{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/api-authorization-object-property-function-boundaries/", "item": { "id": "https://update.dsesecurity.com/updates/api-authorization-object-property-function-boundaries/", "slug": "api-authorization-object-property-function-boundaries", "url": "https://update.dsesecurity.com/updates/api-authorization-object-property-function-boundaries/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/api-authorization-object-property-function-boundaries.md", "json": "https://update.dsesecurity.com/api/v1/posts/api-authorization-object-property-function-boundaries/" }, "title": "Test API authorization at object, property, and function boundaries", "summary": "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.", "format": { "slug": "checklist", "name": "Checklist" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-08-25T21:33:46+00:00", "modified_at": "2026-08-26T13:27:47+00:00", "reviewed_on": "2026-08-25", "reading_minutes": 3, "word_count": 473, "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.", "primary_source": { "name": "OWASP API Security Top 10 — 2023", "url": "https://owasp.org/API-Security/editions/2023/en/0x11-t10/", "published_on": null, "authority": "owasp.org" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

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.

\n

Source fact: what OWASP distinguishes

\n

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.

\n

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.

\n

What the source does not establish

\n

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.

\n

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.

\n

Applicability questions

\n\n

DSE recommendation: test the complete authorization matrix

\n

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

\n
    \n
  1. Inventory API versions, hosts, routes, methods, schemas, objects, sensitive properties, business operations, administrative functions, and owners.
    2. \n
  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. \n
  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. \n
  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. \n
  5. Return minimal errors and log the decision context needed for investigation without recording tokens, secrets, or unnecessary personal data.
    6. \n
  6. Put negative authorization tests into regression suites and re-run them after identity, schema, role, tenant, gateway, or business-flow changes.
    7. \n
\n

Verification and evidence

\n

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.

\n

Official references

\n", "content_text": "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.\nSource fact: what OWASP distinguishes\nThe 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.\nThe 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.\nWhat the source does not establish\nPresence 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.\nCorrect 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.\nApplicability questions\n\nWhich identities, tenants, roles, service accounts, partners, and administrators can call the API?\nWhich object identifiers can a caller supply or discover?\nWhich properties may each caller read, set, clear, or infer?\nWhich functions and state transitions are permitted for each role and relationship?\nCan batch, search, export, GraphQL, mobile, legacy, support, or internal interfaces bypass the intended check?\n\nDSE recommendation: test the complete authorization matrix\nThe following steps are DSE recommendations based on the cited source.\n\nInventory API versions, hosts, routes, methods, schemas, objects, sensitive properties, business operations, administrative functions, and owners.\nBuild 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.\nEnforce authorization at the server-side decision point for every request. Treat client filtering and hidden controls as user experience, not the security boundary.\nTest by changing object identifiers, adding or removing fields, calling alternate methods or routes, changing workflow order, and attempting functions with lower-privileged identities.\nReturn minimal errors and log the decision context needed for investigation without recording tokens, secrets, or unnecessary personal data.\nPut negative authorization tests into regression suites and re-run them after identity, schema, role, tenant, gateway, or business-flow changes.\n\nVerification and evidence\nRetain 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.\nOfficial references\n\nOWASP API Security Top 10 — 2023 — OWASP Foundation; official 2023 edition\nOWASP API Security Project — OWASP Foundation; living project and edition register", "content_markdown": "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.\n\n## Source fact: what OWASP distinguishes\n\nThe 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.\n\nThe 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.\n\n## What the source does not establish\n\nPresence 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.\n\nCorrect 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.\n\n## Applicability questions\n\n- Which identities, tenants, roles, service accounts, partners, and administrators can call the API?\n\n- Which object identifiers can a caller supply or discover?\n\n- Which properties may each caller read, set, clear, or infer?\n\n- Which functions and state transitions are permitted for each role and relationship?\n\n- Can batch, search, export, GraphQL, mobile, legacy, support, or internal interfaces bypass the intended check?\n\n## DSE recommendation: test the complete authorization matrix\n\nThe following steps are DSE recommendations based on the cited source.\n\n- Inventory API versions, hosts, routes, methods, schemas, objects, sensitive properties, business operations, administrative functions, and owners.\n\n- 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.\n\n- Enforce authorization at the server-side decision point for every request. Treat client filtering and hidden controls as user experience, not the security boundary.\n\n- Test by changing object identifiers, adding or removing fields, calling alternate methods or routes, changing workflow order, and attempting functions with lower-privileged identities.\n\n- Return minimal errors and log the decision context needed for investigation without recording tokens, secrets, or unnecessary personal data.\n\n- Put negative authorization tests into regression suites and re-run them after identity, schema, role, tenant, gateway, or business-flow changes.\n\n## Verification and evidence\n\nRetain 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.\n\n## Official references\n\n- [OWASP API Security Top 10 — 2023](https://owasp.org/API-Security/editions/2023/en/0x11-t10/) — OWASP Foundation; official 2023 edition\n\n- [OWASP API Security Project](https://owasp.org/www-project-api-security/) — OWASP Foundation; living project and edition register" }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/api-authorization-object-property-function-boundaries/", "url": "https://update.dsesecurity.com/updates/api-authorization-object-property-function-boundaries/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-08-25" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/api-authorization-object-property-function-boundaries/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Test API authorization at object, property, and function boundaries", "item": "https://update.dsesecurity.com/updates/api-authorization-object-property-function-boundaries/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/api-authorization-object-property-function-boundaries/#article", "identifier": "https://update.dsesecurity.com/updates/api-authorization-object-property-function-boundaries/", "url": "https://update.dsesecurity.com/updates/api-authorization-object-property-function-boundaries/", "headline": "Test API authorization at object, property, and function boundaries", "description": "The OWASP API Security Top 10 distinguishes object-level, property-level, and function-level authorization failures. Test each requested resource…", "abstract": "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.", "articleBody": "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.\nSource fact: what OWASP distinguishes\nThe 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.\nThe 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.\nWhat the source does not establish\nPresence 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.\nCorrect 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.\nApplicability questions\n\nWhich identities, tenants, roles, service accounts, partners, and administrators can call the API?\nWhich object identifiers can a caller supply or discover?\nWhich properties may each caller read, set, clear, or infer?\nWhich functions and state transitions are permitted for each role and relationship?\nCan batch, search, export, GraphQL, mobile, legacy, support, or internal interfaces bypass the intended check?\n\nDSE recommendation: test the complete authorization matrix\nThe following steps are DSE recommendations based on the cited source.\n\nInventory API versions, hosts, routes, methods, schemas, objects, sensitive properties, business operations, administrative functions, and owners.\nBuild 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.\nEnforce authorization at the server-side decision point for every request. Treat client filtering and hidden controls as user experience, not the security boundary.\nTest by changing object identifiers, adding or removing fields, calling alternate methods or routes, changing workflow order, and attempting functions with lower-privileged identities.\nReturn minimal errors and log the decision context needed for investigation without recording tokens, secrets, or unnecessary personal data.\nPut negative authorization tests into regression suites and re-run them after identity, schema, role, tenant, gateway, or business-flow changes.\n\nVerification and evidence\nRetain 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.\nOfficial references\n\nOWASP API Security Top 10 — 2023 — OWASP Foundation; official 2023 edition\nOWASP API Security Project — OWASP Foundation; living project and edition register", "datePublished": "2026-08-25T21:33:46+00:00", "dateModified": "2026-08-26T13:27:47+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/api-authorization-object-property-function-boundaries/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/api-authorization-object-property-function-boundaries/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Test API authorization at object, property, and function boundaries" }, "articleSection": [ "Cybersecurity", "IT", "Microsoft 365 & Identity" ], "keywords": [ "Cybersecurity", "IT", "Microsoft 365 & Identity", "Checklist", "Important priority" ], "genre": "Checklist", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "wordCount": 473, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "OWASP API Security Top 10 — 2023", "url": "https://owasp.org/API-Security/editions/2023/en/0x11-t10/" } } ] } }