Add base-uri 'none', object-src 'none' and form-action 'self' to a CSP unless you have a reason not to. They block injected base tags, legacy plugin embeds and form posts to attacker hosts. Two of them do not fall back to default-src, so leaving them out means no restriction at all.
Why a script-src alone is not enough
A policy that only sets script-src controls where scripts load from. An attacker who can inject markup but not run script still has other tools: redirect relative URLs, embed an object, or submit a form somewhere else. These three directives address those.
MDN's example of a nonce based strict CSP includes object-src 'none' and base-uri 'none' for this reason.
What each directive does
| Directive | Controls | Falls back to default-src? |
|---|---|---|
base-uri | URLs allowed in the document's base element | No. Not setting it allows any URL. |
object-src | Sources for object and embed elements | Yes |
form-action | URLs that forms may submit to | No. Not setting it allows anything. |
base-uri
The base element changes how relative URLs resolve. If an attacker can inject one, relative script paths such as /app.js can be pointed at the attacker's host. MDN says that without this directive any base URI is allowed, and it is not covered by default-src. Set it to 'none' if you never use a base element, or 'self' if you do.
object-src
This covers object and embed elements. MDN notes those are legacy HTML elements that are no longer receiving new standardised security features, so it recommends restricting the directive, explicitly setting object-src 'none' when possible.
form-action
This limits where forms can submit. If injected markup adds a form that posts credentials to another host, a strict form-action stops the submission. MDN warns that whether the directive should block redirects after a submission is debated, and browser implementations were inconsistent, with Chrome blocking and Firefox not blocking in the versions it cites. Do not treat it as a complete fix for open redirects.
A starting policy
Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'none'; form-action 'self'; frame-ancestors 'none'
The frame-ancestors directive in that line controls who may embed your page, which is the clickjacking control. See frame-ancestors vs X-Frame-Options for details.
Steps to roll out
- Search your templates for base elements, object and embed tags, and every form action value.
- Add the directives in a
Content-Security-Policy-Report-Onlyheader first. - Watch for legitimate form posts to payment or login hosts, and add those origins to
form-action. - Enforce, and keep reporting on.
Try it yourself
Open the web app scan and see how missing header controls are listed as findings, with a fix attached.
Click through it at your own pace, or open it full screen.
Quick check
If I set default-src, am I covered for base-uri?
No. MDN says base-uri does not fall back to default-src. Set it directly.
Does form-action stop CSRF?
No. It limits where forms on your page can submit. CSRF defences such as SameSite cookies and tokens address forged requests from other sites.
Can I set these in a meta tag?
The MDN snippets for these directives include meta examples, but a meta tag does not support every CSP feature. Prefer response headers.
Safeguard's dependency scanning and policy gates cover the packages in your build. Run a free scan at gold.safeguard.sh/scan.
Sources
- Content-Security-Policy base-uri, MDN
- Content-Security-Policy object-src, MDN
- Content-Security-Policy form-action, MDN
- Content Security Policy guide, MDN
Last reviewed: 19 October 2026.
