ScrepyDocs

Website Security Headers

Understand missing HSTS, CSP, X-Frame-Options, and X-Content-Type-Options findings and plan safe header changes.

Security headers instruct browsers how to handle transport, scripts, embedded pages, and content types. Screpy provides Missing HSTS, Missing CSP, Missing X-Frame-Options, and Missing X-Content-Type-Options filters.

These findings concern defense in depth and user protection. Do not describe them as direct ranking factors, and do not deploy restrictive policies without testing the site's real resources and integrations.

Understand each header

  • Strict-Transport-Security (HSTS): tells browsers to use HTTPS for future requests after a secure visit.
  • Content-Security-Policy (CSP): limits which sources can load scripts, styles, images, frames, and other resources.
  • X-Frame-Options: helps prevent unauthorized framing; modern CSP frame-ancestors provides more flexible control.
  • X-Content-Type-Options: nosniff: prevents certain MIME-type guessing behavior.
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self'; img-src 'self' https: data:
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff

The example is illustrative, not a policy to copy unchanged. HSTS can affect every included subdomain, and an incorrect CSP can break analytics, payments, media, fonts, authentication, or application scripts.

Analyze missing headers

  1. Confirm the response is public HTTPS and inspect the final response after redirects.
  2. Group missing headers by hostname, route, asset type, and infrastructure layer.
  3. Identify where headers are controlled: application, web server, proxy, or edge configuration.
  4. Inventory required external origins and framing use cases before writing CSP.
  5. Check whether existing policies are valid and effective, not merely present.
  6. Prioritize public application and account surfaces according to security risk.

Roll out changes safely

Introduce CSP in report-only mode when practical, review violations, then enforce a minimal policy. Deploy HSTS only after HTTPS works reliably across the intended hostnames. Avoid broad CSP wildcards and unsafe directives added merely to stop breakage. Coordinate framing policy with legitimate embedded workflows.

Example decision

Marketing pages have all headers, while application routes lack them because a separate server handles responses. Fix the shared application response layer and test login, billing, uploads, analytics, and embedded support experiences before enforcing CSP.

Verify the result

Inspect final HTTP responses for representative routes, test critical user journeys, review browser security reports, and run another Screpy crawl. Verify behavior on redirects and error pages as well as successful HTML pages.

Understand what each header protects

Security headers reduce specific browser risks. They do not directly guarantee rankings, and their correct values depend on the application.

  • HSTS tells browsers to use HTTPS for future requests after a secure response is received.
  • CSP limits which resources and execution contexts the page may use.
  • X-Frame-Options controls legacy framing behavior; CSP frame-ancestors offers more flexible control.
  • X-Content-Type-Options with nosniff prevents certain MIME-type guessing.

Presence alone is not enough. A permissive CSP may provide little protection, while an overly strict policy can break scripts, styles, images, or embedded tools.

Roll out changes safely

Inventory required origins and inline behavior before enforcing CSP. Start with reporting where practical, review violations, and tighten deliberately. Test login, checkout, embeds, analytics, support widgets, and error pages. Apply headers consistently at the edge or server layer so cached and dynamic responses agree.

For HSTS, confirm every relevant subdomain supports HTTPS before using includeSubDomains or preload. Reversing a long max-age decision takes time for browsers that already cached it.

Expected crawl changes

After deployment, missing-header filters should fall across all covered page types. If only some URLs improve, compare CDN rules, application routes, static assets, and error responses. A sudden return of missing headers often points to a proxy, cache, or deployment configuration change.

Use MDN's Content Security Policy reference and HTTP header documentation when choosing values. Have application-security owners review policies before enforcing them.

Frequently asked questions

Do security headers improve rankings?

They are security controls, not a direct ranking guarantee. HTTPS and a trustworthy experience matter, but Screpy's header filters should guide security review rather than predict rankings.

Should every page use the same CSP?

Shared policies are easier to maintain, but some routes may require additional sources. Keep differences deliberate, minimal, and tested. Avoid a permissive global policy created only to stop violations.

On this page