How Do You Systematically Review Code for Security Vulnerabilities Before They Ship?

The Midnight Security Incident Nobody Planned For

It starts with a Slack ping at 2 AM. A customer reports unauthorized access to their account. You dig into the logs and find it: a developer hardcoded a Supabase service-role key in a Next.js API route three weeks ago. The key leaked into a public GitHub repo during a rushed deploy. By the time you rotate it, the attacker has already exported user data.

This scenario is not hypothetical. It happens in small teams shipping fast with AI-generated code. The code works, the tests pass, the feature ships — but nobody ran a structured security review. The AI assistant that wrote the code optimized for functionality, not for the dozen subtle security mistakes that live in authentication flows, input handling, and secret management.

If you build AI agents or use AI coding assistants to ship features, you have likely felt this tension: the speed of AI-assisted development creates a gap between "code that works" and "code that is safe to deploy." A single missed validation, a concatenated SQL string, or a token stored in localStorage instead of an httpOnly cookie can become a production incident.

The core problem is not that developers do not care about security. It is that security review is a checklist discipline, and checklists are easy to skip when you are moving fast. What most teams need is not a vague reminder to "think about security" — they need a concrete, actionable checklist that covers the specific patterns where vulnerabilities hide.

Why Security Gaps Appear in AI-Assisted Workflows

AI coding tools are excellent at generating functional code. They are less reliable at generating secure code by default. Here is why the gap exists:

• Training data includes insecure patterns. The internet is full of tutorials that hardcode API keys, use string concatenation for SQL, and store tokens in localStorage. AI models reproduce these patterns because they are statistically common.
• Speed removes review pressure. When an AI agent generates a working feature in minutes, the human instinct is to ship it, not to spend another hour auditing it line by line.
• Security is context-dependent. A pattern that is safe in one context (e.g., a read-only public endpoint) is dangerous in another (e.g., an admin deletion endpoint). AI tools often miss this nuance.
• Checklists are fragmented. Security best practices are spread across OWASP guides, framework documentation, blog posts, and internal wikis. No single source covers the patterns relevant to a modern full-stack AI-assisted workflow.

The result is a predictable set of recurring vulnerabilities:

1. Hardcoded secrets in source code
2. Missing or weak input validation
3. SQL injection through string concatenation
4. Tokens stored in localStorage (vulnerable to XSS)
5. Missing authorization checks on sensitive endpoints
6. No rate limiting on expensive API routes
7. Sensitive data leaked in logs or error messages
8. Missing CSRF protection on state-changing operations

A good solution should make it trivial to check each of these categories, provide concrete pass/fail examples, and fit into the workflow of someone using AI coding tools — not replace the developer, but give them a structured review surface.

What the Security-Review Skill Provides

The security-review skill is a structured checklist and pattern library designed for developers who use AI coding assistants. It comes from the everything-claude-code repository, a collection of reusable skills for Claude Code workflows.

This skill is not a scanner, a linter, or a runtime tool. It is a structured reference that an AI agent (or a human) can consult during code review to verify that common security patterns are followed. Think of it as a detailed, code-specific security checklist that covers eight major categories:

The Eight Security Domains It Covers

1. Secrets Management — Detecting hardcoded API keys, verifying environment variable usage, checking .gitignore for .env files, and confirming production secrets are stored in hosting platforms.

2. Input Validation — Enforcing schema-based validation (e.g., with Zod), restricting file uploads by size, type, and extension, and ensuring error messages do not leak internal details.

3. SQL Injection Prevention — Verifying that all database queries use parameterized queries or ORM methods, with no string concatenation in SQL strings.

4. Authentication and Authorization — Checking token storage (httpOnly cookies vs. localStorage), verifying authorization checks before sensitive operations, and confirming Row Level Security is enabled where applicable.

5. XSS Prevention — Ensuring user-provided HTML is sanitized (e.g., with DOMPurify), Content Security Policy headers are configured, and dangerouslySetInnerHTML is used safely.

6. CSRF Protection — Verifying CSRF tokens on state-changing operations, SameSite cookie attributes, and double-submit cookie patterns.

7. Rate Limiting — Confirming rate limits exist on API endpoints, with stricter limits on expensive operations like search or file processing.

8. Sensitive Data Exposure — Checking that logs do not contain passwords, card numbers, or tokens, and that error messages returned to users do not expose stack traces or internal paths.

Each category includes concrete FAIL and PASS code examples in TypeScript, making it easy to compare your current code against the expected pattern. For example, the skill shows exactly what a hardcoded secret looks like versus the correct environment variable approach, with verification steps you can check off.

How It Fits Into a Workflow

The skill is designed to be activated in specific situations. It is not meant to run on every commit. The recommended activation triggers are:

