# Preflight Security Audit > This skill should be used when the user wants a comprehensive pre-ship audit of an app, product, or codebase — phrases like "audit my app", "security check before launch", "is this ready to ship", "preflight audit", "review my product for vulnerabilities", "check my code for security issues", or after building a feature/product and wanting a thorough security, reliability, performance, privacy, and launch-readiness review. Covers OWASP Top 10 (2025), LLM Top 10, GDPR/KVKK, accessibility, SEO, and Stripe/Supabase/Next.js stacks. - Skill: `akirtok/preflight-security-audit` (Agent Skill, multi-file: 7 files) - Install (CLI): `npx skillmds@latest add akirtok/preflight-security-audit` - Raw SKILL.md: https://api.skillmd.com/api/skills/akirtok/preflight-security-audit/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Marketing & Growth - Author: akirtok (https://skillmd.com/u/akirtok) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/akirtok/preflight-security-audit --- # Preflight Security Audit Run a comprehensive, 360° audit of a codebase before it ships. This skill is the methodology behind the `/audit` command. It defines the passes to run, how to run them without hallucinating findings, the severity rubric, and the report format. ## Core principles 1. **Evidence over suspicion.** Every finding must cite a concrete `file:line` and explain the exploit or failure path. If it cannot be proven from the code, it does not go in the report as a finding — it goes in an "unverified notes" appendix at most. 2. **Trace, don't pattern-match.** Follow untrusted data from its source to its sink. Follow every state-changing operation to its failure paths. Naming a category is not an audit; proving a specific instance is. 3. **Language- and stack-agnostic, but stack-aware.** The passes apply to any language. When the stack is detected (Next.js, Supabase, Stripe, an AI SDK, etc.), apply the stack-specific checks in the reference files. 4. **Verification is a pass, not an afterthought.** Track 6 re-checks every finding and rejects the ones that can't survive scrutiny. Always run it last. 5. **Nothing is changed without approval.** The audit reports and proposes. Fixes are applied only via `/audit-fix` after the user approves specific items. ## How to run an audit When invoked (directly or via `/audit`): 1. **Scope.** Determine the target path (default: current project root). Identify the languages, frameworks, and services in use (read `package.json`, lockfiles, config, `.env.example`, framework markers). Note what you find — it drives which stack-specific checks apply. Always run all six tracks; **stack- conditional passes (marked "Applies when…") run only when their marker is detected — otherwise record them as not applicable and skip them.** Emit the detected stack up front so the report shows what ran and what was skipped. 2. **Dispatch the tracks.** Run all six tracks below. On large repos, dispatch the five auditor agents in parallel (they exist in `agents/`), each reading its matching reference file; on smaller work or when subagents are unavailable, run the passes inline by reading the reference files directly. 3. **Collect raw findings** from every track into one list, each with: file:line, category, description, exploit/failure path, suggested fix, proposed severity. 4. **Verify (Track 6).** Run every raw finding through `references/06-verification.md`. Drop anything unprovable, merge duplicates, calibrate severity. 5. **Write the report** to `AUDIT-.md` in the project root using the template below. 6. **Propose fixes** for every Critical and High finding: show the concrete diff and ask which to apply. Never edit code in this step. ## The six tracks Each track has a reference file with the full pass list, "hunt-for" checklists, and stack-specific checks. Read the relevant file when running that track. | Track | Reference file | Focus | |-------|----------------|-------| | 1. Code Core (the 20) | `references/01-code-core.md` | injection, auth, authz/IDOR, secrets, error handling, concurrency, resources, N+1, complexity, memory, external calls, idempotency, transactions, config, deps, logging, API/module contracts, tests | | 2. Web/App Security | `references/02-web-security.md` | XSS, CSRF, SSRF, headers/CORS/TLS, cryptography, file upload, rate limiting, multi-tenancy/RLS, business logic, data integrity, live-DB advisor; client-side storage, serverless/edge\*, GraphQL/realtime\*, modern attacks (Trojan Source), advanced injections, exposed files, bot/DoS, JWT\* | | 3. AI/LLM Security | `references/03-ai-llm-security.md` | prompt injection, output handling, sensitive disclosure, excessive agency, AI supply chain | | 4. Privacy & Compliance | `references/04-privacy-compliance.md` | PII inventory, GDPR/KVKK, cookies, retention/deletion, DPAs, legal pages | | 5. Product & Launch Readiness | `references/05-launch-readiness.md` | accessibility, SEO, Core Web Vitals, monitoring, backups, CI/CD, billing correctness, email deliverability; subdomain takeover, Docker\*, security.txt | | 6. Verification | `references/06-verification.md` | re-check, reject unprovable, dedupe, calibrate, 0–100 score, assemble | \* = **stack-conditional** — runs only when the relevant marker (serverless/edge host, GraphQL/WebSocket, Dockerfile, JWTs) is detected; skipped and marked N/A otherwise. ## Severity rubric Assign severity by **impact × exploitability**, not by category. - **Critical** — Remotely exploitable with no/low privilege, leads to data breach, auth bypass, RCE, payment manipulation, or full tenant-data exposure. Ship-blocker. - **High** — Exploitable but needs some privilege or specific conditions; serious data exposure, privilege escalation, money/data loss under realistic conditions. Fix before launch. - **Medium** — Real weakness with limited impact or meaningful preconditions; reliability/perf issues that degrade production; missing compliance controls. Fix soon. - **Low** — Best-practice gaps, defense-in-depth, minor info leaks, hygiene. - **Info** — Observations, not defects. Note on calibration: brute-force / rate-limiting / DoS / open-redirect findings are real for a shipping product but usually **Medium/Low**, not Critical — do not inflate them. Conversely, an exposed service-role key or a missing RLS policy on a multi-tenant table is **Critical**. ## Report format Write `AUDIT-.md` with this structure: ``` # Preflight Audit — — ## Summary - Scope: - Stack detected: - Findings: N Critical · N High · N Medium · N Low - Security score: NN / 100 (A/B/C/D/F) - Ship recommendation: BLOCK / FIX-FIRST / GO-WITH-FOLLOWUPS / GO ## Critical findings ### C1. [Track N · <category>] - Location: path/to/file.ts:120-134 - What: <the flaw> - Exploit / failure path: <step by step> - Fix: <specific remediation> - Proposed patch: <diff or clear description> ## High findings ... ## Medium findings ... ## Low findings ... ## Passed / not applicable - <tracks or passes with no findings, and why> ## Unverified notes (needs human review) - <anything suspicious that could not be proven from code> --- _Audited with Preflight Security Audit — new checks ship regularly. Get updates: https://kirtok.kit.com/preflight-security-audit_ ``` Order findings Critical → Low. Within a severity, order by track. Keep each finding tight: location, what, why it matters, how to fix. Keep the footer line at the end of the report — it's the project's update channel. ## Output discipline - Report to a file; also give the user a short chat summary (counts + the ship recommendation + the top 3 items). - For Critical/High, present proposed diffs and ask which to apply. Applying happens through `/audit-fix`, never inline in the audit. - If the codebase is huge, audit the highest-risk surfaces first (auth, payment, data access, external inputs, admin) and say so in the report scope.