Security Tool

Security Header Planner

Choose your application shape and generate a practical starter set of HTTP security headers to review before deployment.

Back to all developer tools

Application Type

Site Behavior

Allows embedding in framesLoads images from external domainsNeeds inline scripts

Recommended Starter Headers

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
X-Frame-Options: DENY
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self';; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none';

Treat this as a review starter, not a blind copy-paste. Tighten the Content Security Policy after listing every script, style, image, API, and frame dependency your application needs.

Security Headers Are Guardrails

HTTP security headers reduce entire classes of browser-side risk. They can limit framing, MIME sniffing, referrer leakage, permission prompts, and untrusted script execution. They are not a replacement for secure code, but they are a strong baseline for public web projects.

The most sensitive header is usually Content Security Policy. A strict CSP can break scripts, images, styles, or third-party embeds if it does not match the real application. Use this planner to create a starting point, then test it against your actual dependencies.

Practical Review Notes

Avoid allowing inline scripts unless you understand why they are needed.
If a site must be embedded in another page, document exactly which parent origins are allowed.
Revisit headers whenever you add analytics, forms, embeds, image CDNs, or third-party widgets.