security-and-hardening

Security and Hardening

Overview

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

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
• Encode output to prevent XSS (use framework auto-escaping, don't bypass it)
• Use HTTPS for all external communication
• 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 npm audit (or equivalent) 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