security-baseline

# Security Baseline

Establish the security floor for any production website or web app. Stack-agnostic. Covers the things that should be in place before public launch and verified periodically after.

---

## When to use

- Pre-launch security review
- Setting up a new site or environment
- Periodic security audit (quarterly recommended)
- Onboarding a new vendor or third-party integration
- Responding to a security finding or report
- Hardening after an incident

## When NOT to use

- Active incident response (use `incident-response`)
- Code-level security review (use `code-review-web`)
- Email-specific authentication (SPF/DKIM/DMARC) (use `email-deliverability`)
- DNS-level security (CAA, DNSSEC) (use `domain-strategy`)
- Performance-related security (DDoS protection sizing) (use `performance-optimization`)

---

## Required inputs

- The site or app in scope (URLs, environments)
- The hosting platform and CDN
- Authentication method (if any)
- Third-party scripts and integrations
- Compliance context (PCI, SOC2, GDPR, etc., if applicable)
- Existing security tooling

---

## The framework: 6 layers

Security is layered. Each layer addresses a different attack surface.

### Layer 1: Transport security

How data moves from server to client.

- HTTPS everywhere. No HTTP variants serving content.
- TLS 1.2 minimum, TLS 1.3 preferred. Disable TLS 1.0 and 1.1.
- HSTS (Strict-Transport-Security) header set, with `includeSubDomains` and `preload` for high-confidence sites.
- Strong cipher suites only. Modern browsers handle this if you pick a modern config from your provider.
- Certificates from a trusted CA, monitored for expiration.

### Layer 2: Response headers

What the browser is told about your site.

| Header | Purpose | Default value |
|---|---|---|
| `Strict-Transport-Security` | Force HTTPS | `max-age=31536000; includeSubDomains` |
| `Content-Security-Policy` | Restrict resource loading | Site-specific |
| `X-Content-Type-Options` | Prevent MIME sniffing | `nosniff` |
| `X-Frame-Options` | Clickjacking protection | `DENY` or `SAMEORIGIN` |
| `Referrer-Policy` | Control referrer info | `strict-origin-when-cross-origin` |
| `Permissions-Policy` | Control browser features | Site-specific (camera, mic, etc.) |
| `Cross-Origin-Opener-Policy` | Process isolation | `same-origin` (where compatible) |
| `Cross-Origin-Embedder-Policy` | Cross-origin restrictions | `require-corp` (where applicable) |

CSP deserves its own attention. See the framework section below.

### Layer 3: Authentication and authorization

How users prove who they are and what they can do.

- Strong password requirements (length over complexity rules; allow long passphrases)
- Account lockout or rate limiting on login
- 2FA available, required for admin accounts
- Session tokens: short-lived, secure, HttpOnly cookies
- Logout invalidates tokens server-side, not just client-side
- Password reset flows that don't reveal account existence
- Authorization checked on every request (don't rely on UI hiding)

### Layer 4: Input handling

How untrusted input is processed.

- Validate on the server (client validation is UX, not security)
- Parameterized queries for any database access (no string concatenation into SQL)
- Output encoding by context (HTML, JS, URL, CSS)
- File upload restrictions (type, size, location, scanning)
- Rate limiting on endpoints that could be abused
- CSRF tokens on state-changing requests

### Layer 5: Secrets management

Where credentials and keys live.

- No secrets in code, config files in repos, or environment variables baked into images
- Secrets in a dedicated secrets manager
- Different secrets per environment (no shared dev/prod secrets)
- Rotation schedule documented and followed
- Audit log of secret access
- Limited blast radius (each service has its own credentials, scoped narrowly)

### Layer 6: Operational security

How the team operates.

- Access controls reviewed quarterly (offboard immediately on departure)
- 2FA enforced on every admin account (hosting, DNS, registrar, code host, deploy tools)
- Audit logs enabled and reviewed
- Vulnerability scanning (dependencies, containers, infrastructure)
- Patch cadence defined
- Incident response runbook exists (see `incident-response`)
- Backups exist and are tested (see `backup-and-disaster-recovery`)
- Security contact published (security.txt at /.well-known/security.txt)

---

## Content Security Policy

CSP is the most powerful response header and the most often misconfigured. Worth its own treatment.

### What CSP does

CSP tells the browser which sources are allowed for various resource types: scripts, styles, images, frames, connections, etc. A strict CSP prevents most XSS attacks even when input handling has bugs.

### Two flavors

**Strict CSP (recommended):** uses `nonce-` or `hash-` based source allowlists. Inline scripts must be explicitly allowed via nonce.

```
Content-Security-Policy: script-src 'self' 'nonce-{random}' 'strict-dynamic'; object-src 'none'; base-uri 'self';
```

**Allowlist CSP (legacy):** lists allowed domains. Easier to set up, much weaker.

```
Content-Security-Policy: script-src 'self' https://trusted.com; ...
```

Strict CSP requires application changes (every inline script needs a nonce). The investment pays off.

### Roll out CSP gradually

1. Start with `Content-Security-Policy-Report-Only` to log violations without blocking.
2. Set up a violation report endpoint.
3. Watch for legitimate violations (third-party scripts, inline handlers).
4. Tune the policy.
5. Switch to enforcing mode once violations are mostly false positives.
6. Continue monitoring violation reports for new issues.

### Common CSP mistakes

- `unsafe-inline` in script-src. Defeats most of CSP's value.
- `unsafe-eval` in script-src. Often required by older libraries; refactor or replace.
- Wildcard sources (`*`). Defeats the policy.
- Allowing CDNs that host arbitrary user content. Attackers can upload scripts to the CDN.
- Not restri