Access control decides who may perform an action on a resource. It includes authentication, which establishes who a user is, and authorization, which enforces permissions. Missing or broken checks leave an application open to attackers who find exposed functions or manipulate requests to reach data and actions they should not control. section 1.3 section 10.6
Use two complementary rule styles. Role-based access control (RBAC) assigns permissions to user categories. Attribute-based access control (ABAC) makes finer-grained decisions about a subject, an object, their attributes, and the action requested. A typical application combines them: a role establishes broad permissions, while attributes determine which specific resources a user may touch. section 10.6
Make authorization predictable and difficult to bypass:
- Treat authorization as domain logic and describe the intended rules, including ambiguous cases, before relying on code behavior. section 10.13 section 10.21
- Put checks in clearly defined components, such as URL-level routing, interceptors, or model objects; do not assume an upstream component already enforced them. section 10.18 section 10.21
- Keep client-side checks as a convenience only. Enforce permissions on the server because browser JavaScript can be manipulated. section 10.21
- Choose an explicit denial response for each route, such as a redirect, 403 Forbidden, or 404 Not Found, according to its context. section 10.21
Ownership checks and escalation
Resource ownership is a common ABAC rule: a person may control their own email or social-media content, but not another user’s. Never base that decision on HTTP data an attacker can alter. Manipulated input can cause vertical escalation to stronger privileges or horizontal escalation into another user’s account at a similar permission level. section 10.6 section 10.20
Test access-control rules against the behavior defined for the application. Generic scanners are less useful here because authorization is application-specific, so use critical code review, QA where available, and automated tests. Testing early is especially valuable because authorization bugs are critical and cheaper to fix before later stages. 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 creates an author, a post, and another user, then verifies that the other user cannot edit the post. It captures an ownership rule as an executable check that should fail when authorization is missing or regresses. section 10.14
Protect sensitive operational resources as well as application data. Limit the people and processes that can reach servers holding encryption, separate web and application servers, and keep private encryption keys out of publicly shared directories. If unauthorized server access is suspected, follow a prepared certificate-revocation and reissue process. section 7.13
