Why this matters
CISSP lens
Pick answers that align business risk, governance intent, and practical control execution.
Many breaches boil down to one user doing something only another user should be allowed to do. Getting authentication and authorization right inside applications is central to Domain 8 and to everyday security.
Core concept
Access control in applications is about three related ideas:
- Authentication, proving who or what is acting.
- Authorization, deciding what that identity is allowed to do.
- Accounting, recording what was done.
Good application designs apply all three consistently at multiple layers.
Authentication patterns
Common patterns include:
- Session based authentication using cookies after login.
- Token based authentication using JWT or opaque tokens.
- Federated identity using SAML or OpenID Connect.
Regardless of mechanism, secure designs:
- Protect credentials in transit and at rest.
- Use secure session management with timeouts and rotation.
- Support multi factor authentication where risk justifies it.
Authorization models
The two main models you will encounter are:
- Role based access control (RBAC): permissions group into roles, and users are assigned roles.
- Attribute based access control (ABAC): decisions use attributes of users, resources, and context, such as department, classification, or location.
RBAC is simpler and works well in many business systems. ABAC can support rich policies but requires more design and governance.
Enforcement in applications
Access control should be enforced on the server side, not only in the user interface.
Good practices:
- Centralize authorization logic where possible, for example in middleware or a dedicated service.
- Protect every API endpoint that returns sensitive data or performs sensitive actions.
- Ensure the data layer enforces constraints that align with application logic.
- Require re authentication for especially sensitive operations.
CISSP lens
Domain cross-reference
For the exam:
- Distinguish clearly between authentication, authorization, and accounting.
- Recognize RBAC and ABAC examples and choose models that fit business needs.
- Emphasize server side checks and defense in depth.
- Consider usability and administrative overhead in design choices.
Domain 8 also intersects with Domain 5 on identity and access management, but here you focus on how applications consume and enforce identity information.
Real-world scenario
An internal admin interface hides certain links unless the user is marked as an admin in the UI. However, the underlying API endpoints do not check authorization.
An attacker with a normal account inspects network traffic and discovers admin endpoints. By calling these directly, they can perform actions intended only for administrators.
The fix involves:
- Moving authorization checks into the API layer, validating user roles and scopes on every request.
- Adding logging for all administrative actions.
- Updating tests to cover authorization failures.
- Reviewing other services to ensure they do not rely on UI only protection.
How application access control fails in practice
A small set of failure patterns accounts for most real-world authorization breaches. They appear constantly in penetration test reports and in exam scenarios:
| Failure pattern | What it looks like | Primary defense |
|---|---|---|
| Insecure direct object reference (IDOR) | Changing /invoice/1001 to /invoice/1002 shows another customer's invoice | Object-level authorization check on every request |
| Vertical privilege escalation | A normal user calls an admin-only endpoint directly | Server-side role checks, deny by default |
| Horizontal privilege escalation | One tenant's user reads another tenant's data | Tenant context enforced in the data layer, not just the UI |
| Missing function-level control | Hidden menu items, unprotected API routes | Authorization middleware applied to all routes, with exceptions listed explicitly |
Notice the common thread: every failure is the application trusting something the client controls - a URL, a hidden field, a menu state. The fix is always the same principle: the server decides, on every request, using identity it verified itself.
OAuth 2.0 and OpenID Connect in practice
Modern applications increasingly delegate authentication to an identity provider and consume tokens. The division of labor matters for the exam:
- OpenID Connect (OIDC) answers "who is this user?" It produces an ID token the application uses to establish a session.
- OAuth 2.0 answers "what is this client allowed to access on the user's behalf?" It produces access tokens carrying scopes.
The frequent design mistake is treating scopes as a full authorization model. Scopes describe what an application may request (read calendar, send mail); they do not replace per-resource checks. A token with a valid "read invoices" scope still needs the application to verify that this user may read this invoice. Scope checks and object-level checks are layers, not alternatives.
Token handling rules worth memorizing: keep token lifetimes short, validate signatures and audience on every request, and treat refresh tokens like credentials - stored securely, rotated on use, revocable centrally.
Service-to-service identity
In a microservice architecture, services call each other constantly, and "internal traffic is trusted" is the assumption attackers exploit for lateral movement. Service-to-service access control mirrors user-facing access control:
- Authentication: mutual TLS or signed service tokens prove which workload is calling. Platform-issued workload identities beat long-lived shared API keys, which leak and never rotate.
- Authorization: each service maintains an explicit list of which callers may invoke which operations. The billing service accepting calls from anything on the network is the application-layer version of a flat network.
- Accounting: service identity appears in logs, so a request can be traced end to end across hops.
This is zero trust applied inside the application boundary: verify explicitly at every hop, regardless of network location.
Common mistakes
Relying on hidden UI elements or client side checks as the main access control mechanism.
Applying authorization inconsistently across services and endpoints.
Creating overly complex role structures that nobody reviews or cleans up.
Allowing long lived sessions without re authentication for critical actions.
Ignoring service to service authentication and authorization in microservice architectures.
Actionable checklist
- Document key roles and permissions for each major application.
- Ensure server side authorization checks protect every sensitive endpoint and action.
- Implement centralized access control logic or libraries so rules are applied consistently.
- Set reasonable session timeouts and require re authentication for high risk actions.
- Review and adjust role assignments regularly, removing unused or overly powerful roles.
- For microservices, implement strong service authentication using mutual TLS or signed tokens.
Key takeaways
- Access control is a combination of authentication, authorization, and accounting.
- Server side enforcement is essential, UI checks alone are never enough.
- Simple, well governed roles or attributes work better than complex, unmanaged ones.
- CISSP Domain 8 expects you to design access control that is both secure and manageable.
Exam-style reflection
Exam practice
An application hides the "Admin" menu from non admin users but does not enforce authorization checks on the related URLs. What is the primary risk.
Short answer: Users who know or discover the admin URLs can access privileged functions without proper authorization. Relying only on the UI to enforce access control leaves critical functions exposed.
This article is part of the CISSP Domain 8: Software Development Security study guide. Use the pillar to navigate every article in this domain.