• Implementing authentication or authorization logic
• Handling user input or file uploads
• Creating new API endpoints
• Working with secrets or credentials
• Implementing payment features
• Storing or transmitting sensitive data
• Integrating third-party APIs

In practice, you might use it like this: you ask your AI coding assistant to build a user registration endpoint. After the code is generated, you (or the agent) activate the security-review skill and run through the checklist. The skill flags that the generated code stores the JWT in localStorage — a FAIL pattern — and you switch to httpOnly cookies before shipping.

When This Skill Is Useful — and When It Is Not

Good Fit

• You are building a web application with user accounts, payments, or sensitive data. The checklist covers the exact patterns that appear in these contexts.
• You use AI coding assistants and want a structured way to audit generated code. The skill gives you a concrete review surface instead of relying on memory.
• You are a solo developer or small team without a dedicated security engineer. The checklist compensates for the lack of specialized security review.
• You are building with Next.js, Supabase, Express, or similar modern stacks. The code examples use these technologies directly.

Poor Fit

• You need automated, runtime security scanning. This skill is a reference checklist, not a tool that runs in CI/CD or monitors production traffic.
• You are working in a language or framework not covered by the examples. The code samples are TypeScript/JavaScript-centric. The principles transfer, but the specific patterns may not.
• You need compliance certification (SOC 2, HIPAA, PCI-DSS). This skill covers common web application vulnerabilities, not regulatory compliance frameworks.
• You are looking for dependency vulnerability scanning. This skill focuses on application-level code patterns, not third-party package vulnerabilities.

What to Inspect Before Using It

Before integrating this skill into your workflow, consider the following:

Repository Signals

• The everything-claude-code repository has a large number of stars, indicating broad community interest. However, the fork count is listed as zero, which may suggest the repository is used primarily as a reference rather than a forked-and-modified resource.
• The repository license is listed as "Sponsors," which may indicate a sponsorship or patronage model. Review the license terms to understand your obligations.
• The security level is marked as "Low," which likely refers to the repository's own security posture or classification, not the skill's effectiveness.

Content Quality

• The skill's checklist is detailed and includes concrete code examples with FAIL/PASS comparisons. This is more actionable than abstract security advice.
• The examples use modern tools (Zod for validation, DOMPurify for sanitization, Supabase RLS) that are common in current AI-assisted development stacks.
• The skill does not cover every possible vulnerability class. For example, it does not address server-side request forgery (SSRF), insecure deserialization, or cryptographic implementation flaws. If your application involves these areas, you will need additional review resources.

Integration Context

• The skill is designed for use with Claude Code workflows, but the checklist itself is framework-agnostic in principle. You can use it as a manual review guide regardless of your AI tooling.
• There are no installation commands provided. The skill is a reference document (SKILL.md) that you consult, not a package you install.
• The skill does not modify your code. It provides patterns and verification steps. You (or your AI agent) must apply the changes.

Practical Example: Reviewing a Payment Endpoint

Suppose your AI assistant generates this payment endpoint:

export async function POST(request: Request) {
  const { cardNumber, amount, userId } = await request.json()
  
  // Process payment
  const result = await stripe.charges.create({
    amount,
    currency: 'usd',
    source: cardNumber,
  })
  
  console.log('Payment processed:', { cardNumber, amount, userId })
  
  return Response.json({ success: true, chargeId: result.id })
}

Running the security-review checklist against this code would flag:

• Input Validation (FAIL): No schema validation on cardNumber, amount, or userId. A malicious user could send negative amounts or non-numeric values.
• Sensitive Data Exposure (FAIL): The full card number is logged to the console. This violates PCI-DSS and creates a data leak risk.
• Authentication (FAIL): No verification that the request is from an authenticated user. Anyone can call this endpoint.
• Rate Limiting (FAIL): No rate limiting on a payment endpoint, which is an expensive operation and a target for abuse.
• CSRF Protection (FAIL): No CSRF token verification on a state-changing POST request.

After applying the skill's patterns, the corrected version would include Zod validation, redacted logging, authentication middleware, rate limiting, and CSRF verification. The checklist makes these gaps visible in a structured way.

Summary

Security review is a discipline that benefits from structure. When you are shipping fast with AI-generated code, having a concrete checklist that covers the eight most common vulnerability categories — secrets, input validation, SQL injection, authentication, XSS, CSRF, rate limiting, and data exposure — reduces the chance of shipping a preventable vulnerability.

The security-review skill provides that structure as a reusable reference document. It is not a replacement for automated security tooling, penetration testing, or compliance audits. It is a practical first-pass review surface that catches the patterns AI coding assistants most commonly get wrong.

If your workflow involves generating code with AI tools and shipping it to production, inspect this skill's checklist and evaluate whether its categories cover the risk areas in your application. The cost of a structured review is minutes. The cost of a missed vulnerability is measured in incident response, customer trust, and regulatory exposure.