Skip to contentLockpick
How it worksPricingDocs

Read

  • BlogPlain answers to common security questions
  • GuidesStep by step fixes for common setups
  • Security checksEvery check we run, explained

Learn

  • Learn with PickTwo-minute lessons on how sites get attacked
  • Lockpick for ClaudeCheck sites from Claude and other assistants
  • GlossaryThe words we use, in plain words

Company

  • ChangelogWhat changed, newest first
  • StatusWhether scans are running right now
  • Security and trustHow we check and what we never do
Sign inCheck it
Checks

Does your site send a Content Security Policy?

By Mark KashefPublished October 8, 2026

The Content Security Policy check looks for an enforced policy on your pages that limits where scripts may load from. It is a second barrier that helps when an injection bug slips through.

What does this check look at?

It looks at whether your pages send an enforced Content Security Policy that limits where scripts may load from. Report-only policies are read but not counted, because they do not block anything. MDN describes CSP as instructions that tell the browser to place restrictions on the things the site code is allowed to do.

Pulse and Deep scans both run it.

Curious what your site shows from outside? The quick check is free and needs no account.

Check it

What does a result mean?

What the report showsWhat it meansWhat to do
PassAn enforced policy restricts script sources.Nothing here, and the plugin, base and form rules check looks further.
AttentionNo enforced policy restricts scripts.Add one in report-only mode first, then enforce it.
Not testedThe page is not HTML, so the check does not apply.Nothing to act on.

Having a policy does not prove it stops cross-site scripting, and lacking one does not prove an injection bug exists. The scan never tries to inject a script. A clean result means nothing was found in what the scan read. It does not prove the problem is absent from parts the scan never sees.

How serious is a finding?

Treat this as a hardening gap. It makes an attacker’s job easier but gives them no path of its own, so fix it after anything more direct. Confidence starts low, because it is inferred from headers or declarations rather than shown directly. The report lists what to fix by how directly someone could use it, not by the severity label.

What does a confirmed finding have to show?

PartFor this check
Where it startsContent or a frame an attacker can influence
The protection that should stop itA browser protection header is missing or weak
What is reachedHow browsers treat your pages
What followsA hardening gap; no exploit was shown

Which standards does it relate to?

StandardReference
OWASP Top TenA02:2025 Security Misconfiguration
CWECWE-693
ASVSv5.0.0-3.4.3

Each one is a related control, not a verification. A scan sees what anyone online can see, so it never proves a whole requirement is met.

Fix it with your AI

Content Security Policy takes more care, because a strict one can block scripts your site needs, so it's usually added in steps. This prompt does the first step.

Fix prompt for any coding agent
Add a Content Security Policy to my site in report-only mode first. List every script, style, font, image and connection source my pages actually use, including analytics, payments and chat widgets. Write a Content-Security-Policy-Report-Only header that allows only those sources, preferring nonces for my own inline scripts over 'unsafe-inline'. Set it in my framework or host config and show me the header. Do not switch it to enforcing until I have checked the violation reports.

Once a week of normal use shows no surprising violations, rename the header to enforce it and run the scan again.

How to check

Say Atlas, our example app at atlas.example, sends a policy only in report-only mode. The check stays at attention until the enforcing header ships.

The free quick check covers this on your homepage with no account, and a Pulse scan from your account adds your scripts and public records. Pulse or Deep explains the difference.

Questions people ask

Does a Content Security Policy stop all cross-site scripting?

No. It limits the damage when injection happens, and a loose policy with unsafe-inline does much less. Fixing the injection bug still matters most.

Will a policy break my analytics or payment widget?

It can if you leave their sources out. That is why the first version runs in report-only mode, so you can see what it would block.

See what your site shows from outside

A quick check reads your homepage the way a visitor would and gives you a score. No account needed.

Check your site

Related pages

  • Does your Content Security Policy also lock down plugins, base and forms?
  • Can other sites show your pages inside a frame?
  • Does your browser code mix untrusted input with risky methods?

Sources

  1. Content Security Policy (CSP) MDN Web Docs, read on October 7, 2026
  2. How we rate findings Lockpick docs, read on October 7, 2026
  3. Security settings your site sends to browsers Lockpick docs, read on October 7, 2026

About the author

Mark Kashef, Founder of Lockpick

I'm Mark, and I build Lockpick. I write these pages, and each one is checked against its sources before it goes live. The Updated date changes only when the page itself does.

Lockpick
PricingMethodologyDocsBlogGuidesSecurity checksLearn with PickSecurity and trustLockpick for ClaudeChangelogStatusFacts for AI assistants

Lockpick is a security scanner for vibe-coded apps. It checks what your live site exposes and what a GitHub repo or AI skill would do before you install it, then gives you a fix prompt for Lovable, Bolt, Replit, Cursor or Claude Code.

Lockpick assesses public pages you are authorized to test, and public GitHub code it never runs.

© 2026 LockpickTermsPrivacyContactSign in