Skip to main content

​
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.

​
Start with a security skill

Security testing is skill-driven. You can invoke a skill directly in chat: 
Run the security skill against the /api/v1/orders endpoints.

Use the pentest skill on the auth flow. Focus on JWT and rate limiting.
Qodex can also pick the right skill when your request includes terms such as OWASP, BOLA, IDOR, auth bypass, SQL injection, SSRF, JWT, or pentest. Use the security skill for methodical coverage and saved regression scenarios. Use the pentest skill when you want deeper adversarial testing on a specific surface.

​
What Qodex checks

OWASP categoryWhat Qodex doesTypical finding
API1: Broken Object Level AuthorizationUses 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 AuthenticationTests 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 AuthorizationLooks for excessive response fields and mass assignment payloads such as role: admin.Excessive data exposure or privilege escalation.
API4: Unrestricted Resource ConsumptionSends controlled request bursts while respecting environment rate limits.Missing rate limiting on auth or expensive endpoints.
API5: Broken Function Level AuthorizationCalls admin or internal endpoints as a lower-privileged user.Privilege escalation or unauthorized admin access.
API6: Unrestricted Access to Sensitive Business FlowsExercises state-changing flows such as coupon use, balance transfer, or multi-step workflow bypass.Race condition or skipped-step acceptance.
API7: SSRFTests server-side fetch inputs such as webhooks, avatar URLs, imports, and link previews.Internal service exposure or cloud metadata access.
API8: Security MisconfigurationAudits headers, cookie flags, CORS, exposed files, and framework fingerprints.Missing security headers, unsafe CORS, or exposed secrets.
API9: Improper Inventory ManagementCompares documented routes with older, internal, or debug versions.Unprotected legacy route or stale API version.
API10: Unsafe Consumption of APIsChecks how the app handles malformed, slow, or hostile upstream responses.Chained SSRF, weak upstream validation, or unsafe webhook handling.

​
How a finding is created

When a probe confirms a vulnerability, Qodex files a finding with the facts needed to reproduce it:
  • Severity such as critical, high, medium, low, or info.
  • OWASP category and attack type.
  • Affected endpoint or flow.
  • Request and response evidence.
  • Reproduction steps.
  • Suggested remediation.
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: 
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.

Security scenarios

Learn how OWASP probes become saved scenarios.

Inverted semantics

Understand why pass means blocked and fail means vulnerable.

Sensitive endpoints

Scope destructive and invasive checks by environment.

Findings

See where confirmed vulnerabilities are tracked.