RBAC Permission & Access Rule Testing Quiz Quiz

This quiz evaluates your understanding of role-based access control (RBAC) permission testing and access rule verification. Assess your ability to identify security gaps, interpret access policies, and ensure robust protection of resources in RBAC-secured environments.

  1. RBAC Principle Application

    In an RBAC-secured system, if a user with the 'Editor' role can delete records but should only be allowed to modify them, which type of issue does this scenario best illustrate?

    1. Over-assignment of permissions
    2. Role shadowing
    3. Under-assignment of permissions
    4. Privilege escalation attack

    Explanation: This scenario is a classic case of over-assignment of permissions because the 'Editor' role grants more access than necessary, allowing record deletion when only modification should be permitted. Role shadowing refers to one role hiding another's permissions, which is not described here. Under-assignment would mean the user lacks required permissions. Privilege escalation implies the user exploited a vulnerability to gain extra permissions, but there's no suggestion of exploitation in the scenario.

  2. RBAC Test Strategy

    When testing RBAC rules for a 'Manager' role, which of the following is the best practice to ensure proper access restrictions are enforced across different resources?

    1. Test only using a single manager account
    2. Verify access for all assigned and unassigned permissions
    3. Review resource names in the database
    4. Rely on user interface cues for role assignments

    Explanation: The proper approach is to systematically check what the 'Manager' can and cannot do: both assigned (allowed) and unassigned (disallowed) permissions must be tested to ensure RBAC rules are enforced. Using only one account may miss rule inconsistencies. Examining resource names does not directly verify access controls. Relying solely on the interface could be misleading if backend restrictions are misconfigured.

  3. Role Hierarchy Evaluation

    Suppose an RBAC system supports role hierarchies, where 'Senior Analyst' inherits all permissions of 'Analyst' plus additional rights. What is the main security testing concern with this configuration?

    1. Senior Analyst may lose basic permissions
    2. Analyst role becomes a superuser
    3. Inherited permissions might exceed intended access
    4. Role assignment becomes automatic

    Explanation: A key concern is that inherited permissions can lead to broader access than necessary if not carefully managed, causing privilege accumulation. There is little risk of losing basic permissions; inheritance provides additional, not fewer, rights. The Analyst role does not become a superuser just due to inheritance. Role assignment itself does not become automatic in this context.

  4. Access Denial Scenario

    A user assigned only the 'Viewer' role receives an error when attempting to create a record, while reading records works as expected. What does this indicate about RBAC enforcement?

    1. RBAC is incorrectly granting excessive privileges
    2. RBAC is correctly restricting unassigned actions
    3. Role definitions are missing
    4. The user's account is disabled

    Explanation: Since the 'Viewer' role allows reading but not creating records, and the system blocks the creation attempt, RBAC is enforcing access rules properly. Excessive privileges would mean access was granted instead of denied. Missing role definitions would typically prevent any access. An account being disabled would prevent all actions, not selectively block writing.

  5. Testing Least Privilege

    In RBAC permission testing, what is the most effective method to verify the principle of least privilege for a 'Support' role handling user tickets?

    1. Grant temporary admin rights during tests
    2. Attempt all possible ticket actions, including unauthorized ones
    3. Assign every available permission to 'Support'
    4. Skip negative test cases as unnecessary

    Explanation: The best verification is to ensure the 'Support' role only allows necessary actions—both by confirming authorized actions work and by attempting actions that should be disallowed, thereby catching excessive privileges. Granting admin rights undermines least privilege. Assigning all permissions contradicts the intent. Negative testing should not be ignored, as it helps reveal gaps in restrictions.