> ## Documentation Index > Fetch the complete documentation index at: https://qodex.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # OWASP API Top 10 in Qodex > How Qodex turns OWASP API Top 10 risks into runnable probes, saved scenarios, and findings. See the risk-to-test mapping and evidence model. # OWASP API Top 10 in Qodex Qodex uses the OWASP API Top 10 as a practical testing map. For each risk category, the agent can create probes, save scenarios, verify whether the app blocks the attack, and open findings when the attack succeeds. This page focuses on how Qodex runs those checks. OWASP remains the source of truth for the formal category definitions. ![Qodex generated security scenarios for broken access control and request data creation](https://mintcdn.com/qodexai/rhkO1RmGEPTQ07wr/images/docs/security/security-scenarios.png?fit=max\&auto=format\&n=rhkO1RmGEPTQ07wr\&q=85\&s=48e85280b1f79c927e8eb781adf30b45) ## Start in chat Security testing runs through the API security testing skill. Pick **Security Testing** from the skill list in a new chat, type `/security`, or just describe the work: ```text theme={null} Run the security skill against the /api/v1/orders endpoints. ``` ```text theme={null} Security test the auth endpoints. Focus on JWT and rate limiting. ``` Qodex picks the skill on its own when your request includes terms such as OWASP, BOLA, IDOR, auth bypass, SQL injection, SSRF, or JWT. If you ask for a "pen test" of named endpoints or classes, Qodex notes that full penetration scanning is a separate scan and then runs the checks you asked for. A whole-target scan is started from **Security scans**. See [Security testing](https://qodex.ai/docs/security-testing.md#three-ways-to-test-security). ## What Qodex checks | OWASP category | What Qodex does | Typical finding | | - | - | - | | API1: Broken Object Level Authorization | Uses one user's resource ID with another user's token across read and write actions. | BOLA or IDOR with cross-user data access. | | API2: Broken Authentication | Tests token tampering, expired tokens, weak reset flows, default credentials, and missing rate limits. | Auth bypass, weak session handling, or missing brute-force protection. | | API3: Broken Object Property Level Authorization | Looks for excessive response fields and mass assignment payloads such as `role: admin`. | Excessive data exposure or privilege escalation. | | API4: Unrestricted Resource Consumption | Sends controlled request bursts while respecting environment rate limits. | Missing rate limiting on auth or expensive endpoints. | | API5: Broken Function Level Authorization | Calls admin or internal endpoints as a lower-privileged user. | Privilege escalation or unauthorized admin access. | | API6: Unrestricted Access to Sensitive Business Flows | Exercises state-changing flows such as coupon use, balance transfer, or multi-step workflow bypass. | Race condition or skipped-step acceptance. | | API7: SSRF | Tests server-side fetch inputs such as webhooks, avatar URLs, imports, and link previews. | Internal service exposure or cloud metadata access. | | API8: Security Misconfiguration | Probes debug and config endpoints, verbose errors, and CORS with a credentialed cross-origin read. | Exposed config or secrets, stack traces with internal detail, or unsafe CORS. | | API9: Improper Inventory Management | Compares documented routes with older, internal, or debug versions. | Unprotected legacy route or stale API version. | | API10: Unsafe Consumption of APIs | Checks how the app handles malformed, slow, or hostile upstream responses. | Chained SSRF, weak upstream validation, or unsafe webhook handling. | Beyond the ten API categories, the same catalogue covers cross-tenant access, file upload abuse, credential leakage in responses, OAuth scope over-request (found in linked code), and browser-confirmed issues such as stored script, CSRF, and cookie flags. Response headers and clickjacking belong to Security scans, and vulnerable dependencies belong to Code scan. ## How a finding is created When a probe proves a vulnerability, Qodex files a finding with the facts needed to reproduce it: * Severity such as `critical`, `high`, `medium`, `low`, or `info`, rated by impact and who can reach it. * OWASP category and attack type. * Affected endpoint or flow. * Request and response evidence. * The basis: the rule, endpoint note, or your words that say the behavior is not allowed. * Reproduction steps. * Suggested remediation. At the end of a run, the chat report lists findings by severity, anything found in code but not confirmed live, and anything **ruled out by your rules** because a rule you wrote permits it. For example, a BOLA finding includes the user identities involved, the resource ID, the request made with the wrong user token, and the response that exposed another user's data. ## How scenarios are saved Each confirmed or blocked probe can become a scenario. The expected result is always the secure behavior. For example, a BOLA scenario expects `403` or `404` when User B tries to read User A's resource. If the app returns `200`, the scenario fails and Qodex opens a finding. The assertion is not relaxed to match the vulnerable behavior. ## How to scope a run Security testing can be broad or narrow. For a safer, clearer run, name the exact surface: ```text theme={null} Run BOLA and IDOR checks on /api/v1/orders only. Use admin and viewer auth profiles. Do not run rate-limit probes. ``` Qodex also reads environment constraints before running probes, so production-like targets can stay read-only while staging targets can allow deeper tests. ## Related > [card] [Security scenarios](https://qodex.ai/docs/security-testing-scenarios.md) > > Learn how OWASP probes become saved scenarios. > [card] [Inverted semantics](https://qodex.ai/docs/security-testing-inverted-semantics.md) > > Understand why pass means blocked and fail means vulnerable. > [card] [Sensitive endpoints](https://qodex.ai/docs/security-testing-sensitive-endpoints.md) > > Scope destructive and invasive checks by environment. > [card] [Findings](https://qodex.ai/docs/concepts-findings.md) > > See where confirmed vulnerabilities are tracked. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.