Hardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Hardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services.
Security-first development practices for web applications. Treat every external input as hostile, every secret as sacred, and every authorization check as mandatory. Security isn't a phase — it's a constraint on every line of code that touches user data, authentication, or external systems.
When to Use
Building anything that accepts user input
Implementing authentication or authorization
Storing or transmitting sensitive data
Integrating with external APIs or services
Adding file uploads, webhooks, or callbacks
Handling payment or PII data
Process: Threat Model First
Controls bolted on without a threat model are guesses. Before hardening, spend five minutes thinking like an attacker:
Map the trust boundaries. Where does untrusted data cross into your system? HTTP requests, form fields, file uploads, webhooks, third-party APIs, message queues, and LLM output. Every boundary is attack surface.
Name the assets. What's worth stealing or breaking? Credentials, PII, payment data, admin actions, money movement.
Run STRIDE over each boundary — a quick lens, not a ceremony:
Threat
Ask
Typical mitigation
Spoofing
Can someone impersonate a user/service?
Authentication, signature verification
Tampering
Can data be altered in transit or at rest?
Integrity checks, parameterized queries, HTTPS
Repudiation
Can an action be denied later?
Audit logging of security events
Information disclosure
Can data leak?
Encryption, field allowlists, generic errors
Denial of service
Can it be overwhelmed?
Rate limiting, input size caps, timeouts
Elevation of privilege
Can a user gain rights they shouldn't?
Authorization checks, least privilege
Write abuse cases next to use cases. For each feature, ask "how would I misuse this?" — then make that your first test.
If you can't name the trust boundaries for a feature, you're not ready to secure it. This is OWASP — most breaches begin in design, not code.
A04: Insecure Design
The Three-Tier Boundary System
Always Do (No Exceptions)
Validate all external input at the system boundary (API routes, form handlers)
Parameterize all database queries — never concatenate user input into SQL
Hash passwords with bcrypt/scrypt/argon2 (never store plaintext)
Set security headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)
Use httpOnly, secure, sameSite cookies for sessions
Run the detected package manager's native audit against the committed lockfile before every release
Ask First (Requires Human Approval)
Adding new authentication flows or changing auth logic
Storing new categories of sensitive data (PII, payment info)
Adding new external service integrations
Changing CORS configuration
Adding file upload handlers
Modifying rate limiting or throttling
Granting elevated permissions or roles
Never Do
Never commit secrets to version control (API keys, passwords, tokens)
Never log sensitive data (passwords, tokens, full credit card numbers)
Never trust client-side validation as a security boundary
Never disable security headers for convenience
Never use eval() or innerHTML with user-provided data
Never store sessions in client-accessible storage (localStorage for auth tokens)
Never expose stack traces or internal error details to users
OWASP Top 10 Prevention Patterns
These are prevention patterns, not a ranking. For the 2021 ordering, see the quick-reference table in references/security-checklist.md.
Injection (SQL, NoSQL, OS Command)
// BAD: SQL injection via string concatenationconst query = `SELECT * FROM users WHERE id = '${userId}'`;
// GOOD: Parameterized queryconst user = await db.query('SELECT * FROM users WHERE id = $1', [userId]);
// GOOD: ORM with parameterized inputconst user = await prisma.user.findUnique({ where: { id: userId } });
// BAD: Rendering user input as HTML
element.innerHTML = userInput;
// GOOD: Use framework auto-escaping (React does this by default)return<div>{userInput}</div>;
// If you MUST render HTML, sanitize firstimportDOMPurifyfrom'dompurify';
const clean = DOMPurify.sanitize(userInput);
Broken Access Control
// Always check authorization, not just authentication
app.patch('/api/tasks/:id', authenticate, async (req, res) => {
const task = await taskService.findById(req.params.id);
// Check that the authenticated user owns this resourceif (task.ownerId !== req.user.id) {
return res.status(403).json({
error: { code: 'FORBIDDEN', message: 'Not authorized to modify this task' }
});
}
// Proceed with updateconst updated = await taskService.update(req.params.id, req.body);
return res.json(updated);
});
Security Misconfiguration
// Security headers (use helmet for Express)import helmet from'helmet';
app.use(helmet());
// Content Security Policy
app.use(helmet.contentSecurityPolicy({
directives: {
defaultSrc: ["'self'"],
scriptSrc: ["'self'"],
styleSrc: ["'self'", "'unsafe-inline'"], // Tighten if possibleimgSrc: ["'self'", 'data:', 'https:'],
connectSrc: ["'self'"],
},
}));
// CORS — restrict to known origins
app.use(cors({
origin: process.env.ALLOWED_ORIGINS?.split(',') || 'http://localhost:3000',
credentials: true,
}));
Sensitive Data Exposure
// Never return sensitive fields in API responsesfunctionsanitizeUser(user: UserRecord): PublicUser {
const { passwordHash, resetToken, ...publicFields } = user;
return publicFields;
}
// Use environment variables for secretsconstAPI_KEY = process.env.STRIPE_API_KEY;
if (!API_KEY) thrownewError('STRIPE_API_KEY not configured');
Server-Side Request Forgery (SSRF)
Any time the server fetches a URL the user influenced — webhooks, "import from URL", image proxies, link previews — an attacker can aim it at internal services (cloud metadata, localhost, private IPs).
// BAD: fetch whatever the user gives youawaitfetch(req.body.webhookUrl);
// GOOD: allowlist scheme + host, reject if ANY resolved IP is private, forbid redirectsimport { lookup } from'node:dns/promises';
import ipaddr from'ipaddr.js';
constALLOWED_HOSTS = newSet(['hooks.example.com']);
asyncfunctionassertSafeUrl(raw: string): Promise<URL> {
const url = newURL(raw);
if (url.protocol !== 'https:') thrownewError('https only');
if (!ALLOWED_HOSTS.has(url.hostname)) thrownewError('host not allowed');
// Resolve ALL records; a single private/reserved address fails the check.const addrs = awaitlookup(url.hostname, { all: true });
if (addrs.some((a) => ipaddr.parse(a.address).range() !== 'unicast')) {
thrownewError('private/reserved IP');
}
return url;
}
awaitfetch(awaitassertSafeUrl(req.body.webhookUrl), { redirect: 'error' });
The range() !== 'unicast' check covers loopback, link-local 169.254.169.254 (cloud metadata, the #1 SSRF target), private, and unique-local ranges across IPv4 and IPv6.
Caveat — this still has a TOCTOU gap.fetch resolves DNS again after the check, so an attacker using a short-TTL record can rebind to an internal IP between validation and connection. For high-risk surfaces, resolve once and connect to the pinned IP, or put a filtering agent in front (request-filtering-agent / ssrf-req-filter).
Input Validation Patterns
Schema Validation at Boundaries
import { z } from'zod';
constCreateTaskSchema = z.object({
title: z.string().min(1).max(200).trim(),
description: z.string().max(2000).optional(),
priority: z.enum(['low', 'medium', 'high']).default('medium'),
dueDate: z.string().datetime().optional(),
});
// Validate at the route handler
app.post('/api/tasks', async (req, res) => {
const result = CreateTaskSchema.safeParse(req.body);
if (!result.success) {
return res.status(422).json({
error: {
code: 'VALIDATION_ERROR',
message: 'Invalid input',
details: result.error.flatten(),
},
});
}
// result.data is now typed and validatedconst task = await taskService.create(result.data);
return res.status(201).json(task);
});
File Upload Safety
// Restrict file types and sizesconstALLOWED_TYPES = ['image/jpeg', 'image/png', 'image/webp'];
constMAX_SIZE = 5 * 1024 * 1024; // 5MBfunctionvalidateUpload(file: UploadedFile) {
if (!ALLOWED_TYPES.includes(file.mimetype)) {
thrownewValidationError('File type not allowed');
}
if (file.size > MAX_SIZE) {
thrownewValidationError('File too large (max 5MB)');
}
// Don't trust the file extension — check magic bytes if critical
}
Triaging Dependency Audit Results
Package-manager audits report known advisories; they do not prove a package is trustworthy or that vulnerable code is reachable. Use this decision tree:
The native package-manager audit reports a vulnerability
├── Severity: critical or high
│ ├── Is the vulnerable code reachable in runtime, build, test, or deployment paths?
│ │ ├── YES --> Fix immediately (update, patch, or replace the dependency)
│ │ └── NO (confirmed unused across those paths) --> Fix soon, but not a blocker
│ └── Is a fix available?
│ ├── YES --> Update to the patched version
│ └── NO --> Check for workarounds, consider replacing the dependency, or add to allowlist with a review date
├── Severity: moderate
│ ├── Reachable in production? --> Fix in the next release cycle
│ └── Dev-only? --> Fix when convenient, track in backlog
└── Severity: low
└── Track and fix during regular dependency updates
Key questions:
Is the vulnerable function actually called in your code path?
Is the dependency a runtime dependency or dev-only?
Is the vulnerability exploitable given your deployment context (e.g., a server-side vulnerability in a client-only app)?
When you defer a fix, document the reason and set a review date.
Supply-Chain Hygiene
Do not assume npm or treat the nearest manifest as the install root. Apply this order:
Find the installation boundary and manager. Use the workspace root that owns the lockfile, or an independent nested project only when it is outside that workspace. There, corroborate packageManager (when present), the lockfile, and CI; stop on disagreement or competing lockfiles. Pin the manager version and use the matrix in references/security-checklist.md.
Block dependency scripts before first execution. Bootstrap with scripts disabled or a documented fail-closed policy, inspect the pending script source, approve only the minimum required packages, commit the policy, then verify with a clean frozen/immutable install. Never blanket-approve scripts.
Audits only find known advisories; they do not catch a newly malicious or typosquatted package. Therefore:
Never apply forced audit remediation automatically (npm audit fix --force or equivalent). Preview the remediation, read changelogs, and test each resulting upgrade; forced fixes may cross declared dependency ranges.
Verify registry signatures and provenance where supported (npm audit signatures, pnpm audit signatures) and treat absence as a signal to investigate, not automatic proof of compromise.
Review new dependencies, lockfile diffs, and script-policy changes together — ownership, maintenance, release age, provenance, transitive graph, and typosquats such as cross-env vs crossenv (OWASP A06, LLM03).
If a secret is ever committed, rotate it. Deleting the line or rewriting history is not enough — assume it's compromised the moment it reaches a remote. Revoke and reissue the key first, then purge it from history.
Treat all model output as untrusted input (LLM05: Improper Output Handling). Never pass LLM output straight into eval, SQL, a shell, innerHTML, or a file path. Validate and encode it exactly as you would raw user input.
Assume prompts can be hijacked (LLM01: Prompt Injection). Untrusted text in the context window — a user message, a fetched web page, a PDF — can carry instructions. The system prompt is not a security boundary; enforce permissions in code, not in the prompt.
Keep secrets and other users' data out of prompts (LLM02 / LLM07). Anything in the context can be echoed back. Don't put API keys, cross-tenant data, or the full system prompt where the model can repeat it.
Constrain tool and agent permissions (LLM06: Excessive Agency). Scope tools to the minimum, require confirmation for destructive or irreversible actions, and validate every tool argument.
Bound consumption (LLM10: Unbounded Consumption). Cap tokens, request rate, and loop/recursion depth so a crafted input can't run up cost or hang the system.
Isolate retrieval data (LLM08: Vector and Embedding Weaknesses). In RAG, treat the vector store as a trust boundary: partition embeddings per tenant so one user can't retrieve another's data, and validate documents before indexing so poisoned content can't steer answers.
// BAD: trusting model output as a command or as markupconst sql = await llm.generate(`Write SQL for: ${userQuestion}`);
await db.query(sql); // arbitrary query execution
container.innerHTML = await llm.reply(userMessage); // stored XSS, via the model// GOOD: model output is data — parse defensively, then validate, then encodelet intent;
try {
intent = CommandSchema.parse(JSON.parse(await llm.replyJson(userMessage)));
} catch {
thrownewValidationError('unexpected model output'); // JSON.parse or schema failed
}
awaitrunAllowlistedAction(intent.action, intent.params);
container.textContent = await llm.reply(userMessage);
Security Review Checklist
### Authentication- [ ] Passwords hashed with bcrypt/scrypt/argon2 (salt rounds ≥ 12)
- [ ] Session tokens are httpOnly, secure, sameSite
- [ ] Login has rate limiting
- [ ] Password reset tokens expire
### Authorization- [ ] Every endpoint checks user permissions
- [ ] Users can only access their own resources
- [ ] Admin actions require admin role verification
### Input- [ ] All user input validated at the boundary
- [ ] SQL queries are parameterized
- [ ] HTML output is encoded/escaped
- [ ] Server-side URL fetches are allowlisted (no SSRF to internal services)
### Data- [ ] No secrets in code or version control
- [ ] Sensitive fields excluded from API responses
- [ ] PII encrypted at rest (if applicable)
### Infrastructure- [ ] Security headers configured (CSP, HSTS, etc.)
- [ ] CORS restricted to known origins
- [ ] Dependencies audited for vulnerabilities
- [ ] Error messages don't expose internals
### Supply Chain- [ ] One authoritative lockfile committed; CI uses that manager's frozen/immutable install
- [ ] Native audit triaged by reachability and fix risk; dependency install scripts blocked unless explicitly approved
- [ ] New dependencies reviewed (ownership, provenance, release age, transitive graph)
### AI / LLM (if used)- [ ] Model output treated as untrusted (no eval/SQL/innerHTML/shell)
- [ ] Secrets and other users' data kept out of prompts
- [ ] Tool/agent permissions scoped; destructive actions require confirmation
See Also
For detailed security checklists and pre-commit verification steps, see references/security-checklist.md.
Common Rationalizations
Rationalization
Reality
"This is an internal tool, security doesn't matter"
Internal tools get compromised. Attackers target the weakest link.
"We'll add security later"
Security retrofitting is 10x harder than building it in. Add it now.
"No one would try to exploit this"
Automated scanners will find it. Security by obscurity is not security.
"The framework handles security"
Frameworks provide tools, not guarantees. You still need to use them correctly.
"It's just a prototype"
Prototypes become production. Security habits from day one.
"Threat modeling is overkill here"
Five minutes of "how would I attack this?" prevents the design flaws no control can patch later.
"It's just LLM output, it's only text"
That "text" can be a SQL statement, a script tag, or a shell command. Treat it like any untrusted input.
"The audit passed, so the dependency is safe"
Audits match known advisories. They do not detect a newly malicious package or make unreviewed install scripts safe to execute.
Red Flags
User input passed directly to database queries, shell commands, or HTML rendering
Secrets in source code or commit history
API endpoints without authentication or authorization checks
Missing CORS configuration or wildcard (*) origins
No rate limiting on authentication endpoints
Stack traces or internal errors exposed to users
Dependencies with known critical vulnerabilities, competing lockfiles at one installation boundary, non-reproducible installs, or blanket-approved scripts
Server fetches user-supplied URLs without an allowlist (SSRF)
LLM/model output passed into a query, the DOM, a shell, or eval
Secrets, PII, or the full system prompt placed inside an LLM context window
Verification
After implementing security-relevant code:
The native audit has no unmitigated reachable critical/high findings; CI preserves the authoritative lockfile and blocks unreviewed dependency scripts
No secrets in source code or git history
All user input validated at system boundaries
Authentication and authorization checked on every protected endpoint
Security headers present in response (check with browser DevTools)
Error responses don't expose internal details
Rate limiting active on auth endpoints
Server-side URL fetches validated against an allowlist (no SSRF)
LLM/model output validated and encoded before use (if AI features present)
