Content-Security-Policy Presence Check: What Agencies Should Know

A Content-Security-Policy presence check only tells an agency whether a CSP header appears in the public response; it does not prove the policy is complete, strict, or appropriate. That distinction matters because CSP can be useful, but a first-pass public check should not pretend to validate policy quality.

This tool checks public trust signals only. It is not a security audit, vulnerability scan, malware scan, or compliance check.

Use the Client Website Trust Check to see whether CSP presence is visible alongside other public trust signals. Use the free 10-domain agency audit for a broader portfolio review of SSL, DNS, domain expiry, CAA, and email-authentication signals.

Quick answer: Content-Security-Policy presence check

For agencies, a CSP presence check should answer:

• Is a Content-Security-Policy header visible on the checked public response?
• Is a Content-Security-Policy-Report-Only header visible instead?
• Does the visible policy appear very broad and worth developer review?
• Is the policy likely controlled by the CDN, host, framework, or app?
• Does the finding need careful wording in the client report?

Presence is a signal. Quality requires developer testing.

What Content-Security-Policy does at a high level

Content-Security-Policy is an HTTP response header that can tell browsers which sources are allowed for scripts, styles, images, frames, and other resources. MDN's Content-Security-Policy reference explains the header and directives.

For agencies, the important first-pass concept is simple: CSP is powerful and site-specific. It can help document resource rules, but a broken policy can also disrupt normal page behavior. That is why a public trust-signal check should report presence carefully.

Why agencies should treat CSP presence carefully

CSP is not like a simple yes/no file check. A site can have:

• No CSP header.
• A strict policy.
• A very broad policy.
• A report-only policy.
• Different policies on different routes.
• A policy injected by a CDN, host, or framework.
• A policy that works for one page and breaks another.

Agency reports should avoid saying that CSP presence proves the site is fully reviewed. The correct language is narrower: "CSP was detected" or "CSP was not detected on the checked response."

Presence vs quality: the important difference

Presence means a header is visible. Quality means the policy matches the application, routes, scripts, embeds, analytics, forms, checkout, and operational requirements. A passive public check can help with the first part. It cannot solve the second part.

Use this framing:

• Missing CSP: recommended developer review.
• CSP present: policy exists; deeper review may still be needed.
• Report-only CSP: the site may be testing a policy.
• Very broad CSP: developer should decide whether it is intentional.

Common CSP review findings

| CSP finding | What it may mean | What it does not prove | Agency action | |---|---|---|---| | Missing CSP header | No CSP signal on checked response | The whole site is not evaluated | Ask developer whether CSP is appropriate | | Very broad policy | Policy may allow many sources | It does not prove the policy is useless | Ask developer to confirm intent | | Report-only policy | Policy may be in testing mode | It does not mean enforcement is active | Ask whether rollout is planned | | CDN-set policy | Edge may inject header | It does not prove app routes match | Confirm owner and deployment layer | | Route-specific policy | Some pages may differ | Homepage result is not whole-site result | Check priority routes manually if needed |

Missing CSP header

If CSP is missing, the checked public response did not expose a CSP signal. Phrase it as a recommended improvement:

"Content-Security-Policy was not detected on the checked response. Developer should review whether a CSP is appropriate for this site."

Do not say the website is unsafe. Do not imply a final result. Missing CSP is a header hygiene finding.

Very broad policy

A CSP can be present but broad. For example, it may allow many hosts or broad resource patterns. A broad policy may be intentional during rollout, required by complex third-party scripts, or simply inherited from a template.

The agency action is to ask for review, not to rewrite the policy from a checklist.

Report-only policy

Content-Security-Policy-Report-Only lets teams observe potential policy effects without enforcing them. If report-only is visible, it may indicate a staged rollout or testing process.

In a report, say that report-only was observed and ask the developer whether an enforcement plan exists.

Policy set by hosting, CDN, or app framework

CSP may be set in:

• CDN rules.
• Managed hosting headers.
• Web server config.
• Framework middleware.
• Application route handlers.
• Plugins or platform settings.

Because ownership can be split, a missing or surprising policy should be routed to the person who controls the response layer.

When to involve a developer

Involve a developer when:

• CSP is missing and the client wants a policy.
• CSP is present but broad.
• CSP blocks expected behavior.
• The site uses many third-party scripts.
• The site has checkout, forms, portals, embedded apps, or analytics-heavy pages.
• Report-only policy appears without known ownership.

The handoff should include the URL checked and the exact visible header value when available.

CSP presence review checklist

• Check the public production URL.
• Record whether Content-Security-Policy is present.
• Record whether Content-Security-Policy-Report-Only is present.
• Avoid scoring policy quality from presence alone.
• Identify likely owner: CDN, host, framework, or app.
• Ask developer to review broad or missing policies.
• Use careful client-facing wording.
• Do not imply that CSP presence proves a final outcome.

What Client Website Trust Check reports

The Client Website Trust Check reports CSP presence as a public trust signal. It does not deeply validate CSP quality. It does not claim the policy is complete, strict, or appropriate for every route.

That is intentional. For agency client review, CSP presence is useful as a handover and header hygiene item, but deeper policy work belongs with a developer who can test the actual site behavior.

What this check cannot prove

We make a small number of public requests to the domain you submit. We do not log in, scan plugins, or crawl the site.

Some signals are only visible if the site responds normally on the public URL being checked. Sites behind WAFs, geo-blocks, or aggressive bot protection may show unknown rather than missing.

A passive public check cannot prove policy quality, route coverage, JavaScript compatibility, report endpoints, or whether the CSP matches business requirements. For CertPilot's public-check methodology and limitations, see the methodology page.

Related Resources

• Website header checklist for agencies
• Client website trust signals guide
• Client website trust checklist
• Website trust signals checker

Frequently Asked Questions

What is a Content-Security-Policy presence check?

A Content-Security-Policy presence check reports whether a CSP header is visible on the checked public response. It is a first-pass header hygiene signal for agencies. It does not prove that the policy is complete, strict, route-wide, or appropriate for the application.

Does CSP presence mean the policy is good?

No. CSP presence only means the public response includes a policy signal. The policy may still be broad, incomplete, too strict, route-specific, or in testing. A developer needs to review policy quality against the actual application and third-party services.

Does missing CSP mean the website is unsafe?

No. Missing CSP means the checked response did not expose that public header signal. Treat it as a recommended improvement or developer review item. Avoid broad conclusions in client reports because a passive presence check cannot evaluate the entire site.

Why might a site use report-only CSP?

A report-only policy lets a team observe what a CSP would affect before enforcing it. This can be useful during rollout because CSP changes can break scripts, styles, images, frames, or integrations if they are not tested carefully. Ask the developer whether report-only is intentional and whether an enforcement plan exists.

Can CertPilot deeply validate CSP quality?

No. CertPilot reports CSP presence as part of a passive public trust-signal review. It does not deeply validate directive quality, route coverage, browser behavior, or application-specific compatibility. Use the result to start a developer conversation.

Who should own CSP changes?

CSP changes should usually be owned by a developer, platform engineer, host, or CDN owner with context about scripts, embeds, forms, analytics, checkout, and route behavior. Agencies can flag missing or broad signals, but policy design needs testing.