/tidy

Security Checklist

Three-tier classification for security-relevant changes. Load when the diff touches auth, input handling, external APIs, file uploads, or environment config, and always in tidy's Security audit mode (whole-codebase).

Contents

• Always do
• Ask first
• Never do
• OWASP quick reference
• Threat-model lens (audit mode)
• Vulnerability-class sweep (audit mode)

How to use this file

• Diff review (default): classify the security-relevant lines with Always do / Ask first / Never do / OWASP quick reference.
• Security audit mode (whole-codebase): also run the Threat-model lens and Vulnerability-class sweep across the named subsystem or repo. Walk by class, confirm each hit against real code, report only concrete exploit paths.

Always Do

For every change handling user input, authentication, or external data:

• Parameterize queries: never interpolate user input into SQL, ORM, or NoSQL queries
• Validate and sanitize input: schema validation (Zod, Yup) at system boundaries; reject unexpected shapes early
• Encode output: escape user content before rendering in HTML, URLs, or shell commands; use framework auto-escaping (React JSX, Next.js Server Components); avoid dangerouslySetInnerHTML
• Use HTTPS everywhere: enforce TLS for external calls; reject plain HTTP in API clients
• Hash passwords with bcrypt/scrypt/argon2: never plaintext, MD5, or SHA-family hashes for passwords
• Set security headers: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options: nosniff, X-Frame-Options: DENY
• Secure cookies: HttpOnly, Secure, SameSite=Strict (or Lax with justification)
• Audit dependencies: run npm audit or equivalent; flag known vulnerabilities in dependency changes

Ask First

Flag for human confirmation before merging; verify intent and scope:

• Auth flow changes: login, logout, session management, token refresh, OAuth callback
• Sensitive data storage: PII, payment info, health data, credentials; verify encryption at rest
• External service integrations: new API keys, webhook endpoints, third-party SDKs
• CORS config changes: verify allowed origins are intentional and minimal
• File upload handling: validate type, size limits, storage location; never serve uploads from the app domain without scanning
• Rate limiting changes: verify thresholds curb abuse without blocking legitimate users
• Permission or role changes: elevation, new roles, access control modifications
• Environment variable additions: no hardcoded secrets; in .env.example but not committed in .env

Never Do

Automatic critical severity if found in the diff:

• Commit secrets: API keys, tokens, passwords, private keys in source
• Log sensitive data: PII, tokens, passwords, or full request bodies in production logs
• Client-side-only validation: always validate server-side; client validation is UX, not security
• Disable security headers: removing CSP, HSTS, or X-Frame-Options without documented justification
• Use eval() or innerHTML with user data: use safe alternatives (JSON.parse, textContent, sanitized HTML)
• Store auth tokens in localStorage: use HttpOnly cookies; localStorage is accessible to any XSS
• Expose stack traces in production: generic error messages; log details server-side only
• Trust client-sent IDs for authorization: always verify ownership server-side

OWASP Quick Reference

Diff-mode shortcut: the highest-yield categories to eyeball on a changed line, named per OWASP Top 10:2025. In audit mode skip this and run the fuller Vulnerability-class sweep below (a superset).

Low-yield classes that cost the reader more than they return unless the exploit path is concrete: a race you cannot name the interleaving for, ReDoS on input an attacker cannot control, resource exhaustion with no amplification, an outdated library whose vulnerable function the code never calls, and log spoofing. Anthropic's open-source /security-review prompt excludes the same set for the same reason. Report them only as plausible with the missing piece named, or drop them.

Threat-model lens (audit mode)

Frame what you're protecting before sweeping, so the sweep is targeted, not generic:

• Assets: what's worth stealing or breaking? Credentials, PII, payment data, tenant isolation, admin capability.
• Entry points: where untrusted input enters: HTTP routes, webhooks, file uploads, message queues, CLI args, env, third-party callbacks.
• Trust boundaries: where does data cross from less-trusted to more-trusted (client to server, tenant to tenant, user to admin, external API to internal)? Check authz and validation at each.
• Actors: anonymous, authenticated, other tenant, insider, compromised dependency. Per finding ask "which actor reaches this, and what do they gain?"

A finding matters only if a real actor reaches a real asset through a real entry point. Drop speculative items.

Vulnerability-class sweep (audit mode)

Walk the codebase one class at a time: search for the pattern, then confirm each hit against the actual code before reporting. Search anchors are starting points, not exhaustive.

For each confirmed hit, report through the standard three-tier output with the vulnerability class, location, and exploit path.