What to know
- Check the caller’s permission for the specific object and requested action.
- Separate object access, administrative functions, and access to individual fields.
- Test denied cases, shared access, and background workflows with authorized test accounts.
The missing question after sign-in
An API can correctly authenticate a customer and still return another customer’s record. The missing decision is whether this caller may perform this action on this particular object. OWASP identifies this class of failure as broken object level authorization. The problem can appear wherever a client supplies a reference that the server uses to locate protected data.
Consider a hypothetical project-management service. A signed-in contractor may legitimately view tasks assigned to one project. That does not authorize the contractor to read every task held by the service. The server needs enough trusted context to evaluate the relationship between the caller and the requested task, even when the request is well formed and the identifier is valid.
Source: OWASP API Security: Broken Object Level Authorization
An identifier locates data; it does not grant access
A difficult-to-guess identifier can reduce casual discovery, but it does not replace an authorization decision. References can legitimately appear in links, exports, notifications, and integrations. An implementation should remain correct when someone learns an identifier they are not entitled to use. This is why object access must be evaluated at the operation that reads or changes the protected record.
In the project example, a contractor might receive a forwarded email containing a link to an unrelated task. The safe result depends on policy, not on whether the link was expected to remain obscure. A useful design exercise is to ask what the service does with a valid reference outside the user’s authorized project and whether the response reveals unnecessary information.
Source: OWASP API Security: Broken Object Level Authorization
Express the relationship the product intends
Ownership is only one possible access relationship. A record may be shared with a team, delegated for a limited task, or governed by a customer organization. OWASP’s authorization guidance discusses attribute- and relationship-based approaches alongside least privilege and default denial. The implementation needs a policy model that reflects the product’s actual relationships, rather than relying on a single broad role.
For the hypothetical service, write down whether a contractor can read a task, attach a file, edit its due date, or invite someone else. Those actions may require different authority. When a person changes teams, decide what happens to access already shared with them. These are product requirements with security consequences, and they should be explicit before an endpoint is released.
Source: OWASP: Authorization Cheat Sheet
Distinguish objects, functions, and properties
OWASP separately describes broken function level authorization, where a caller reaches an operation outside their permitted role. It also describes broken object property level authorization, where an otherwise accessible object exposes or accepts changes to protected fields. These distinctions are useful because checking one boundary does not necessarily enforce the others.
A project member might be allowed to read a task but not invoke an organization-wide export. The member might also be allowed to edit a task description but not its internal billing classification. Review the endpoint, the selected object, and the fields returned or changed. A generic conversion of an internal record into an API response can obscure these separate decisions.
Source: OWASP API Security: Broken Function Level Authorization · OWASP API Security: Broken Object Property Level Authorization
Test the negative space of the product
Authorized tests should cover more than successful access by the intended user. Create controlled accounts representing different customers, projects, and roles. Verify that each can perform its permitted work and cannot reach the neighboring cases. Use test data and systems you are authorized to assess. The most useful failures reveal a gap in the policy or where it is applied.
Add cases for bulk operations, downloads, search results, and background jobs. In the project service, the ordinary task page might enforce membership while an asynchronous export uses a broader service identity. Trace the initiating user’s authority through the job and the delivery of its result. A consistent policy should survive a change in interface or execution timing.
Source: Ceron: Customer Portal Security Assessments: Protecting the Systems Your Clients Log Into
Make the boundary maintainable
Place checks where developers can reason about them and reuse them consistently without losing the necessary object context. Keep a compact record of the policy and the tests that demonstrate it. When the product adds sharing or delegation, update both. A code review should be able to identify which decision permits an operation and what would cause that decision to deny it.
Logging can help investigate unexpected access, but it should not create another store of unnecessarily exposed data. Capture useful identifiers and decisions under an appropriate retention policy. The objective is an API whose access behavior can be explained and tested as the product evolves. A secure sign-in establishes the caller; the application still has to protect every operation that follows.
Source: OWASP: Authorization Cheat Sheet
Sources & further reading
- OWASP API Security: Broken Object Level Authorization
- OWASP: Authorization Cheat Sheet
- OWASP API Security: Broken Function Level Authorization
- OWASP API Security: Broken Object Property Level Authorization
- Ceron: Customer Portal Security Assessments: Protecting the Systems Your Clients Log Into
Factual statements are grounded in the linked material. Interpretation and illustrative examples are Byte Watchr analysis. Vendor claims are identified as claims, rather than independent testing.
This article belongs to Byte Watchr’s launch collection. The edition date organizes evergreen coverage and does not imply historical publication. Actual publication is recorded above.
Corrections policy · About this byline
