Innomerc Learn
English is the default.
Application Security

Broken Access Control

Compare an allowed request, an ownership failure and a server-enforced denial in the same application.

Intermediate6 min explorationReviewed OWASP Top 10 2025
My learningNot started

Choose your depth. Learn at your own pace.

Simple explanation

Understand it

Broken access control happens when a system allows an action that its policy should forbid. A signed-in user might read another user’s invoice, change an administrator setting or cross a tenant boundary. The login can be correct while the permission decision is wrong.

Cedar Billing assigns invoice 123 to Alex and invoice 124 to Sam. The visual changes only the requested invoice. A secure server checks ownership rather than assuming that a user who knows the identifier may access it.

Technical explanation

Under the hood

Object-level authorization connects the authenticated subject with the requested object and operation. Function-level checks restrict operations such as exports or administration. Property-level checks limit which fields can be read or modified. All can fail independently.

An insecure direct object reference is one way an object authorization failure appears. Random identifiers may reduce guessing, but do not enforce permission. Scope queries and writes using trusted identity and tenant context; do not accept a client-supplied owner as evidence.

Practitioner explanation

Practitioner perspective

Test a matrix of users, roles, tenants, objects and actions using authorized test accounts. Include alternate methods, bulk operations, nested resources and asynchronous exports. A single middleware check can miss business rules deeper in the operation.

Record authorization outcomes with enough context to investigate cross-boundary access. Avoid exposing sensitive response bodies in logs. Test both allowed and denied cases so controls do not quietly break legitimate collaboration or delegated access.

Picture the idea: identity is not permission

A visitor shows an identity card beside two separate filing cabinets. The other person’s cabinet remains protected.

Entering the building represents Authentication. Permission to open a particular cabinet represents Authorization. A server must check access to each resource; signing in alone is not enough.

Illustrated analogy · Select the image to enlarge
See the decision happen

Watch it work

A fictional, simplified model. Select a component to inspect it, or follow the steps in order.

Interactive Lab

How credentials are checked

See the difference between storage, proof, validation and authorization.

Steps1. Valid credentials 2. Other user’s object 3. 403 · denied
Click a box or choose its name to learn what it means.
ClientReadyVerifierReadyCredential storeReadyResourceReadyClientReadyVerifierReadyCredential storeReadyResourceReady
Ready to traceAuthorization failure
Before you start · 3 stepsAuthorization failure

Authentication can succeed while the requested object remains forbidden.

How to use this example

Select Next step to read at your own pace, or Animate step to watch one exchange. Nothing advances until you choose.

Inspect components & read every step
  • Client

    A program that asks another system for information or an action.

    Example: A shopping app requests a list of products from a service.

  • Verifier

    The system checking whether the presented proof is acceptable.

    Example: A sign-in service checks a submitted password against its stored password verifier.

  • Credential store

    Storage for authentication-related records. It should not hold passwords as readable text.

    Example: A service stores salted password hashes and account information.

  • Resource

    The information or action someone wants permission to use.

    Example: A private document or an account setting is a resource.

JWT validation

A readable token is not a trusted token; validate claims before authorization.

  1. Client Verifier: Signed token. The request includes a token, not its signing key.
  2. Credential store Verifier: Trusted public key. Resolve trusted verification material; this may be cached.
  3. Verifier Resource: Validated claims. Check issuer, audience and lifetime, then evaluate permissions.
  4. Resource Client: Allowed response. Only an authorized operation returns protected data.

Server session

An opaque cookie identifies server-side session state.

  1. Client Verifier: Session cookie. The browser sends an opaque session identifier.
  2. Verifier Credential store: Lookup session. The service reads the associated state.
  3. Credential store Verifier: User + expiry. Expiry and revocation affect the result.
  4. Verifier Resource: Identity context. Resource authorization is still required.

Password hashing

