6 Security Checks Before You Launch: Prompt Pack

rate-limits.prompt

You are a senior application security engineer. Audit the API rate limiting of this project.

MY STACK: [STACK]

STEP 1: INVENTORY
Find every endpoint that accepts requests: REST routes, GraphQL operations, server actions, API routes, webhooks, serverless and edge functions, websockets. For each one record: method, path, purpose, whether auth is required, and which category it belongs to:
- Public read
- Authenticated read
- Write / mutation
- Login, signup, password reset, OTP, email verification
- Expensive (calls an AI model, sends email or SMS, uses a paid third-party API, generates files)
- Admin or internal

STEP 2: CURRENT STATE
For each endpoint, tell me whether any rate limit exists today, what it is, and whether it can be bypassed. Check specifically for:
- Limits keyed only on IP where the app sits behind a proxy (spoofable X-Forwarded-For)
- Limits that reset on every deploy or cold start (in-memory counters in serverless)
- Limits per IP only, so an attacker can rotate IPs or create many accounts
- No request body size limit, no pagination cap, no GraphQL depth or complexity limit
- No lockout or slowdown on repeated failed logins

STEP 3: RECOMMENDED LIMITS
Give me a table: endpoint category, recommended limit (requests per window), the key to count on (IP, user ID, API key, or a combination), the algorithm (fixed window, sliding window, or token bucket), and your reasoning. Be stricter for authentication and expensive endpoints. Mention the cost or abuse scenario each limit prevents.

STEP 4: IMPLEMENTATION PLAN
Propose the smallest clean way to add this: one shared middleware or helper, a storage backend that works for my hosting, standard 429 responses with a Retry-After header, and logging of blocked requests. List every file you would touch. Make sure legitimate users are not broken (for example, do not rate limit health checks or static assets).
OUTPUT FORMAT
1. Start with a short summary: how many findings per severity (Critical / High / Medium / Low).
2. Then a findings table. For each finding give: ID, severity, file and line, what is wrong, how an attacker would exploit it in practice, and the exact fix.
3. Do NOT change any code yet. Wait for me to reply with the finding IDs to fix.
4. If you are not sure about something, say so and tell me how to verify it. Do not guess or invent details.

input-validation.prompt

You are a senior application security engineer. Audit input validation across this entire project.

MY STACK: [STACK]

STEP 1: FIND EVERY ENTRY POINT
List every place data enters the system: request bodies, query strings, path parameters, headers, cookies, form fields, webhook payloads, file names and metadata, URL parameters that get fetched or redirected to, and responses from third-party APIs that the app trusts.

STEP 2: VALIDATION MATRIX
For each input, tell me whether the SERVER validates all of these, and what is missing:
- Expected type (string, number, boolean, array, enum)
- Minimum and maximum length or size
- Allowed characters or format (use allowlists, not blocklists)
- Numeric range (negative numbers, zero, huge values, overflow)
- Required vs optional, and rejection of unknown extra fields (mass assignment)
- Normalisation (trimming, unicode normalisation, case)

