HTTP security headers tell a browser how to handle a response. Inspect the actual response values before you change a policy. The FindUtils Security Headers Analyzer grades the response headers you paste from curl -I or the browser's Network panel. It does not request your site, so the grade reflects exactly the block you copied.

This guide explains the headers, a manual review method, and how to feed the analyzer. A grade is a checklist of which security headers are present in one response. Do not use it alone to decide whether a production site is secure.

What Are HTTP Security Headers and Why Do They Matter?

HTTP security headers are instructions a web server sends with every response that tell the browser how to behave safely. They are a free, server-side defense layer against common attacks like cross-site scripting, clickjacking, and protocol downgrade.

Default headers depend on the application and its hosting configuration. A site can have a valid SSL certificate and still leave visitors exposed because the browser was never told to enforce HTTPS, block framing, or restrict scripts.

Analyze your security headers when:

  • You launch a site and want a baseline security posture before traffic arrives.
  • You handle user data — logins, forms, payments — where an attack has real consequences.
  • You pass a security review — clients and auditors increasingly check headers.
  • You changed your stack — a new host, CDN, or framework can silently drop headers.

How to inspect actual security headers

  1. Open the target page in your browser.
  2. Open the browser Network panel.
  3. Reload the page.
  4. Select the main document request.
  5. Read the response headers and final URL.
  6. Record the policy values before making a change.

Inspect the final response after redirects. Repeat the check on the specific route you want to assess. A homepage response does not establish the headers on a login page, download, or API route.

To get a grade, copy the response headers from step 5, or run curl -I https://example.com in a terminal, and paste the block into the Security Headers Analyzer. It checks ten headers, from Content-Security-Policy and Strict-Transport-Security to the Cross-Origin policies, and lists a recommendation for each one that is missing. The page makes no request to your site; the same code answers the FindUtils REST API and MCP tool.

Key HTTP Security Headers Explained

Each header defends against a specific class of attack. These are the ones the analyzer weights most heavily.

HeaderProtects againstWhat it does
Strict-Transport-Security (HSTS)Protocol downgrade, cookie hijackingForces browsers to use HTTPS only
Content-Security-Policy (CSP)Cross-site scripting (XSS)Restricts which scripts and resources can load
X-Frame-OptionsClickjackingStops your site being embedded in a hostile frame
X-Content-Type-OptionsMIME-type sniffingForces the browser to respect declared content types
Referrer-PolicyData leakageControls how much referrer information is shared
Permissions-PolicyFeature abuseLimits access to camera, microphone, geolocation, and more

The most impactful two are HSTS and CSP. HSTS directs supporting browsers to use HTTPS after the policy is known. CSP restricts selected resource loads and script execution. Neither header proves that the site is secure.

Separate a reference from a measured scan

MethodEvidence it providesLimit
FindUtils paste-headers gradeWhich of ten security headers are present in the response you pasted, with a recommendation per gapGrades one response you copied; counts presence, does not judge policy values, and does not test other routes
Browser response inspectionHeaders returned for one actual requestDoes not test all routes or application behavior
An independent scanFindings within that scanner's scopeRequires review of methods, targets, and date
Application security reviewTests of specific application controlsMust cover the relevant authentication and data flows

Start with the actual response. Record what you observed and which route returned it. Do not convert a tool label into evidence of a complete audit.

Common Security Header Mistakes and How to Fix Them

Mistake 1: Having No Security Headers at All

If a required policy is absent, identify which application or server sets that response. Add an appropriate value only after you check the route's requirements.

Mistake 2: A Content-Security-Policy That Allows Everything

A CSP that permits inline scripts and any source provides almost no protection. Fix it by writing a specific policy that lists only the sources your site actually uses.

Mistake 3: Setting HSTS Without Testing HTTPS First

HSTS forces HTTPS for a long duration. If HTTPS is not fully working, you can lock visitors out. Fix it by confirming your certificate and HTTPS work with the FindUtils SSL Certificate Checker before enabling HSTS.

Mistake 4: Headers Set on One Page but Not Sitewide

Headers added to the homepage only leave inner pages exposed. Fix it by setting headers at the server or CDN level so every response includes them.

Mistake 5: Never Re-scanning After Deploys

A framework upgrade or CDN change can silently drop headers. Inspect actual responses again after configuration or deployment changes.

Tools Used in This Guide

What a header grade cannot establish

A header scan checks one response. It does not test application authorization, stored data, all routes, or every browser interaction. A present CSP header can still allow unsafe sources. Read the policy before you act on a grade.

Check the MDN HSTS reference for first-visit and preload limits.

Do not add legacy headers only to improve a score

X-XSS-Protection is deprecated. Its old browser filter can create security problems in some cases. Do not enable it merely because a scanner marks it missing. Check MDN's X-XSS-Protection guidance and use an appropriate CSP.

FAQ

Q1: Is the security headers analyzer free to use? A: Yes. The FindUtils page grades the headers you paste with no signup and no usage limit. It makes no request to your site, so headers copied from a staging or internal host are safe to check there.

Q2: When should I use this security headers analyzer? A: After you copy the headers of a real response: at launch, after a host, CDN, or framework change, and before a security review. Paste the block, read which headers are missing, then read the policy values yourself. The grade counts presence; it does not judge whether a policy is strict enough.

Q3: What are the most important security headers to add first? A: Start with Strict-Transport-Security (HSTS) to enforce HTTPS, Content-Security-Policy (CSP) to block cross-site scripting, X-Frame-Options to prevent clickjacking, and X-Content-Type-Options to stop MIME sniffing.

Q4: Is it safe to scan my website's security headers online? A: The FindUtils page never requests your URL. It grades the header block you paste in your browser and sends nothing to FindUtils or to a third party. Online scanners that fetch a URL do send it to their servers, so with those use a public URL without credentials or secret query parameters.

Q5: Will adding security headers slow down my website? A: Headers add response bytes, and policies can change resource loading. Measure the application after a policy change rather than assuming no performance effect.

Q6: Can security headers break my site? A: A poorly written Content-Security-Policy can block your own scripts, and HSTS can lock out visitors if HTTPS is not working. Test changes carefully, evaluate CSP in report-only mode before enforcement, and confirm HTTPS before enabling HSTS.

Q7: Do security headers affect SEO? A: Indirectly. HTTPS enforcement and a secure user experience are part of technical SEO and trust signals. Headers themselves are not a direct ranking factor, but the security posture they create supports overall site quality.

Next Steps