Web and API security
How to review HTTP security headers
Inspect response headers, understand the role of major browser protections, review CORS and caching, and verify the final production response.
Document summary
A practical header-review checklist covering content restrictions, framing, MIME handling, transport, referrers, permissions, CORS, cookies, and caching.
Key takeaways
- Review the actual production response, not only application configuration.
- Header values must match the resources and behavior the site really needs.
- CORS, cookies, caching, and security headers should be evaluated together.
Inspect the final response seen by the browser
Headers can be added, removed, or replaced by the application, web server, reverse proxy, content delivery network, or security service. Inspect the final public response for the relevant page and status code.
Check normal pages, redirects, errors, downloads, and API responses because different routes may use different policies.
Review core browser security headers
| Header | Purpose | Review point |
|---|---|---|
| Content-Security-Policy | Restricts scripts, styles, frames, and other resources | Start with the real resource inventory and reduce unsafe allowances |
| X-Content-Type-Options | Prevents MIME type guessing | Use nosniff for modern web responses |
| Referrer-Policy | Controls referrer information | Choose a policy that balances privacy and analytics needs |
| Permissions-Policy | Limits browser features | Disable camera, microphone, geolocation, and other unused capabilities |
| Strict-Transport-Security | Keeps future visits on HTTPS | Enable only after HTTPS is reliable for the intended domain scope |
| frame-ancestors or X-Frame-Options | Controls embedding | Use CSP frame-ancestors for flexible modern policy |
Treat Content Security Policy as an application policy
A restrictive policy can block required resources, while an overly broad policy provides little protection. Build CSP from an inventory of scripts, styles, images, frames, connections, workers, and form destinations.
Use report-only testing before enforcing a major policy change. Remove inline script and style dependencies where practical.
Review CORS as an API access decision
CORS tells browsers which origins may read a response. It is not authentication and does not prevent servers or command-line clients from sending requests.
Avoid reflecting arbitrary origins. Do not combine wildcard origins with credentialed access. Return only the methods and headers the API needs.
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: trueAccess-Control-Allow-Origin: https://app.example
Vary: OriginVerify across environments and routes
- 1
Inspect production HTTPS responses.
- 2
Check redirects and error pages.
- 3
Test CSP in the browser console.
- 4
Verify CORS with allowed and disallowed origins.
- 5
Review cookie flags after login.
- 6
Re-run the check after proxy, CDN, or deployment changes.
