HTTP Header Checker

1. Core HTTP Response Security Directives

Per the MDN HTTP Headers reference, security headers work because browsers are built to honor them by default — a header like X-Frame-Options doesn't need a plugin or extra client-side code to take effect; the browser itself enforces the restriction the moment it reads the header. This makes them a genuinely low-effort, high-leverage layer: a handful of correctly configured response headers close off entire categories of attack (clickjacking, MIME-sniffing exploits, mixed-content downgrades) with zero application code changes.

2. Strict-Transport-Security (HSTS) Preloading Rules

A basic HSTS header protects a domain after the browser's first HTTPS visit. HSTS "preloading" goes further — submitting a domain to browser vendors' preload lists means the HTTPS-only enforcement applies from a user's very first visit ever, closing the small window a basic HSTS header leaves open. Preloading is effectively permanent (removal from the list is slow and disruptive), so it's worth testing HSTS thoroughly on a domain before committing to preload submission.

3. Headers vs Certificate Validity

HSTS and other headers control browser behavior around an existing HTTPS connection — they don't address whether the underlying TLS certificate itself is valid, correctly issued, or approaching expiration. Those are separate, equally important checks: verify certificate health with the SSL Certificate Checker alongside your header audit for a complete picture.

4. Header Delivery via Nimbica Static Edge

Nimbica can attach security headers at the edge layer alongside static HTML delivery, meaning the header configuration is enforced consistently across every edge node without needing origin-server-level configuration for each one. This is a delivery-consistency benefit — deciding which headers and directive values are appropriate for your specific site (especially CSP, which needs to match your actual script/resource sources) still requires deliberate configuration.

5. How to Use This Checker

1. Scan your site and review each header flag — HSTS, CSP, X-Frame-Options, X-Content-Type-Options.
2. Prioritize HSTS and X-Frame-Options/X-Content-Type-Options first — they're lower-risk to add than CSP, which needs careful testing to avoid breaking legitimate scripts.
3. Add missing headers via your web server config (.htaccess/nginx.conf), a security plugin, or your CDN's edge configuration.
4. Re-scan after each change and test the live site thoroughly — especially after adding CSP, which is the header most likely to break something if misconfigured.

6. Common Mistakes

• Adding a strict CSP without testing thoroughly first. An overly restrictive CSP can silently break embedded widgets, third-party scripts, or inline styles — test in report-only mode before enforcing.
• Enabling HSTS preload before confirming HTTPS works flawlessly site-wide. Preload removal is slow and disruptive — only submit once you're confident every subdomain and page serves correctly over HTTPS.
• Treating a clean header scan as proof of overall security. These headers address specific browser-level attack vectors — they say nothing about server hardening, plugin vulnerabilities, or application-layer security.

7. Limitations

This tool checks the presence and basic value of a handful of common security headers on one URL — it doesn't validate the semantic correctness of a CSP policy's directive values, doesn't check every possible security header, and doesn't test how headers behave across different pages or subdomains on the same site. A clean result here is a good sign, not a comprehensive security certification.