AI Security Auditing, Part 3: Audit Your API Against the OWASP API Top 10 With AI

AI Security Auditing series — Part 3 of 5. Part 1: Setup · Part 2: Authentication · Part 3: API & OWASP · Part 4: Injection & XSS · Part 5: Runtime detections

If your product is API-first, this is the most important audit you'll run. APIs are the bloodstream of modern applications, and they fail in ways a web-page scanner never sees — because the vulnerability is in the authorization logic, not the markup. In this part we audit your API against the full OWASP API Security Top 10 (2023) with an AI agent.

New to the series? Start with Part 1.

The OWASP API Security Top 10 (2023)

The audit maps to all ten risks. Here's what each means and what the AI looks for in your code:

• API1 — Broken Object Level Authorization (BOLA). An endpoint takes an object ID but never checks the caller owns it (GET /orders/1234 returns anyone's order). The #1 API risk, ~40% of attacks. The audit flags handlers that read an ID from the request and query by it without an ownership check.
• API2 — Broken Authentication. Weak token validation, missing expiry, JWTs accepted without signature checks. Overlaps with Part 2.
• API3 — Broken Object Property Level Authorization (BOPLA). Mass assignment (a client sets isAdmin: true) or over-returned fields (the response leaks columns the user shouldn't see).
• API4 — Unrestricted Resource Consumption. No rate limits, no pagination caps, unbounded queries — the door to denial-of-service and denial-of-wallet.
• API5 — Broken Function Level Authorization (BFLA). A regular user can call an admin-only route because the check is missing or client-side.
• API6 — Unrestricted Access to Sensitive Business Flows. Automation abuse of flows like checkout, signup, or ticket purchase — technically "valid" requests, used at scale.
• API7 — Server-Side Request Forgery (SSRF). The API fetches a user-supplied URL, letting an attacker reach internal services or the cloud metadata endpoint.
• API8 — Security Misconfiguration. Debug mode in prod, open /swagger, wide-open CORS, missing TLS, default credentials.
• API9 — Improper Inventory Management. Old API versions still live, shadow endpoints, internal/test APIs exposed. Attackers love forgotten endpoints — unpatched and unmonitored.
• API10 — Unsafe Consumption of APIs. Blindly trusting data from third-party APIs you call.

Run the audit

Go to /threat-modeling/api-security and click Copy prompt. Paste it into your agent at the project root.

The prompt tells the agent to inventory every route and handler, then walk each of API1–API10 against your real implementation. When it finishes, open threat/api-security/api-security-code-findings.html.

What the findings look like

An API audit typically surfaces:

• BOLA on GET /api/projects/:id — routes/projects.js:28, critical. Reads :id and queries by it with no WHERE owner_id = currentUser check.
• Mass assignment on PATCH /api/users/:id — routes/users.js:64, high. Spreads the whole request body into the update, so a client can set role.
• No pagination cap on GET /api/events — routes/events.js:12, medium. ?limit=1000000 will happily try to return everything.
• Shadow endpoint /api/v1/internal/export — routes/legacy.js:5, high. An old, undocumented route with no auth middleware.

Every finding points at a file:line. Fix the criticals first — BOLA and BFLA are the ones attackers reach for.

Don't forget the adjacent surfaces

The OWASP API Top 10 prompt covers REST. If your API includes other shapes, run these alongside it:

• GraphQL: /threat-modeling/graphql-security — introspection, query depth/cost, batching, resolver authorization.
• Webhooks: /threat-modeling/webhooks — inbound signature/replay verification and outbound SSRF on dispatch.
• Realtime: /threat-modeling/realtime-websocket-sse — authz and resource use on long-lived connections.

For a deeper, standalone reference on the framework itself, see OWASP API Security Top 10 (2023): a developer's guide with AI audit prompts.

Code fixes close holes; detection catches attempts

Two OWASP API risks — API4 (Unrestricted Resource Consumption) and API6 (Sensitive Business Flows) — can't be fully solved in code, because the individual requests are valid. The attack is the volume and pattern. That's a runtime-detection problem by nature.

Open api-security-detection-mitigation.html for the rules: flag an IP flooding a single endpoint, flag distributed enumeration of sequential object IDs (BOLA probing), flag automation against a sensitive business flow. Related deep dives:

• API attack surface discovery & mapping — find the shadow endpoints from API9.
• Anatomy of an API abuse campaign: detection to remediation.

We turn the detection logic into running rules in Part 5.

Checklist before you move on

• Ran the API security prompt and reviewed the code-findings report
• Fixed all BOLA/BFLA (API1/API5) findings — these are the priority
• Ran the GraphQL and/or webhooks prompts if they apply
• Skimmed the detection-mitigation report for API4/API6 rules
• Committed the reports to version control

Next

APIs fail on authorization. The next class of bug fails on input — data that gets executed instead of stored. That's injection, XSS, and SSRF, and it's Part 4.

Continue to Part 4 — Find injection, XSS & SSRF with AI →