Production Security Audit Prompt

Fresh Codex CLI

Copy this into Codex before you ship your beginner app to production.

Run Codex CLI in your repo, paste this prompt, and let it find and safely fix vulnerabilities before production.

---

Audit first, fix safely, ship only after clean gates.

Use Codex like a security reviewer

Before a beginner project goes live, ask Codex to inspect dependencies, secrets, authentication, inputs, web headers, server behavior, and deploy config. The goal is not a broad rewrite. The goal is small, safe remediations and a final report you can review.

1. Open Codex in the repo. Start from the project folder so the agent can inspect the real files, lockfiles, tests, and config.
2. Paste the security audit prompt. Tell Codex exactly what to check, what it can fix, and what must wait for a human decision.
3. Review fixes and rerun checks. Ship only after the verification commands pass and the remaining findings make sense to you.

The master prompt

Paste this into Codex before pushing your app to production. Keep the human-decision rule intact so the agent does not guess on risky choices.

You are a senior application security engineer. Perform a production-readiness
security audit on this codebase, then safely fix the issues you find.

Goal:
Before this app goes to production, identify likely vulnerabilities, insecure
defaults, exposed secrets, broken auth/access control, dependency risks, unsafe
API behavior, and configuration mistakes. Then implement safe remediations.

Rules:
- Do not delete features or make broad rewrites.
- Do not change public behavior unless required for security.
- Do not touch real secrets, rotate credentials, publish, deploy, or run
  external destructive actions.
- If a finding requires a human decision, document it instead of guessing.
- Prefer small, targeted fixes with clear comments only where helpful.
- Preserve existing style, architecture, and tests.

Audit scope:
1. Dependencies
   - Run the project's package/security audit commands when available.
   - Check package manager files for vulnerable or stale dependencies.
   - Flag critical/high vulnerabilities and fix safe upgrades if compatible.

2. Secrets and sensitive data
   - Search for hardcoded API keys, tokens, passwords, private keys, secrets,
     auth headers, database URLs, and webhook URLs.
   - Check whether .env, credentials, generated keys, or local config files are tracked.
   - Ensure .gitignore protects sensitive files.
   - Do not print secret values in your final report. Redact them.

3. Authentication and authorization
   - Review login/session/auth middleware.
   - Check every API route, server action, mutation, write endpoint, admin
     action, and protected resource.
   - Verify data-modifying operations require auth.
   - Verify users can only access their own data unless explicitly intended.
   - Look for IDOR, missing ownership checks, role bypasses, and unsafe trust
     of client-provided IDs.

4. Input validation and injection
   - Check user-controlled inputs for SQL, NoSQL, command, path, or header injection.
   - Ensure file paths, URLs, redirects, uploads, search params, and request
     bodies are validated.
   - Add schema validation or defensive checks where missing.

5. Web security
   - Review CORS, cookies, CSRF, redirects, headers, iframe policy, CSP, XSS
     risks, and unsafe HTML rendering.
   - Check whether secure cookie flags, same-site behavior, and HTTPS
     assumptions are production-safe.
   - Look for dangerous use of innerHTML, markdown rendering, unsanitized HTML,
     or script injection.

6. API and server hardening
   - Check rate limiting, error handling, logging, public endpoints, SSRF risk,
     open redirects, debug modes, and environment checks.
   - Ensure errors do not leak secrets, stack traces, tokens, internal paths,
     or private config.
   - Check network/service bindings if relevant.

7. Build/deploy config
   - Review framework config, environment variable usage, CI config,
     Docker/systemd/Vercel/hosting config if present.
   - Check for unsafe production defaults.

Execution plan:
1. Inspect the repo structure and identify the stack.
2. Run the smallest useful verification commands first: install status if
   needed, typecheck, lint, tests, build, package audit.
3. Perform the security review.
4. Implement safe fixes.
5. Re-run verification.
6. Produce a final report.

Final response format:
## Summary
- Overall risk level: Critical / High / Medium / Low
- What was fixed
- What remains

## Findings Fixed
For each:
- Severity
- File/location
- Issue
- Fix made
- Verification

## Findings Needing Human Decision
For each:
- Severity
- Issue
- Why no automatic fix was made
- Recommended next step

## Verification
List exact commands run and results.

## Production Checklist
Short checklist of anything still required before deployment.

Example command

CLI flags can vary by setup, so treat this as an example pattern. The important part is running from the repo root with the full prompt.

cd your-repo && codex exec "[paste prompt]"

What Codex should check

These are the high-risk areas beginners usually miss before shipping: dependencies, secrets, auth and ownership, input validation, web security headers, server hardening, and deploy config.

Production gate: ship only when these are true

• No critical or high findings remain unresolved
• No secrets, tokens, or credentials are exposed
• Auth and ownership checks are verified on write paths
• Tests, typecheck, lint, and build pass cleanly
• Human-reviewed findings are documented before deploy

Beginner rule: Codex helps, you still approve

Let Codex do the boring inspection and the safe fixes, then read the final report. If it says a finding needs a human decision, pause and understand the tradeoff before deploying.