Authorization Testing

Authorization tests verify that users can access only the resources and operations permitted by their roles or permissions. They focus on what an authenticated user is allowed to do, including preventing access to another user's data or privileged operations.

Authorization is the access-control decision made after, or alongside, authentication: given a user, resource, and requested operation, the application determines whether access should be allowed. In a Java backend, this may be implemented with roles, permissions, ownership checks, or framework-level security rules.

Tests should cover both allowed and denied cases. For example, a regular user might be allowed to read their own profile but denied access to another user's profile, while an administrator may be allowed to access both. Negative tests are especially important because an authorization defect can expose data or privileged functionality.

A useful test matrix varies the caller, resource, and operation. Test users with different roles, resources owned by different users, and operations such as read, update, delete, or administrative actions. Also verify that changing URL parameters, request bodies, or HTTP methods cannot bypass the intended access rules.

Authorization tests should exercise the real security boundary rather than merely testing helper methods in isolation. In Java applications using a security framework, integration or controller-level tests can verify that protected endpoints return the expected status, such as `403 Forbidden` for an authenticated user without sufficient permission.

Key points

• Test both permitted and denied access.
• Cover role, permission, and resource-ownership rules.
• Include negative tests for horizontal and vertical privilege escalation.
• Do not rely only on client-side or UI restrictions.
• Prefer tests that exercise the actual backend security boundary.

Interview questions

What is authorization testing?

Authorization testing verifies that an authenticated user can perform only the actions and access only the resources allowed by the application's security rules. It includes successful cases and denied cases. For example, a normal user should not be able to call an administrator-only endpoint. It should also verify that one user cannot access another user's protected data.

How would you test an endpoint that allows users to update their own profile?

I would test a user updating their own profile and expect the request to succeed when the input is valid. I would then attempt to update another user's profile using that user's identifier and expect the server to deny the operation. I would also verify that changing the identifier in the URL or request body does not bypass the ownership check. The important rule is enforced by the backend, not merely by the UI.

What is the difference between horizontal and vertical privilege escalation?

Horizontal privilege escalation occurs when a user accesses another user's resources at the same privilege level, such as reading someone else's account. Vertical privilege escalation occurs when a lower-privileged user performs an action reserved for a higher-privileged role, such as invoking an administrator operation. Authorization tests should cover both forms. They are different failure modes even though both result from inadequate access control.

Where should authorization be tested in a Java backend?

The exact layer depends on where the application enforces the rule, but tests should reach the real security boundary. Controller or integration tests are useful for verifying that protected HTTP endpoints reject unauthorized requests. Service-level tests can verify business authorization rules when those rules live in services. A strong test suite can combine focused unit tests with integration tests so that both rule logic and actual endpoint enforcement are covered.

What authorization cases belong in a test matrix?

A useful matrix varies the caller identity or role, the target resource and its ownership, and the requested operation. It should include allowed access, same-level cross-user access, higher-privilege operations, missing permissions, and attempts to manipulate resource identifiers. The matrix should also consider different HTTP methods when an endpoint exposes multiple operations. This approach makes authorization rules explicit and reduces gaps caused by testing only the happy path.