Security and Hardening

Security-first development practices for web applications. Treat every external input as hostile.

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

Threat Model First

Before hardening, spend five minutes thinking like an attacker:

1. Map the trust boundaries. Where does untrusted data cross into your system?
2. Name the assets. What's worth stealing or breaking?
3. Run STRIDE over each boundary:

| 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 | | Repudiation | Can an action be denied later? | Audit logging of security events | | Information disclosure | Can data leak? | Encryption, field allowlists | | Denial of service | Can it be overwhelmed? | Rate limiting, input size caps | | Elevation of privilege | Can a user gain rights they shouldn't? | Authorization checks, least privilege |

The Three-Tier Boundary System

Always Do (No Exceptions)

• Validate all external input at the system boundary
• Parameterize all database queries — never concatenate user input into SQL
• Encode output to prevent XSS
• Use HTTPS for all external communication
• Hash passwords with bcrypt/scrypt/argon2
• Set security headers (CSP, HSTS, X-Frame-Options)
• Use httpOnly, secure, sameSite cookies for sessions
• Run npm audit before every release

Ask First (Requires Human Approval)

• Adding new authentication flows
• Storing new categories of sensitive data
• Adding new external service integrations
• Changing CORS configuration
• Adding file upload handlers

Never Do

• Never commit secrets to version control
• 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

OWASP Top 10 Prevention Patterns

Injection (SQL, NoSQL, OS Command)

// BAD: SQL injection via string concatenation
const query = `SELECT * FROM users WHERE id = '${userId}'`;

// GOOD: Parameterized query
const user = await db.query('SELECT * FROM users WHERE id = $1', [userId]);

// GOOD: ORM with parameterized input
const user = await prisma.user.findUnique({ where: { id: userId } });

Broken Authentication

// Password hashing
import { hash, compare } from 'bcrypt';

const SALT_ROUNDS = 12;
const hashedPassword = await hash(plaintext, SALT_ROUNDS);
const isValid = await compare(plaintext, hashedPassword);

// Session management
app.use(session({
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: {
    httpOnly: true,
    secure: true,
    sameSite: 'lax',
    maxAge: 24 * 60 * 60 * 1000,
  },
}));

Cross-Site Scripting (XSS)

// 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 first
import DOMPurify from '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 resource
  if (task.ownerId !== req.user.id) {
    return res.status(403).json({
      error: { code: 'FORBIDDEN', message: 'Not authorized' }
    });
  }

  const updated = await taskService.update(req.params.id, req.body);
  return res.json(updated);
});

Input Validation Patterns

Schema Validation at Boundaries

import { z } from 'zod';

const CreateTaskSchema = 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(),
});

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(),
      },
    });
  }
  const task = await taskService.create(result.data);
  return res.status(201).json(task);
});

Rate Limiting

import rateLimit from 'express-rate-limit';

// General API rate limit
app.use('/api/', rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 100,
  standardHeaders: true,
  legacyHeaders: false,
}));

// Stricter limit for auth endpoints
app.use('/api/auth/', rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 10,
}));

Secrets Management

.env files:
  ├── .env.example  → Committed (template with placeholder values)
  ├── .env          → NOT committed (contains real secrets)
  └── .env.local    → NOT committed (local overrides)

.gitignore must include:
  .env
  .env.local
  .env.*.local
  *.pem
  *.key

Always check before committing:

git diff --cached | grep -i "password\|secret\|api_key\|token"

Security Review Checklist

• [ ] Passwords hashed with bcrypt/scrypt/argon2 (salt rounds ≥ 12)
• [ ] Session tokens are httpOnly, secure, sameSite
• [ ] Login has rate limiting
• [ ] Every endpoint checks user permissions
• [ ] Users can only access their own resources
• [ ] All user input validated at the boundary
• [ ] SQL queries are parameterized
• [ ] HTML output is encoded/escaped
• [ ] No secrets in code or version control
• [ ] Sensitive fields excluded from API responses
• [ ] Security headers configured (CSP, HSTS, etc.)
• [ ] CORS restricted to known origins
• [ ] Dependencies audited for vulnerabilities
• [ ] Error messages don't expose internals

Verification

After implementing security-relevant code:

• [ ] npm audit shows no critical or high vulnerabilities
• [ ] 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
• [ ] Error responses don't expose internal details
• [ ] Rate limiting active on auth endpoints