Indie codebases get breached on the boring stuff: missing authz, leaked env file, dependency with a 2-year-old CVE. You don’t need a pentester for the first 80%, you need disciplined checks. These prompts walk the OWASP-y bases and produce a finding-plus-fix list you can actually close.
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"), (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}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 × 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?
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}Common mistakes
- Auditing only injection bugs and skipping authorization entirely
- Trusting “the framework handles it” without verifying which version and config
- No threat model per feature — security gets bolted on at release week
- Logging fixed but log retention forever, so historical PII still leaks on breach
- Patching the bug but not adding a regression test or alert
Related
Tags: #Prompt #AI coding #Security audit