When this skill is activated, always start your first response with the 🧢 emoji.

AppSec - OWASP Top 10

A practitioner's guide to application security based on the OWASP Top 10 2021. This skill covers the full lifecycle of web application security - from threat modeling to concrete code patterns for preventing injection, authentication failures, XSS, CSRF, SSRF, and misconfiguration. Designed for developers who need security guidance at the code level, not just as policy.

When to use this skill

Trigger this skill when the user:

• Asks how to prevent XSS, SQL injection, CSRF, or SSRF
• Implements or reviews authentication / session management
• Sets security headers (CSP, HSTS, X-Frame-Options, etc.)
• Validates or sanitizes user input
• Designs authorization logic or access controls
• Reviews code for OWASP Top 10 vulnerabilities
• Asks about output encoding, parameterized queries, or allowlists

Do NOT trigger this skill for:

• Network-level security (firewalls, VPNs, DDoS mitigation) - use a network security skill instead
• Secrets management / key rotation workflows - use a secrets management skill for those operational concerns

Key principles

1. Never trust user input - All data from the outside world is untrusted: HTTP bodies, headers, query params, cookies, uploaded files, and even data read back from your own database that originated from user input.

2. Defense in depth - Apply multiple independent security controls. If one layer fails, the next one stops the attack. Never rely on a single control.

3. Least privilege - Every component (user accounts, DB connections, API tokens, OS processes) should have only the permissions required and nothing more. Blast radius is limited by privilege scope.

4. Fail securely - When something goes wrong, default to the most restrictive outcome. Deny access on error, not grant it. Surface a generic error message to users, log the detail server-side.

5. Security by default - Secure configuration should be the default state. Developers should have to explicitly opt out of security controls, not opt in.

Core concepts

OWASP Top 10 2021

Threat modeling basics

Before writing security controls, answer four questions:

1. What are we building? - Draw a data-flow diagram including trust boundaries
2. What can go wrong? - Use STRIDE (Spoofing, Tampering, Repudiation, Info Disclosure, Denial of Service, Elevation of Privilege)
3. What are we going to do about it? - For each threat, decide: mitigate, accept, transfer, or eliminate
4. Did we do a good enough job? - Validate controls cover identified threats

Run threat modeling at design time, not after the code is written.

Security headers quick reference

See references/security-headers.md for full CSP directive reference and frame-ancestors vs X-Frame-Options comparison.

Common tasks

Prevent XSS with output encoding

Never insert untrusted data into HTML without context-aware encoding. The encoding rule depends on where in the HTML the data lands.

import DOMPurify from 'dompurify';
import { escape } from 'html-escaper';

// 1. HTML context - escape <, >, &, ", '
function renderComment(userInput: string): string {
  return escape(userInput); // safe: &lt;script&gt; not executed
}

// 2. When you must allow some HTML (e.g. rich text) - sanitize, don't escape
function renderRichText(userHtml: string): string {
  // DOMPurify strips disallowed tags/attributes; allowlist only what you need
  return DOMPurify.sanitize(userHtml, {
    ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a', 'p', 'ul', 'li'],
    ALLOWED_ATTR: ['href', 'title'],
  });
}

// 3. JavaScript context - use JSON.stringify, never template-inject
// WRONG:  <script>var name = "<%= userInput %>";</script>
// RIGHT:
function inlineJsonData(data: unknown): string {
  // JSON.stringify encodes <, >, & to unicode escapes automatically
  return `<script>var __DATA__ = ${JSON.stringify(data)};</script>`;
}

Set Content-Security-Policy: default-src 'self'; script-src 'self' so that even if encoding fails, inline scripts are blocked by the browser.

Prevent SQL injection with parameterized queries

Never concatenate user input into SQL strings. Always use parameterized queries or a safe ORM layer.

import { Pool } from 'pg';

const pool = new Pool();

// WRONG - string interpolation:
// const rows = await pool.query(`SELECT * FROM users WHERE email = '${email}'`);

// RIGHT - parameterized ($1, $2 for pg):
async function findUserByEmail(email: string) {
  const { rows } = await pool.query(
    'SELECT id, name, email FROM users WHERE email = $1',
    [email]
  );
  return rows[0] ?? null;
}

// RIGHT - ORM (Prisma example):
// const user = await prisma.user.findUnique({ where: { email } });

// Dynamic ORDER BY (column names can't be parameterized - use an allowlist):
const ALLOWED_SORT_COLUMNS = new Set(['name', 'created_at', 'email'] as const);

async function listUsers(sortBy: string, order: 'ASC' | 'DESC') {
  if (!ALLOWED_SORT_COLUMNS.has(sortBy as any)) {
    throw new Error(`Invalid sort column: ${sortBy}`);
  }
  const direction = order === 'DESC' ? 'DESC' : 'ASC'; // only two valid values
  const { rows } = await pool.query(
    `SELECT id, name FROM users ORDER BY ${sortBy} ${direction}`
  );
  return rows;
}

Implement CSRF protection

For detailed CSRF token pattern and SameSite cookie implementations, see references/auth-csrf-patterns.md.

Set security headers (CSP, HSTS, X-Frame-Options)

import helmet from 'helmet';
import { Express } from 'express';

function applySecurityHeaders(app: Express): void {
  app.use(
    helmet({
      // HSTS: force HTTPS for 2 years, include subdomains, add to preload list
      hsts: {
        maxAge: 63072000,
        includeSubDomains: true,
        preload: true,
      },

      // CSP: restrict resource loading to same origin; tighten per-app
      contentSecurityPolicy: {
        directives: {
          defaultSrc: ["'self'"],
          scriptSrc: ["'self'"],          // no inline scri