Indie codebases rarely fall to clever zero-days. They fall to the boring stuff: a missing ownership check, an .env committed to git, a dependency carrying a two-year-old CVE. Broken Access Control is still the #1 risk in the OWASP Top 10:2025, present in roughly 3.7% of all tested apps, and SSRF was folded into it that same year. You don’t need a pentester for the first 80% of that surface — you need disciplined, repeatable checks. The 12 prompts below walk the OWASP bases and produce a finding-plus-fix list you can actually close before launch.
TL;DR
- Paste each prompt into a model with a large context window so it can read the whole file, not a snippet. As of June 2026, Claude Opus 4.7 and Sonnet 4.6 (1M tokens) and Gemini 3.1 Pro (1M) are the strongest fits; GPT-5.5 Thinking works for shorter files.
- AI replaces the first pass, not the audit. Treat every “ok” as “looks ok, verify the fix and add a test.”
- Always confirm dependency findings with a real scanner (
npm audit,pip-audit, orosv-scanner) — LLMs hallucinate CVE numbers. - The prompts are mapped to OWASP Top 10:2025 categories below so your coverage is auditable, not vibes.
Which prompt covers which OWASP risk
| OWASP Top 10:2025 | Prompts that cover it |
|---|---|
| A01 Broken Access Control (incl. SSRF) | 5 (authz), 2 (SSRF in input) |
| A02 Security Misconfiguration | 7 (CORS), 11 (CSP/headers) |
| A03 Software Supply Chain Failures | 4 (dependencies) |
| A04 Cryptographic Failures | 1 (token/JWT), 3 (secrets) |
| A05 Injection | 2 (input validation), 6 (uploads) |
| A06 Insecure Design | 12 (STRIDE threat model) |
| A07 Authentication Failures | 1 (auth flow) |
| A08 Data Integrity Failures | 10 (webhook signatures) |
| A09 Security Logging & Alerting Failures | 8 (PII logging), 9 (abuse) |
| A10 Mishandling of Exceptional Conditions | 8, 10 (failure behavior) |
Best for
- Pre-launch security pass
- API / endpoint review
- Auth and authz flow audit
- Dependency and supply-chain audit
- Post-incident hardening
1. Auth flow audit
Audit my auth flow below. For each of the following, give status (ok / risky / broken), evidence (cite line), and the fix: token storage location, refresh token rotation, session expiry policy, multi-device handling, password reset link entropy and TTL, brute-force / rate-limit protection, OAuth state and PKCE, JWT algorithm and audience validation, account enumeration on login error. Output as a markdown table.
Code:
[paste]2. Input validation audit
Audit input validation across the endpoints below. For each endpoint, list: (a) every parameter and whether it is validated (type, range, allowlist), (b) plausible attacks if unvalidated (SQLi, XSS, path traversal, SSRF, command injection, prototype pollution), (c) the minimal fix with library suggestion. Rank findings critical / high / medium.
Code:
[paste]3. Secret-handling audit
Audit secret handling in the code and config below. Look for: hardcoded API keys / tokens / passwords, secrets in client-side bundles or source maps, .env files committed to git, secrets logged at any level, secrets passed via URL query params, missing rotation strategy. Output: file:line, severity, fix. Also produce a 5-line "what to do in the next 60 minutes" emergency list if anything is critical.
Code + config:
[paste]4. Dependency vulnerability check
Below is package.json / requirements.txt / Gemfile / go.mod. Identify: (a) packages with known CVEs (use your training knowledge, mark "verify with npm audit / pip-audit / osv-scanner"), (b) suspiciously unmaintained packages (no release in 2+ years for security-critical libs), (c) typosquatting risks, (d) over-broad version ranges that pin to vulnerable majors. Output upgrade order with breaking-change risk noted.
Manifest:
[paste]The model’s CVE list is a starting hypothesis, not a result. Always re-run the real scanner:
npm audit,pip-audit(PyPA / Trail of Bits), orosv-scannerfor multi-ecosystem repos — these match against OSV.dev instead of guessing.
5. Authorization model audit
Below are authz checks across the app. Map them and identify: (a) endpoints that have authentication but no authorization check, (b) inconsistent checks (same resource has different rules in different routes), (c) IDOR risk (object access by ID without ownership check), (d) horizontal and vertical privilege escalation paths, (e) admin endpoints reachable from user role. Output a route x required-role matrix and call out the holes.
Code:
[paste]6. File upload safety audit
Below is the file upload code path. Audit for: unrestricted file types / missing magic-byte check, path traversal in filename, content-type spoofing, double-extension bypass, size limits and total-quota limits, where files are stored (inside web root? S3 with public ACL?), virus/malware scanning, image processing CVE exposure (ImageMagick, sharp). For each finding give a fix with code.
Code:
[paste]7. CORS & CSRF audit
Below is CORS + CSRF config and a sample of state-changing endpoints. Audit: (a) over-permissive Access-Control-Allow-Origin (`*` with credentials, regex bypass), (b) state-changing endpoints missing CSRF tokens or SameSite=Lax/Strict cookies, (c) preflight handling, (d) WebSocket origin checks, (e) subdomain takeover risk in the allowed list. Fix each with concrete config.
Config + routes:
[paste]8. Logging & PII audit
Below are logging statements and the log retention config. Identify any log line that emits PII (email, phone, full name, IP, device ID), credentials (tokens, session IDs, password reset URLs), or business secrets. For each: suggest a scrub (hash, truncate, redact), or drop the line entirely. Also check: are logs shipped to a third party? do we have a DSAR-friendly deletion story? do we alert on auth failures and not just log them (OWASP A09)?
Code + config:
[paste]9. Server-side rate limiting & abuse audit
Audit rate limiting on the endpoints below. For each: is there a limit, is it per-IP / per-user / per-key, is it global or per-endpoint, what is the cost-of-abuse if missing (LLM token cost, SMS cost, email send, expensive query). Flag any endpoint that can drain budget or trigger account lockout DOS. Suggest limits with reasoning.
Endpoints:
[paste]10. Webhook & inbound API audit
Audit inbound webhooks and public APIs. Check: (a) signature verification (HMAC with constant-time compare, replay protection via timestamp + nonce), (b) idempotency keys, (c) source IP allowlist where available, (d) payload size limits, (e) what happens on signature failure (silently 200? log and alert?). Also verify the secret rotation story.
Code:
[paste]11. Client-side / browser security audit
Audit the front-end for: (a) Content-Security-Policy presence and gaps (unsafe-inline, wildcard sources), (b) sensitive data in localStorage vs httpOnly cookies, (c) XSS sinks (dangerouslySetInnerHTML, v-html, innerHTML with user data), (d) postMessage origin checks, (e) third-party script supply chain (any script tag from a domain we don't control without SRI). Fix per finding.
Code:
[paste]12. Threat model for a single feature
For the feature described below, run a STRIDE threat model. For each category (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege): 1-2 specific threats relevant to this feature, the asset at risk, the existing mitigation (or "none"), and the recommended control. End with 3 top risks to fix before shipping.
Feature spec:
[paste]Pick the right model and tool
The audit prompts above are model-agnostic, but the read quality scales with context window and reasoning.
| Setup | Best for | Note (June 2026) |
|---|---|---|
| Claude Opus 4.7 / Sonnet 4.6 | Whole-repo and multi-file authz mapping | 1M-token context; Opus scored 73.1% on CyberGym vuln reproduction |
| Gemini 3.1 Pro | Large monorepos, cheap bulk passes | 1M context; API 2/12 per 1M tokens |
| GPT-5.5 Thinking | Single-file deep dives | In-app ~320 pages on Plus; full 1M only on the $200 Pro tier |
| Claude Code Security | Automated repo scan in your terminal | Built into Claude Code since Feb 2026; runs the audit without copy-paste |
If you live in the terminal, Claude Code Security (launched February 2026) runs many of these checks automatically — Anthropic reports it surfaced 500+ high-risk issues in open-source repos during testing. See what Claude Code is and our code review prompts for the day-to-day workflow.
Common mistakes
- Auditing only injection bugs and skipping authorization entirely — yet A01 Broken Access Control outranks A05 Injection in the 2025 list.
- Trusting “the framework handles it” without verifying which version and config.
- No threat model per feature, so security gets bolted on during release week.
- Logging fixed but retention set to forever, so historical PII still leaks on breach.
- Taking the model’s CVE numbers at face value instead of re-running a real scanner.
- Patching the bug but not adding a regression test or an alert.
FAQ
Can AI prompts replace a real penetration test? No. They cover the repeatable first 80% — config, obvious authz gaps, leaked secrets, stale dependencies. They miss business-logic abuse, chained exploits, and runtime issues. For anything handling payments or health data, budget for a human pentest before launch and treat these prompts as the cheap pre-screen.
How accurate are AI dependency findings?
Useful as a hypothesis, unreliable as fact. LLMs frequently hallucinate CVE identifiers and version ranges. Always confirm with npm audit, pip-audit, or osv-scanner, which match against the OSV.dev database rather than guessing.
Which model should I use? Pick the one that fits the whole file in context. As of June 2026 that means Claude Opus 4.7 / Sonnet 4.6 or Gemini 3.1 Pro (1M tokens each) for repo-scale audits; GPT-5.5 Thinking is fine for single files. If you work in the terminal, Claude Code Security automates the scan.
Is it safe to paste my code into a chatbot? Don’t paste live secrets — redact keys first, and prefer your provider’s data-controls or API (which is not trained on by default). For private repos, a local or self-hosted model is the safest option. Strip real credentials before any audit prompt regardless of provider.
What’s the right order for a pre-launch pass? Start with secrets (3) and dependencies (4) because they are the cheapest to exploit, then authorization (5) and auth (1), then input/upload/CORS (2, 6, 7), then logging and abuse (8, 9), and finish with a per-feature threat model (12) on your two riskiest features.
Related
Tags: #Prompt #AI coding #Security audit