Use a password KDF such as Argon2id with a unique salt and suitable cost.

  1. Client Verifier: Password over TLS. The verifier receives the candidate in a protected connection.
  2. Credential store Verifier: Salt + KDF settings. Retrieve the stored salt, parameters and verifier.
  3. Verifier Credential store: Compare verifier. Compare computed and stored verifier safely; do not store plaintext.
  4. Verifier Client: Decision. Apply rate limits and additional factors where required.

Refresh token

Renewal is a separate credential flow, not an extension of an expired access token.

  1. Client Resource: Expired token. The resource rejects an expired access token.
  2. Client Verifier: Refresh credential. The client presents its refresh credential to the authorization server.
  3. Verifier Client: New access token. Issue a new token only after the refresh policy succeeds.
  4. Client Resource: Retry with token. The resource validates the new token and requested permissions.

API key

An API key is a credential with scope, expiry and revocation policy—not necessarily a user identity.

  1. Client Verifier: API key. The client presents a secret credential over TLS.
  2. Verifier Credential store: Lookup policy. Check status, expiry and configured permissions.
  3. Verifier Resource: Scoped caller. Authorize this operation under the credential’s policy.

Authorization failure

Authentication can succeed while the requested object remains forbidden.

  1. Client Verifier: Valid credentials. The verifier establishes who the caller is.
  2. Verifier Resource: Other user’s object. The application checks the target owner and action.
  3. Resource Client: 403 · denied. Protected content is not returned.

Fictional teaching trace. One moving dot represents an exchange, not a measured network capture.

Open the detailed lesson walkthrough

Explore the system

Alex

Alex is authenticated to Cedar Billing.

1 / 4

Takeaway An allowed request has a valid identity and a valid permission.

Read every step without animation

Normal request

  1. Alex. Alex is authenticated to Cedar Billing.
  2. Invoice 123. The requested invoice belongs to Alex.
  3. Ownership check. The server verifies the subject–object relationship.
  4. Allowed. Alex receives only the permitted invoice.

An allowed request has a valid identity and a valid permission.

Missing check

  1. Alex. The same authenticated user changes the object identifier.
  2. Invoice 124. This invoice belongs to Sam.
  3. No ownership check. The application looks up the ID without checking its owner.
  4. Data exposed. Sam’s fictional invoice is returned to Alex.

Authentication succeeded; authorization failed.

Defense enabled

  1. Alex. Alex requests invoice 124 again.
  2. Invoice 124. The server obtains the object’s ownership context.
  3. Policy enforced. Alex is not permitted to read Sam’s invoice.
  4. Denied. No invoice content is returned.

Server-side ownership validation changes the outcome.

Explore deeper: additional experiment
Change an input. Inspect the consequence.

Try the object ownership boundary

200 · Invoice returned

The authenticated user owns this invoice. This scenario grants access to the owner.

A local teaching model with fictional inputs. It does not test a live system.

Attack view

In this local simulation, Alex requests Sam’s invoice. Without the ownership check, the fictional application returns another person’s data. No real API or customer information is involved.

Defender view

  • Enforce deny-by-default policy on the server for every protected action.
  • Use trusted identity and tenant context in object lookup and modification.
  • Add regression checks for cross-user and cross-tenant requests.

Common mistakes

  • Hiding a button does not protect the underlying operation.
  • Unpredictable IDs are not a substitute for authorization.

Check your understanding

Which fix directly addresses this failure?
Active recall: explain this idea in 30 seconds

Broken access control happens when a system allows an action that its policy should forbid. A signed-in user might read another user’s invoice, change an administrator setting or cross a tenant boundary. The login can be correct while the permission decision is wrong.

Now give an example and name one limitation. Revisit the explanation if you get stuck.

Primary sources

Original explanations informed by these specifications and official resources. Source versions and lesson review are separate from product updates.

Content reviewed 2026-09-10. Framework reference: OWASP Top 10 2025. Read the editorial policy.

What comes next?

Web and application security
OWASP Top 10 2025

Back to topic

Applying this to your environment? Explore relevant Innomerc Tech services