# Does your Content Security Policy also lock down plugins, base and forms?

By Mark Kashef, founder of Lockpick. Published 2026-10-08, updated 2026-10-08.

This check reads three directives in an enforced CSP that are easy to miss, and explains what each one blocks and how to add them.

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.

:::fix-prompt any
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](/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](/docs/get-started/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.

## Sources

- [Content-Security-Policy (CSP) header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy), MDN Web Docs, read on 2026-10-07
- [How we rate findings](https://www.lockpick.app/docs/security/how-we-rate-findings), Lockpick docs, read on 2026-10-07