> ## 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. # Security testing > Run OWASP API Top 10, BOLA, IDOR, auth-bypass, and injection tests in the same suite as your functional regression. # Security testing Qodex brings security testing into the same workflow as your API, UI, and regression tests. Instead of waiting for a yearly pentest report, you can run OWASP API Top 10 checks, BOLA and IDOR probes, auth-bypass tests, and injection scenarios as repeatable tests in your project. The goal is simple: turn important security checks into saved scenarios with evidence, severity, and reproduction steps. When the app blocks an attack, the scenario becomes regression coverage. When the attack succeeds, Qodex opens a finding. ## How security testing works The security testing flow has four parts: * **Choose the surface** you want to test, such as an endpoint group, auth flow, sensitive resource, or imported API collection. * **Ask for API security testing** in chat so Qodex runs checks from known vulnerability classes against those endpoints. * **Verify each check** against the target environment using inverted security assertions, and save it as a rerunnable scenario. * **Report findings** with request and response evidence only when a vulnerability is proven. ## Three ways to test security | Surface | Where | What it does | | - | - | - | | API security testing | Chat (pick **Security Testing** or type `/security`) | Tests the endpoints you name against the OWASP Top 10 and OWASP API Security Top 10, saves a scenario for every check, and files findings with evidence. | | Security scans | **Test > Security scans** | Runs an authorized scanner, built on ZAP and nuclei, against a whole target you have verified you own. Started from a button, not from chat. | | Code scan | **Code > Code scan** | Reads a linked repository and files what it finds (for example code patterns, secrets, and vulnerable dependencies) on the Findings page. | > [!NOTE] > > Full penetration scans do not run in chat. If you ask chat to "pen test" specific endpoints or a vulnerability class, Qodex says in one line that full penetration scanning runs as a separate scan, then runs the API security checks you asked for. A whole-app pen test is a **Security scan**, which a project admin starts from **Security scans**. Security scans are switched on per project; if the page says scanning is not enabled, contact Qodex to turn it on. ## Start a security scan A project admin starts a scan in two steps: 1. Open **Test > Security scans** and switch to **Targets**. Under **Register a target**, enter the origin (scheme, host, and port, no paths) and click **Register**. Prove you control it with a **DNS record** or a **File on your server**, then click **Verify**. The target shows **Verified** once the proof is found. 2. Switch to **Scans**. Under **Start a scan**, pick the **Target**, keep **Web app** as the scan type, and click **Start scan**. Type the target's label to confirm, then start. The scan sends real attack traffic, with destructive and denial-of-service payload classes disabled. **Recent scans** lists the last 10 scans with their status, duration, and findings count. Scan results stay on this page and are not listed on the Findings page. ## What you can start with > [card] [OWASP API Top 10 in Qodex](https://qodex.ai/docs/security-testing-owasp-api-top-10.md) > > See how Qodex maps OWASP API risks to probes, scenarios, and findings. > [card] [Security scenarios](https://qodex.ai/docs/security-testing-scenarios.md) > > Understand how attack scenarios differ from functional tests. > [card] [Inverted semantics](https://qodex.ai/docs/security-testing-inverted-semantics.md) > > Learn why pass means the attack was blocked and fail means the app is vulnerable. > [card] [Sensitive endpoints](https://qodex.ai/docs/security-testing-sensitive-endpoints.md) > > Scope active testing with environment constraints before running invasive checks. ## Continuous, not annual Security testing often happens as a point-in-time audit. The report lands, the highest-risk issues get fixed, and coverage starts drifting as soon as new endpoints ship. Qodex treats security checks as part of the normal test suite. The agent can author security scenarios from chat, save them with the same lifecycle as functional scenarios, run them on a schedule or in CI, and turn failures into findings with evidence. That makes security testing easier to repeat. A BOLA check on `/api/orders/{id}` can run after every release, not only during a formal review. ## What Qodex can test today * OWASP API Top 10 categories such as BOLA, broken auth, mass assignment, rate limiting, SSRF, and misconfiguration. * Authorization issues including IDOR, broken object-level authorization, and broken function-level authorization. * Auth and session issues such as JWT manipulation, expired tokens, default credentials, and missing login rate limits. * Injection and payload-based checks such as SQL injection, command injection, and unsafe server-side fetches. * Security findings with severity, reproduction steps, request and response evidence, and OWASP category. * Code-assisted checks when repositories are linked: Qodex reads the route handler before it probes, and marks anything found in code but not confirmed live as **Needs review** instead of filing it as a bug. * Per-environment constraints such as `read_only`, `max_requests_per_second`, and `allow_destructive_tests`. ## DAST and SAST DAST (dynamic application security testing) probes a running application from the outside, sending real requests to find vulnerabilities in live behavior. SAST (static application security testing) scans source code without running it. Qodex security testing is dynamic, so it is DAST-style: it runs real attack scenarios against your live API and web app and confirms a vulnerability with request and response evidence. It is not a SAST tool and does not scan your source for insecure patterns. Qodex PR review does read the code diff for risky changes, but that is code review, not a static security scanner. ## Where results go When a security scenario passes, Qodex keeps it as regression coverage. When it fails, Qodex first classifies what happened: the attack worked, the app defended itself, the setup broke before the check ran, or the expectation was wrong. Only a proven attack becomes a finding, with the evidence a human needs to reproduce and fix the issue. An authorization claim ("user B should not be able to read this") must rest on a rule you wrote, an endpoint note, or something you said in chat. Without one, Qodex asks you instead of filing, and the candidate waits on the Findings page as **Needs review**. Findings are deduplicated, so the same vulnerability does not become a pile of duplicate tickets. On the test run page, a failed security check is labeled **Vulnerability present**, or **Still present** when the finding was already open. ## Where to go next > [card] [Security scenarios](https://qodex.ai/docs/security-testing-scenarios.md) > > Learn the scenario model Qodex uses for security checks. > [card] [Findings](https://qodex.ai/docs/concepts-findings.md) > > Review severity, evidence, and lifecycle states for reported issues. > [card] [Auth profiles](https://qodex.ai/docs/api-testing-auth-profiles.md) > > Configure roles used for BOLA, IDOR, and privilege-escalation tests. > [card] [API scenarios](https://qodex.ai/docs/api-testing-scenarios.md) > > See the base scenario model shared by API and security testing. ## On the roadmap > [!TIP] > > Qodex plans to add a dedicated `allow_security_testing` environment gate and an API scan type for Security scans that drives your documented endpoints against their own schema. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.