Essential HTTP security headers

HTTP security headers are browser instructions sent with a website response. They can reduce common risks, but a header is useful only when it fits the application and has been tested safely.

Use the Security Headers Checker

The three headers this checker reports

Content-Security-Policy can define which content sources a browser is allowed to load. It is powerful, but a policy should be designed around the application's real scripts, styles, frames, and third-party services.

Strict-Transport-Security tells supporting browsers to prefer HTTPS for a period of time. X-Frame-Options can help control whether a page is framed. CloudSpex currently reports whether these headers are present on the final safe HTTPS response.

Presence is not a full security review

A present header can still have a value that is unsuitable, too broad, or incompatible with the site's workflow. Conversely, an absent header may need a carefully tested implementation rather than a blind copy-and-paste fix.

The public checker intentionally reports a small allowlist of header-presence signals. It does not rate policy strength, expose raw response headers, or replace application security testing.

Make changes safely

Identify the layer that adds headers: application code, web server, CDN, reverse proxy, or hosting control panel. Change one policy at a time and test key user flows, embedded content, authentication, and third-party integrations.

Check the public HTTPS response after a deployment or proxy change.
Find the configuration owner for each header.
Use a report-only or staged approach where the platform supports it.
Test critical user flows before enforcing a restrictive policy.
Recheck after CDN, hosting, or application changes.

Keep HTTPS fundamentals in view

Security headers work alongside, not instead of, HTTPS certificate validity, DNS correctness, secure cookies, application access controls, and vulnerability management.

Use the result as one operational signal in a broader security review.

Frequently asked questions

Does a present CSP mean my site is secure?

No. CSP presence alone does not prove that the policy is appropriate or that the application has no other security issues.

Should I add HSTS immediately?

Confirm the entire site is reliably available over HTTPS first. An HSTS policy can make recovery harder if HTTPS is not ready.

Does CloudSpex show raw headers?

No. The public result exposes only a small sanitized allowlist of supported header signals.

Use public checks as a starting point

CloudSpex reads limited public-facing signals. It does not change DNS, website, certificate, or email settings. Confirm the responsible provider and test relevant changes before applying a remediation.