Test API authorization at object, property, and function boundaries

Bottom line: a valid login does not authorize every object, field, or function an API can reach. For each request, verify the current caller’s right to the specific resource, properties, operation, and business context on the server side.

Source fact: what OWASP distinguishes

The official OWASP API Security Top 10 — 2023 lists broken object-level authorization, broken object-property-level authorization, and broken function-level authorization as separate API risk categories. OWASP describes object identifiers as an object-level access-control surface, property-level failures as unauthorized exposure or manipulation of fields, and function-level failures as access to other users’ resources or administrative functions through flawed role or hierarchy enforcement.

The project describes the Top 10 as an awareness resource for people involved in API development and maintenance. It is not a complete application-security standard.

What the source does not establish

Presence on a Top 10 list does not prove a specific API is vulnerable, and absence from a scanner report does not prove correct authorization. A gateway, token scope, client-side menu, hidden field, or undocumented endpoint may contribute to control but may not enforce the complete business decision.

Correct authorization depends on current identity, tenant, role, relationship, resource ownership, field sensitivity, workflow state, transaction purpose, and other application context. The exact decision varies by system.

Applicability questions

• Which identities, tenants, roles, service accounts, partners, and administrators can call the API?
• Which object identifiers can a caller supply or discover?
• Which properties may each caller read, set, clear, or infer?
• Which functions and state transitions are permitted for each role and relationship?
• Can batch, search, export, GraphQL, mobile, legacy, support, or internal interfaces bypass the intended check?

DSE recommendation: test the complete authorization matrix

The following steps are DSE recommendations based on the cited source.

1. Inventory API versions, hosts, routes, methods, schemas, objects, sensitive properties, business operations, administrative functions, and owners.
2. Build a matrix of caller identity and context against object, property, function, and permitted result. Include cross-tenant, former-owner, suspended, support, and automation cases where applicable.
3. Enforce authorization at the server-side decision point for every request. Treat client filtering and hidden controls as user experience, not the security boundary.
4. Test by changing object identifiers, adding or removing fields, calling alternate methods or routes, changing workflow order, and attempting functions with lower-privileged identities.
5. Return minimal errors and log the decision context needed for investigation without recording tokens, secrets, or unnecessary personal data.
6. Put negative authorization tests into regression suites and re-run them after identity, schema, role, tenant, gateway, or business-flow changes.

Verification and evidence

Retain the API inventory and schema version, authorization matrix, representative test identities and data, allowed and denied requests, server-side decision evidence, regression results, findings and retests, gateway or application configuration, and release record. Sanitize secrets and personal data in evidence.

Official references

• OWASP API Security Top 10 — 2023 — OWASP Foundation; official 2023 edition
• OWASP API Security Project — OWASP Foundation; living project and edition register