​

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

​

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

​

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

​

On the roadmap