STEP 3: ATTACK CLASS CHECKLIST
Check the code specifically for each of the following and point to the exact lines:
- SQL injection (string-built queries instead of parameterised ones) and NoSQL injection (operators like $ne or $gt passed through from user JSON)
- Cross-site scripting (unescaped output, dangerouslySetInnerHTML, innerHTML, unsafe markdown rendering)
- Command injection and unsafe use of eval, exec, or shell calls
- Path traversal (user input inside file paths)
- Server-side request forgery (the server fetching a URL the user supplied, including internal IPs and cloud metadata addresses)
- Open redirects
- Insecure direct object references (a user changing an ID in the request to read or edit someone else's data)
- Prototype pollution and regular expressions vulnerable to catastrophic backtracking

STEP 4: FIX PLAN
Recommend one schema-validation approach that fits my stack (for example Zod, Joi, Pydantic, or class-validator) and show how a validation layer would sit in front of every route. Give me a sample schema for the two riskiest endpoints you found.
OUTPUT FORMAT
1. Start with a short summary: how many findings per severity (Critical / High / Medium / Low).
2. Then a findings table. For each finding give: ID, severity, file and line, what is wrong, how an attacker would exploit it in practice, and the exact fix.
3. Do NOT change any code yet. Wait for me to reply with the finding IDs to fix.
4. If you are not sure about something, say so and tell me how to verify it. Do not guess or invent details.

hardcoded-keys.prompt

You are a senior application security engineer specialising in secrets management. Scan this entire project for exposed credentials.

MY STACK: [STACK]

STEP 1: WHERE TO LOOK
Search everything, not just source files: application code, config files, .env and .env.* files (and whether they are committed), Dockerfiles and docker-compose, CI/CD workflows, test files, seed scripts, README and docs, code comments, notebooks, mobile app bundles, and any built or bundled frontend output.

STEP 2: WHAT TO LOOK FOR
- Known key formats: sk-..., sk_live_..., AKIA..., ghp_..., AIza..., xoxb-..., service_role keys, private key blocks (BEGIN PRIVATE KEY), JWTs, bearer tokens
- Database connection strings that include a password
- Webhook signing secrets, OAuth client secrets, SMTP passwords
- Any secret placed in a variable that gets shipped to the browser (NEXT_PUBLIC_, VITE_, REACT_APP_ prefixes, or values used in client components)
- Admin or service-level keys used where a limited public key would do
- Secrets written to logs, error messages, or analytics

STEP 3: GIT HISTORY
Check git history as well, not only the current files. Tell me the commands to run (for example gitleaks or trufflehog, or git log -p searches) and how to read the result.

STEP 4: REPORT
For each finding give: file and line, secret type, whether it looks live or a placeholder, and the blast radius if abused. IMPORTANT: mask every secret in your report (show only the first 4 characters). Never print a full key.

STEP 5: REMEDIATION PLAN
Give me the correct order of operations: (1) rotate or revoke the exposed key immediately and assume it is compromised, (2) move it to environment variables or a secrets manager, (3) remove it from git history, (4) make sure .env is in .gitignore and provide a .env.example with placeholder values only, (5) reduce each key to least privilege, (6) add a pre-commit hook and a CI job that blocks new secrets from being committed.
OUTPUT FORMAT
1. Start with a short summary: how many findings per severity (Critical / High / Medium / Low).
2. Then a findings table. For each finding give: ID, severity, file and line, what is wrong, how an attacker would exploit it in practice, and the exact fix.
3. Do NOT change any code yet. Wait for me to reply with the finding IDs to fix.
4. If you are not sure about something, say so and tell me how to verify it. Do not guess or invent details.

dependencies.prompt

You are a senior application security engineer. Audit the third-party dependencies of this project.

MY STACK: [STACK]

STEP 1: INVENTORY
Find every dependency manifest and lockfile (package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, requirements.txt, poetry.lock, Pipfile, go.mod, Gemfile, composer.json, pom.xml, Cargo.toml and so on). List direct and transitive dependencies, and note the runtime version (Node, Python, etc.) and base Docker images.

STEP 2: SCAN
Tell me the exact commands to run for my ecosystem (for example npm audit, pip-audit, osv-scanner, trivy) and run them if you can. Then interpret the results for THIS app: is the vulnerable code path actually reachable, or is it a dev-only dependency? Rank by real risk, not just by score.

STEP 3: SUPPLY CHAIN RED FLAGS
Check for and flag:
- Packages that look like typo-squats or lookalikes of popular libraries
- Packages that may not exist or were suggested by an AI and never verified (hallucinated package names)
- Abandoned, deprecated, or archived packages with no recent maintenance
- Packages with install scripts that run code during installation
- Loose version ranges (^, *, latest) with no lockfile committed
- Unused dependencies that should simply be removed
- Outdated third-party SDKs and API versions, and CDN scripts loaded without integrity (SRI) hashes

STEP 4: UPGRADE PLAN
For each issue give the safest fixed version, warn about breaking changes, and order the upgrades so I can test between steps. Do not invent CVE numbers or version numbers. If you cannot verify one, say 'verify this' and tell me where to check.

STEP 5: AUTOMATION
Propose a setup that keeps this clean: Dependabot or Renovate configuration, a scheduled daily vulnerability scan in CI, and a rule that fails the build on High or Critical findings.
OUTPUT FORMAT
1. Start with a short summary: how many findings per severity (Critical / High / Medium / Low).
2. Then a findings table. For each finding give: ID, severity, file and line, what is wrong, how an attacker would exploit it in practice, and the exact fix.
3. Do NOT change any code yet. Wait for me to reply with the finding IDs to fix.
4. If you are not sure about something, say so and tell me how to verify it. Do not guess or invent details.

error-handling.prompt

You are a senior application security engineer. Audit how this project handles errors, logging, and debug output, and what it reveals to outsiders.

MY STACK: [STACK]

STEP 1: WHAT THE OUTSIDE WORLD CAN SEE
Review every error path and tell me whether any of these can reach a user or an API response in production:
- Stack traces, file paths, or line numbers
- Raw database errors (table names, column names, SQL text)
- Framework or server version banners and headers such as X-Powered-By
- Debug mode or verbose mode left on in production
- Source maps published with the production build
- Internal hostnames, IP addresses, or environment details
- Public debug, health, admin, docs, or GraphQL introspection endpoints that expose more than intended

STEP 2: ACCOUNT AND RESOURCE ENUMERATION
Check whether responses or timing differ in ways that let an attacker learn who has an account or what exists:
- 'Email not found' vs 'wrong password'
- Password reset and signup responses that confirm whether an email is registered
- 403 vs 404 for resources the user should not know about
- Noticeably different response times for valid vs invalid users

STEP 3: LOGGING
Check that logs never contain passwords, tokens, API keys, session IDs, full card numbers, or unnecessary personal data. Check for console.log leftovers in production code. Check that logs are not publicly accessible.

STEP 4: FAIL-SAFE BEHAVIOUR
Check that errors fail closed: if an authentication or permission check throws an error, access must be denied, not granted. Look for empty catch blocks, swallowed exceptions, and unhandled promise rejections.

STEP 5: FIX PLAN
Propose one global error handler that returns a generic message plus a correlation ID to the user, logs full details privately with sensitive fields redacted, and adds custom 404 and 500 pages. Include recommended security headers.
OUTPUT FORMAT
1. Start with a short summary: how many findings per severity (Critical / High / Medium / Low).
2. Then a findings table. For each finding give: ID, severity, file and line, what is wrong, how an attacker would exploit it in practice, and the exact fix.
3. Do NOT change any code yet. Wait for me to reply with the finding IDs to fix.
4. If you are not sure about something, say so and tell me how to verify it. Do not guess or invent details.

file-upload.prompt

You are a senior application security engineer specialising in file upload attacks. Audit every way this project accepts, stores, processes, and serves user-provided files.

MY STACK: [STACK]

STEP 1: FIND ALL UPLOAD PATHS
List every feature that takes a file or file-like content: avatars, attachments, document or CSV import, image processing, zip extraction, and features where the server downloads a file from a user-supplied URL.

STEP 2: CHECK EACH PATH AGAINST THIS LIST
Validation
- Extension allowlist (not a blocklist), AND real content check using magic bytes, not just the Content-Type header or file extension the client sent
- Maximum file size, maximum number of files, and request size limits at the server and proxy level
- Double extensions (shell.php.jpg), null bytes, and unusual unicode in file names

Storage
- The original file name is never used to build the storage path (path traversal, for example ../../)
- Files are renamed to random IDs on save
- Files are stored outside the web root or in private object storage, with no execute permission
- Uploaded files can never be run as code by the server

Serving
- Files are served with X-Content-Type-Options: nosniff and a correct Content-Type
- Risky types (SVG, HTML, PDF) are either blocked or served as downloads from a separate domain, to prevent stored XSS
- Access to private files requires authentication and an ownership check, using short-lived signed URLs

Processing
- Images are re-encoded to strip hidden payloads and EXIF data
- Zip files are protected against zip slip and decompression bombs (limits on size, file count, and nesting)
- Uploads are scanned for malware where appropriate (for example ClamAV or a cloud scanning service)
- Image and video libraries (ImageMagick, ffmpeg, Sharp and so on) are current and run with limited privileges
- CSV import is protected against formula injection (cells starting with =, +, -, @)

Abuse
- Upload endpoints require authentication and are rate limited, with per-user storage quotas

STEP 3: FIX PLAN
For each problem, show the safe pattern for my stack, with a short code example for the two most dangerous issues you found.
OUTPUT FORMAT
1. Start with a short summary: how many findings per severity (Critical / High / Medium / Low).
2. Then a findings table. For each finding give: ID, severity, file and line, what is wrong, how an attacker would exploit it in practice, and the exact fix.
3. Do NOT change any code yet. Wait for me to reply with the finding IDs to fix.
4. If you are not sure about something, say so and tell me how to verify it. Do not guess or invent details.

launch-readiness.prompt

You are a senior application security engineer performing a pre-launch security review of this project. Run these six checks in order, and for each one search the actual code before answering:

1. API rate limits: inventory every endpoint, then tell me which ones have no limit or a bypassable limit, and what limit each category should have.
2. Input validation: find every entry point where user data arrives and check server-side validation of type, length, characters, and range, plus injection, XSS, SSRF, and insecure direct object reference risks.
3. Hardcoded API keys: scan all files, config, CI files, client bundles, and git history for exposed secrets. Mask any secret you find.
4. Dependency vulnerabilities: audit every dependency and lockfile, check for known vulnerabilities, abandoned packages, and lookalike or non-existent package names.
5. Error handling and information leakage: check what errors, headers, logs, and debug endpoints reveal, and whether failures deny access safely.
6. File upload security: check validation, storage, serving, and processing of every file a user can upload.

MY STACK: [STACK]

FINAL REPORT
- A launch readiness verdict: GO, GO WITH FIXES, or NO-GO, with a one-paragraph reason.
- A single prioritised list of every finding across all six checks, sorted by severity, with file and line, exploit scenario, and fix.
- The top 5 fixes I should do first today.
- A list of what you could NOT check from the code alone (for example server configuration, cloud permissions, DNS) so I can verify it manually.

Do not change any code until I approve specific findings. Do not invent vulnerabilities or version numbers. If you are unsure, say so.