Coding Standards: Security Review

Scope

This skill covers security checks only. Style and structure conventions come from the project's own detected patterns — defer to the backend-patterns cache (.claude/idev/backend-patterns/cache.md) and frontend-patterns cache (.claude/idev/frontend-patterns/cache.md), not from this skill. Detect and follow project conventions; do not impose generic ones.

Security Checks

Run these checks when writing or reviewing code that touches user input, auth, secrets, files, or data stores. Wording is stack-agnostic — apply the equivalent in the project's language/framework.

1. Injection (SQL, NoSQL, command, XSS)

• Never interpolate user input into queries — use parameterized queries, prepared statements, or the ORM's safe query API
• Never pass user input to a shell — use exec APIs that take an argument array, and whitelist allowed commands
• Never render user content as raw HTML — use text-content APIs, or sanitize with a vetted library before rendering
• Treat template/eval-style APIs fed by user input as injection sinks

2. Authentication & authorization

• Protected routes must enforce authentication; sensitive operations must also check authorization (role/ownership) server-side
• Compare passwords only against salted hashes (bcrypt/argon2-class), never plain text
• Verify tokens with secrets from configuration/environment, never hardcoded
• Prefer httpOnly cookies over script-accessible storage for session tokens
• Check object-level access: a valid user must not be able to read or mutate another user's records by changing an ID (IDOR)

3. Secrets handling

• No hardcoded API keys, passwords, connection strings, or tokens in source — load from environment or a secrets store
• Never log secrets or tokens; redact sensitive fields in structured logs
• Do not return password hashes, tokens, or internal identifiers in API responses — select response fields explicitly

4. Input validation at boundaries

• Validate all external input (request bodies, query params, headers, file uploads, webhook payloads) at the boundary, before business logic
• Validate type, range, length, and format; reject rather than coerce on failure
• File uploads: validate content type and size, strip path components from filenames, and resolve the final path to confirm it stays inside the intended directory (path traversal)
• Avoid deserialization modes that instantiate arbitrary types from input

5. Error-message and data leakage

• Error responses to clients must not expose stack traces, internal paths, query text, or framework internals — log details server-side, return a generic message
• CORS: restrict to known origins; never wildcard with credentials
• State-changing endpoints need CSRF protection when cookie-authenticated

Security Alert Format

When a security issue is found, report it like this:

SECURITY ALERT: [Vulnerability Type]
Location: [file:line]
Severity: CRITICAL | HIGH | MEDIUM | LOW
Issue: [brief description]
Risk: [what could happen if exploited]
Fix: [how to fix it]

Alert before writing the fix, so the user understands the risk even if they decline the change.

Security Checklist

Before completing work that touches input, auth, secrets, files, or queries:

• No hardcoded secrets, keys, or passwords
• All external input validated at the boundary
• Queries parameterized; no string-built SQL/commands
• No raw HTML rendering of user content (or sanitized)
• Authentication enforced on protected routes
• Authorization (role/ownership) checked before data access
• Sensitive data absent from logs and responses
• File uploads validated (type, size, name, resolved path)
• Error messages do not leak internals
• CORS/CSRF configured for the project's auth model