# Security Headers: Add a Basic Response Hardening Layer

> What common security headers do and why launch pages should ship with a basic hardening baseline.

Canonical: https://softwareontheweb.com/tools/launch-readiness-checker/security-headers

Security headers do not replace secure code, but they reduce common browser-side risks.

A public launch should include a sensible baseline.

## What It Is

Security headers are HTTP response headers that instruct the browser how to handle framing, transport, MIME types, referrers, and related behavior.

```text
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
```

## Why It Matters

- They reduce avoidable exposure to common browser-level issues.
- They help enforce safer defaults across public traffic.
- They add trust and operational maturity to the deployment.

## Best Practices

1. Ship a minimal baseline such as HSTS, X-Content-Type-Options, and Referrer-Policy.
2. Add X-Frame-Options or CSP framing rules where appropriate.
3. Test headers after CDN and proxy layers, not just locally.

## Common Mistakes

- No security headers on production responses.
- Setting headers only on one route instead of the whole app.
- Breaking behavior with untested restrictive policies.

## Quick Checklist

- Baseline headers present.
- Values tested on the public response.
- No regressions introduced by policy rules.

## Final Takeaway

Security headers are part of disciplined delivery. They should not be an afterthought.

## Related
- [Home](https://softwareontheweb.com/)
- [Topics](https://softwareontheweb.com/topics)