Does your Content Security Policy also lock down plugins, base and forms?
This check reads three parts of an enforced Content Security Policy that are easy to miss. They block old plugin content, stop the page base address from being changed and limit where forms may send data.
What does this check look at?
It looks at whether an enforced Content Security Policy also restricts plugins, the page base address and where forms may send data. MDN describes the three directives as restricting plugin sources, the page base element and the targets of form submissions.
Pulse and Deep scans both run it.
What does a result mean?
| What the report shows | What it means | What to do |
|---|---|---|
| Pass | The enforced policy restricts all three. | Nothing. |
| Attention | One or more of the three is missing or too loose. | Add them to the existing policy. |
| Not tested | No enforced policy was seen, or the page is not HTML. | Start with the Content Security Policy check. |
It reads a few directives, not whether the whole policy is safe. 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?
| Part | For this check |
|---|---|
| Where it starts | Content or a frame an attacker can influence |
| The protection that should stop it | A browser protection header is missing or weak |
| What is reached | How browsers treat your pages |
| What follows | A hardening gap; no exploit was shown |
Which standards does it relate to?
| Standard | Reference |
|---|---|
| OWASP Top Ten | A02:2025 Security Misconfiguration |
| CWE | CWE-693 |
| ASVS | v5.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
These three are usually safe to add to a working policy, since few modern sites use plugins or change their base address.
My site already has a Content-Security-Policy header. Add object-src 'none', base-uri 'self' (or 'none' if no page uses a base tag) and form-action limited to my own site plus any form provider I really use. Keep every existing directive as it is. Test the login, signup, checkout and contact forms after the change and tell me if any form stops working.How to check
Say Atlas, our example app at atlas.example, enforces a script policy but has no form-action rule. The check flags only the missing directive.
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
Why does form-action matter if my forms use HTTPS?
It limits where a form may send data, so injected markup cannot quietly point your login form at another site.
Does default-src cover these?
Not all of them. base-uri and form-action do not fall back to default-src, so they need their own entries.
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 siteSources
- Content-Security-Policy (CSP) header MDN Web Docs, read on October 7, 2026
- How we rate findings Lockpick docs, read on October 7, 2026