An authorization decision answers a security-critical question: may this authenticated user perform this action on this resource? Authentication establishes who the user is; authorization enforces the permissions they should have. A wrong decision can expose another user’s data or let an attacker obtain greater privileges. section 10.0 section 10.20
Treat each decision as domain logic rather than generic plumbing. Define the categories of users, the resources they can reach, and the actions they may or may not take. Because these rules differ between applications and evolve with features, keep a shared design document that states the intended behavior. section 10.0 section 10.5
Make authorization decisions reliably by following a consistent process:
- Identify the authenticated principal, requested action, and target resource before applying a rule. section 10.6
- Use role-based access control (RBAC) for permissions associated with user categories, and attribute-based access control (ABAC) for rules involving particular users and resources. section 10.6
- Base the decision only on validated, trusted data. Keep unvalidated HTTP claims separate from trusted session or database data. section 10.19 section 10.20
- Enforce checks on the server. Client-side checks can improve usability but can be altered by an attacker. section 10.21
- Choose and document the failure response for each route, such as a redirect, 403 Forbidden, or 404 Not Found. section 10.21
Messaging access decision
For a direct-message conversation, a user may read messages they sent or received, but not messages in conversations they do not participate in. A group-chat invitation can likewise determine whether a recipient may join. These are resource-specific decisions: the same user might be allowed to read one conversation and denied another. section 10.4 section 10.6
Test decisions against the documented rules, especially ambiguous and denied cases. Automated scanners cannot determine whether application-specific access rules are correct, so use critical review, QA where available, and automated unit tests to verify that actual behavior matches the design. section 10.13 section 10.14
public void testIllegalEdit() {
User author = new User(1, "theAuthor");
Post post = new Post(author, "Initial content");
User otherUser = new User(2, "notTheAuthor");
Assertions.assertThrows(IllegalEditException.class, () -> {
post.edit(otherUser, "Updated content");
});
}
This unit test verifies a denied decision: a user who did not author a post cannot edit it, and the model raises an exception. section 10.14
