What this prompt does
This prompt runs a focused OWASP Top 10 (2025) review of a single API endpoint and demands evidence, not opinions. The model walks each risk category, states present yes or no, and — for every yes — cites the exact line of code as proof. It then assigns a rough CVSS severity, writes real remediation code, and produces a regression test that fails before the fix and passes after. Forcing line-level evidence is what stops it inventing phantom vulnerabilities.
The variables scope the review tightly. [method] and [path] identify the endpoint under test. [endpoint_code] is the substance — you paste the route and controller so the model has something to cite rather than guess at. [auth_model] tells it how authentication and authorization actually work, which is decisive for the access-control checks the prompt asks it to scrutinize hardest.
When to use it
- You are reviewing one endpoint before it ships and want a per-risk verdict
- You suspect broken object-level authorization — the classic edit-the-id-read-someone-elses-record bug
- You want findings backed by exact line evidence, not generic security advice
- You need remediation code you can apply, plus a test that proves the fix
- You want a rough CVSS severity to prioritize what to fix first
- You are checking injection or SSRF risk in an endpoint that takes user input
Example output
The model returns a table with columns for risk, present, evidence, and severity covering the 2025 OWASP Top 10. Below it come remediation snippets for each real issue and the matching regression tests. Findings marked yes point to specific lines from the [endpoint_code] you pasted, with a one-line CVSS justification, so you can trace every claim back to the source.
Pro tips
- Paste the full
[endpoint_code]— route, controller, and any middleware — so the model can cite real lines instead of assuming - Describe
[auth_model]precisely ("Sanctum bearer token, policy-gated"); access-control findings hinge on how authorization actually runs - Push hard on broken access control, injection, and SSRF, which the prompt already flags for extra scrutiny
- Verify the access-control fix manually with a second user's token before shipping — that is the bug class the prompt is best at catching
- Treat the CVSS numbers as rough triage signals, not audited scores; they exist to rank, not to certify
- For endpoints that call other services, make sure the SSRF section accounts for any user-controlled URLs or identifiers
- Include any middleware or policy class in
[endpoint_code], not just the controller method, since authorization often lives a layer up from the handler - Run the generated regression test in your suite before and after the fix, so you have proof the vulnerability is closed rather than just a patched line
