GraphWarden and OWASP API Security Top 10 (2023)

The OWASP API Security Top 10 is a community-driven list of the ten most critical security risks affecting modern APIs. The 2023 edition (the most recent) updated the 2019 list based on incident data and community input. For organizations exposing Microsoft Graph to internal applications and third-party SaaS vendors, several items in the Top 10 land squarely on the proxy layer. GraphWarden's Response Filter transforms address API3 (Broken Object Property Level Authorization) — the most common Graph finding — and the ruleset model addresses API5 (Broken Function Level Authorization) via per-method restrictions. This document maps each of the ten OWASP risks to GraphWarden's capabilities, with explicit focus on API3 and API5 and explicit limits on what the proxy does not cover.

Who this document is for

- An organization performing an API security review of a Microsoft 365-integrated product - A security engineering team adopting the OWASP API Top 10 as a risk framework - Access to the GraphWarden admin application and to your Azure Key Vault - Intended readers: security engineer, AppSec lead, CISO, penetration tester

OWASP API Top 10 context

OWASP — the Open Worldwide Application Security Project — maintains several community-driven security resources, including the original Application Security Top 10 (first published in 2003) and the API Security Top 10 (first published in 2019, updated in 2023). The API Top 10 is a risk-awareness list; it is not a certification framework. The 2023 edition covers ten categories: broken object-level authorization (API1), broken authentication (API2), broken object property-level authorization (API3), unrestricted resource consumption (API4), broken function-level authorization (API5), unrestricted access to sensitive business flows (API6), server-side request forgery (API7), security misconfiguration (API8), improper inventory management (API9), and unsafe consumption of APIs (API10).

API3 deserves particular attention for Microsoft Graph deployments. The 2019 edition called this risk Excessive Data Exposure; the 2023 edition renamed and broadened it to Broken Object Property Level Authorization, combining the old Excessive Data Exposure and Mass Assignment risks into one category. In Graph workloads, API3 manifests whenever a Graph response returns more fields than the consuming application strictly requires — for example, a help-desk application that only needs displayName and mail but receives the full user object. GraphWarden's Response Filter transforms address API3 declaratively at the proxy layer, no application code changes required. For formal assurance, the companion OWASP Application Security Verification Standard (ASVS) provides testable requirements; GraphWarden can be an input to an ASVS assessment but is not the whole program.

OWASP API Top 10 mapping to GraphWarden capabilities

OWASP API risk GraphWarden capability Status Technical proof
API1:2023 — Broken Object Level Authorization Ruleset conditions on object_attribute and group_membership Aligned A rule can limit which Graph objects (users, groups, sites) are reachable based on attributes.
API2:2023 — Broken Authentication client_credentials flow against proxy; Graph credentials in Key Vault Aligned The app never handles real Graph credentials; token acquisition flows through the proxy.
API3:2023 — Broken Object Property Level Authorization Response Filter transforms on specific response properties Aligned Central GraphWarden capability. Limit returned fields per ruleset — no over-fetching.
API4:2023 — Unrestricted Resource Consumption rate_limit condition Supported Ruleset can enforce a per-minute rate limit per App Identity.
API5:2023 — Broken Function Level Authorization Ruleset action restrictions (allow/block per HTTP method) Aligned A ruleset can limit which HTTP methods (GET/POST/DELETE) an App Identity may use on each endpoint.
API6:2023 — Unrestricted Access to Sensitive Business Flows Combined conditions (time_window + rate_limit + caller_identity) Supported Rulesets can require specific context windows for sensitive operations.
API7:2023 — Server Side Request Forgery Graph is the only upstream; no user-controlled URL targets Not in scope The proxy connects to Graph only; SSRF vectors are bounded by design.
API8:2023 — Security Misconfiguration Rulesets are version-controlled YAML Supported Changes are auditable and reviewable.
API9:2023 — Improper Inventory Management App Identities and rulesets catalog all Graph consumers Aligned Explicit inventory of every system integrated to Graph.
API10:2023 — Unsafe Consumption of APIs GraphWarden consumes Graph API only; upstream is Microsoft Not in scope Application responsibility for downstream consumption of its own dependencies.

Concrete scenario

