Is a Content Security Policy report-only header enforced?

No. Content-Security-Policy-Report-Only is used to monitor policy violations while a policy is refined. Browsers do not enforce it as a blocking policy.

Should every website use every security header?

No. Some controls are broadly useful, while permissions and cross-origin isolation policies depend on the site's features, embedded services, popups and browser support needs.

Why can two pages on the same website return different headers?

Headers can vary by route, CDN rule, application, login state, response status and deployment. This check describes only the final public response it received.

Public response · plain-English evidence

Free website security headers check.

Q: Do security headers prove a website is secure?

No. Response headers can reduce specific browser risks, but they cannot reveal every application vulnerability, configuration problem or authenticated user journey.

See which browser protections a public page sends, what each one does and which settings deserve a careful review before they change.

Check a page

Inspect one public response

Which page should we check?

Use a homepage or a specific public page. We follow its redirects and inspect the headers on the final response.

We request the public page much like a browser would. The result can vary by page, location, CDN rule, login state or deployment.

What this check actually does

One response. Eight careful interpretations.

We follow up to five public redirects, inspect the final response and keep the reading brief so a repeat visit does not keep fetching the same page.

Follow the public path

Every destination is checked before connection. Private networks and unusual web ports stay out of scope.

Read exact policy values

Core headers, optional isolation controls and obsolete signals are interpreted separately.

Keep changes contextual

Advice calls out trade-offs because a stricter header can break legitimate scripts, frames, popups or services.

Read the boundary

Headers are one layer of website security.

This check cannot find application vulnerabilities, test authenticated pages, prove compliance or confirm that every browser and route receives the same policy.

Reference points W3C Content Security Policy MDN HTTP header reference OWASP Secure Headers Project

Security header questions

Use the result without over-reading it.

Do security headers prove a website is secure?

No. They can reduce specific browser risks, but they cannot reveal every application vulnerability, configuration problem or authenticated journey.

Is a report-only CSP enforced?

No. Content-Security-Policy-Report-Only records violations while a policy is refined. It does not block content as an enforced CSP does.

Should every site use every header?

No. HSTS, CSP and nosniff are broadly useful when configured correctly. Permissions and cross-origin isolation policies depend more heavily on site architecture.

Why can pages on one site return different results?

Headers can vary by route, CDN rule, response status, application, login state and deployment. Check important page types separately.

Can adding a stricter header break a website?

Yes. CSP can block legitimate resources, HSTS can make broken HTTPS impossible to bypass, and isolation policies can affect popups or embedded content. Test first and keep a rollback path.