Skip to content

Test Plan: Unauthorized Access Handling

Version Date Author Change Description
1.0 2025-09-11 Senior QA Lead Initial Draft

1.0 Introduction

This document provides the testing strategy for Feature 09: Unauthorized Access Handling. This feature ensures that if an authenticated user attempts to access a resource or perform an action for which they do not have the required permissions, the system will gracefully deny the request and present a clear, user-friendly "Access Denied" page. This serves as a critical security layer.

This plan is based on the requirements defined in:

  • docs/features/09-unauthorized-access-handling/index.md (BRD)
  • docs/features/09-unauthorized-access-handling/use_case.md (Use Cases)

2.0 Scope

2.1 In Scope

  • Verifying that a logged-in user is shown an "Access Denied" page when they try to navigate directly (via URL) to a page for which they lack permissions.
  • Verifying that if a user tries to perform an action via an API call for which they are not authorized, the API returns a "Forbidden" (e.g., HTTP 403) status.
  • Testing the content and usability of the "Access Denied" page, ensuring it has a clear message and a link to a safe location (like the dashboard).
  • This covers all permission-gated features, such as the administrative sections.

2.2 Out of Scope

  • Testing unauthenticated access (covered in Feature 01).
  • The logic of calculating permissions (covered in Feature 04).
  • The proactive hiding of UI elements based on permissions (covered in Feature 02 and other UI feature plans). This plan focuses on testing the reactive "catch-all" security mechanism.

3.0 Test Strategy & Approach

  • Functional/Security Testing: This is the core of the plan. Manual tests will involve logging in as a user with restricted permissions and actively attempting to breach access boundaries by manipulating URLs and, where possible, API calls.
  • UI/UX Testing: The "Access Denied" page itself will be reviewed for clarity and usability.
  • Test Environments: QA, Staging.
  • Test Data:
  • admin_user@example.com (full permissions).
  • standard_user@example.com (no administrative permissions).
  • admin_viewer@example.com (user with admin:user:list but without admin:user:edit or admin:user:create permissions).

4.0 Test Environment Requirements

  • Backend Service: The AuthService must be deployed with all permission-checking logic in place.
  • Frontend Application: The web-based enterprise console must be deployed with the global exception handler and the "Access Denied" page implemented.
  • Supported Browsers: Google Chrome, Mozilla Firefox, Microsoft Edge (latest stable versions).
  • Database: The test database must be populated with the test user accounts and their specific permission sets.

5.0 Test Cases

5.1 Unauthorized Page Access (URL Manipulation)

Test Case ID User Story Description Steps Expected Result
TC-UNAUTH-001 US-14 Security: Standard user attempts to access the admin user list via URL. 1. Log in as standard_user@example.com. \<br> 2. Manually type the URL for the User Management page (e.g., /admin/users) into the browser's address bar and press Enter. The user is not shown the user list. Instead, they are redirected to a user-friendly "Access Denied" page that clearly states they do not have permission to view the page.
TC-UNAUTH-002 US-14 Security: A partial admin attempts to access a function they don't have. 1. Log in as admin_viewer@example.com. \<br> 2. Manually type the URL for the "Add User" form (e.g., /admin/users/create) into the browser's address bar. The user is shown the "Access Denied" page, not the "Add User" form.
TC-UNAUTH-003 US-14 UI: Verify the content and functionality of the "Access Denied" page. 1. Trigger the "Access Denied" page by performing TC-UNAUTH-001. \<br> 2. Inspect the page content. \<br> 3. Click the link to go back to the dashboard. The page contains a clear heading like "Access Denied". It has a helpful message explaining the issue. The link/button to return to the dashboard works correctly.

5.2 Unauthorized API Access

Test Case ID User Story Description Steps Expected Result
TC-UNAUTH-004 US-14 Security: Standard user attempts to fetch user list via API call. 1. Log in as standard_user@example.com to obtain a session token. \<br> 2. Using an API tool, make a direct gRPC/HTTP call to the backend endpoint that lists users, using the session token. The API call fails. The backend service returns an "Unauthorized" or "Forbidden" status code (e.g., 403) and does not return any user data.

6.0 UAT Scenarios

Scenario ID User Story Scenario Description Acceptance Criteria
UAT-UNAUTH-01 US-14 A curious user tries to access a part of the system they shouldn't by guessing the URL. When I am logged in as a standard user and I try to go to the admin page by typing its address directly, the system stops me and shows me a polite "Access Denied" message.

7.0 Entry & Exit Criteria

7.1 Entry Criteria

  • All development for permission-gated features (05-08) is complete and deployed.
  • The global exception handling and "Access Denied" UI are implemented and deployed.
  • All related unit tests are passing.

7.2 Exit Criteria

  • All test cases in this plan have been executed.
  • 100% of Critical and High severity defects are closed. There must be no way for a user to bypass the access control checks.
  • UAT has been successfully completed and signed off by stakeholders.