# Test API authorization at object, property, and function boundaries > The OWASP API Security Top 10 distinguishes object-level, property-level, and function-level authorization failures. Test each requested resource, field, and operation with representative identities. - Canonical URL: https://update.dsesecurity.com/updates/api-authorization-object-property-function-boundaries/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:33:46+00:00 - Modified: 2026-08-26T13:27:47+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know The OWASP API Security Top 10 distinguishes object-level, property-level, and function-level authorization failures. Test each requested resource, field, and operation with representative identities. ## Potentially affected Organizations developing, integrating, purchasing, or operating APIs that expose data objects, object properties, business functions, or administrative operations. ## DSE recommendation Create an authorization matrix for identities, objects, properties, functions, and context; enforce decisions server-side; and automate negative tests without relying on hidden user-interface controls. ## Article 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](https://owasp.org/API-Security/editions/2023/en/0x11-t10/) 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. - Inventory API versions, hosts, routes, methods, schemas, objects, sensitive properties, business operations, administrative functions, and owners. - 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. - Enforce authorization at the server-side decision point for every request. Treat client filtering and hidden controls as user experience, not the security boundary. - Test by changing object identifiers, adding or removing fields, calling alternate methods or routes, changing workflow order, and attempting functions with lower-privileged identities. - Return minimal errors and log the decision context needed for investigation without recording tokens, secrets, or unnecessary personal data. - 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](https://owasp.org/API-Security/editions/2023/en/0x11-t10/) — OWASP Foundation; official 2023 edition - [OWASP API Security Project](https://owasp.org/www-project-api-security/) — OWASP Foundation; living project and edition register ## Primary reference - Name: OWASP API Security Top 10 — 2023 - Authority: owasp.org - URL: https://owasp.org/API-Security/editions/2023/en/0x11-t10/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Test API authorization at object, property, and function boundaries,” DSE Security, https://update.dsesecurity.com/updates/api-authorization-object-property-function-boundaries/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.