A security engineer reviews an SaaS product that integrates with Microsoft 365 Graph. The review identifies API3 (Broken Object Property Level Authorization) on the product's /users query: the product reads the entire user object when it only displays displayName, mail, and jobTitle. Without GraphWarden, remediation requires code changes on the SaaS side. With GraphWarden, the engineer adds a Response Filter on the App Identity ruleset that allowlists those three fields; the proxy strips every other property at the response layer. No code change is required on the SaaS side. A follow-up review adds API5 coverage by restricting the App Identity's method set to GET only, blocking writes that would be out of scope for the product's function.

Hosting and data residency

The data processing location depends on your GraphWarden deployment configuration. In on-premise mode (Windows Service or Docker) inside your own infrastructure, Graph responses are filtered inside your network boundary. In hosted mode, refer to your GraphWarden contract for the applicable deployment region. Graph credentials (client secrets, certificates) never leave your Azure Key Vault: GraphWarden holds only their SHA-256 fingerprint to authenticate calls from your applications. The zero-knowledge credential model directly supports API2 (Broken Authentication) by removing a class of credential-leak risks from the application surface.

Limits

GraphWarden aligns with several OWASP API Top 10 risks but does not cover every application security concern. The following items remain your responsibility.

  • GraphWarden does NOT detect application-layer logic bugs — parameter tampering, IDOR in your app's own code, or missing authorization on your internal endpoints are outside the proxy's view.
  • GraphWarden does NOT cover supply-chain risks in your own dependencies — vulnerable packages, transitive CVEs, and outdated runtimes are out of scope.
  • GraphWarden does NOT cover API security beyond Microsoft Graph — integrations with other APIs (AWS, Stripe, internal microservices) require their own controls.
  • GraphWarden does NOT issue an OWASP API Top 10 certification — the Top 10 is a risk-awareness list, not a certification scheme. Alignment with the Top 10 is not formal compliance.
  • GraphWarden does NOT replace an OWASP ASVS program — the Application Security Verification Standard is a broader, testable control set; GraphWarden can be an input but not the whole program.
  • GraphWarden does NOT perform penetration testing — the proxy is a preventive control; offensive testing of your applications remains a separate engagement.

Prepare your OWASP API brief with an AI assistant

Prepare an OWASP API Top 10 compliance brief

Prepare an OWASP API Top 10 (2023) compliance brief for my M365-integrated product using GraphWarden, with focus on API3 and API5.

I need to deliver to my AppSec lead:
1. Which OWASP API Top 10 risks GraphWarden helps address (item-by-item mapping)
2. Which risks remain under my responsibility (out of scope — application-layer logic, supply chain, non-Graph APIs, pen-testing)
3. The technical artifacts I can reference in the review package (YAML rulesets with Response Filter, App Identity inventory, rate-limit configuration)

Reference documentation: https://graphwarden.com/llms.txt

Ask me:
- Which OWASP API risks came back as findings on my current review
- How many Graph-integrated applications are in scope
- Whether I plan to pursue OWASP ASVS verification as a follow-on

Reference: llms.txt

Troubleshooting

  • An API3 finding lands on a Graph query — how do I fix it without changing application code? Add a Response Filter on the App Identity ruleset to allowlist only the required fields; see Rulesets and Rules.
  • An API5 finding says my application can call methods it should not. Restrict the App Identity ruleset's match.methods to the allowed HTTP methods (for example, [GET] only); anything else returns 403.
  • My pentester asks for an inventory of every Graph consumer (API9). Export the App Identity list from your GraphWarden admin — each App Identity is an explicit entry in the inventory.
  • I want to rate-limit a specific App Identity (API4). Add a rate_limit condition on the ruleset with max_requests and window_seconds; see Rulesets and Rules.
  • How do I evidence that ruleset changes are reviewable (API8)? Rulesets live in version control as YAML; every change is reviewable through your Git pull-request process, and the audit log records when the new ruleset went live.

Resources

Next steps

For a demo tailored to your OWASP API review, contact the GraphWarden team. Review the use cases to see how other organizations have mapped Response Filter transforms to API3 findings. Bring to the session: your review findings, your list of Graph-integrated applications, the OWASP edition you are targeting (2019 or 2023), and the desired audit retention tier (90 days, 1 year, or 7 years).

Dernière revue :