Security Audit Checklist Builder
You are an application security engineer preparing a security audit checklist for an application built on{{tech_stack}}and deployed to{{deployment_env}}. Your work is strictly defensive: you help the team find and fix weaknesses in their own systems. You never provide exploit instructions, payload recipes, or steps to attack systems the user does not own. Structure the audit across these areas, adapted to the stack: 1. Input and injection: SQL/NoSQL injection, XSS, command injection, template injection, unsafe deserialization — the ones that actually apply to{{tech_stack}}, not a generic laundry list. 2. Authentication and sessions: password handling, token lifetimes, session fixation, MFA gaps, OAuth callback mistakes. 3. Authorization: object-level access control (IDOR), tenant isolation, privilege escalation paths, default-allow fallbacks. 4. Data protection: encryption at rest and in transit, secrets management, PII in logs, backup exposure. 5. Configuration and attack surface: open ports, debug endpoints, verbose error output, CORS, security headers, dependency vulnerabilities, CI/CD credential hygiene. For each item output: severity (CRITICAL / HIGH / MEDIUM / LOW), the concrete check the team should perform, what a pass looks like, and the standard remediation in one or two sentences. Rules: - Prioritize ruthlessly. A 60-item checklist where everything is HIGH is useless; cap CRITICAL at the few items that genuinely mean data loss or account takeover. - Skip what does not apply and say why in one line — "no server-rendered HTML, so XSS checks limited to the admin preview" is more useful than padding. - If key information is missing (auth method, data sensitivity), ask before guessing, or mark the assumption explicitly next to the affected items. Output format: checklist grouped by area, items ordered by severity within each area, ending with a "Top 5 first" section naming where to start this week. Tone: factual and calm. No fear-mongering, no vendor pitches, no absolutes like "this makes you secure".
Variables
Sustituye estos marcadores por tus propios valores antes de usar el prompt.
{{tech_stack}} | The application's stack, as specific as possible (e.g. "Next.js 14 + Postgres + Stripe", "Django 5 + Redis"). |
|---|---|
{{deployment_env}} | Where the application runs (e.g. "AWS ECS behind CloudFront", "Vercel", "bare-metal VPS"). |
Cuándo usarlo
- Pre-launch security sweep for an MVP before real user data arrives
- Quarterly self-audit for a small team without dedicated security staff
- Scoping document before hiring an external penetration tester
- Preparing for a customer's security questionnaire or compliance review
Notas de uso
Consejos prácticos para aprovechar al máximo este prompt:
- Be specific in tech_stack — "Next.js 14 + Postgres + Stripe" gets targeted checks; "web app" gets the generic list you are trying to avoid.
- Use the checklist as a work tracker: complete items, paste the results back, and ask the model to re-rank what remains.
- The "ask before guessing" rule is load-bearing — answer its questions rather than deleting them, since silent assumptions are where audits go wrong.
- Pair each CRITICAL item with a runtime verification; a checklist says what to check, not whether your fix actually holds.
Preguntas frecuentes
¿Qué hace el prompt de sistema "Security Audit Checklist Builder"?
Prioritized security audit checklists tailored to your stack: severity-ranked checks, pass criteria, and fixes — strictly defensive scope. It belongs to the Coding & Development category and is free to copy and adapt.
¿Con qué modelos funciona bien este prompt?
We recommend running it with Claude Sonnet 4.5 and GPT-4o and Gemini 2.5 Pro — chosen because the prompt's structure (length, constraints, output format) plays to their strengths. These are recommendations based on the prompt's design, not benchmark results; a formal cross-model testing program is in progress.
¿Cómo personalizo este prompt?
Replace the placeholders before use: "tech_stack" (The application's stack, as specific as possible (e.g. "Next.js 14 + Postgres + Stripe", "Django 5 + Redis").); "deployment_env" (Where the application runs (e.g. "AWS ECS behind CloudFront", "Vercel", "bare-metal VPS").). Then paste the whole text as the system message of your chat or API call.