Partly. A CSP can cut off many outbound channels: connect-src limits fetch, XHR, WebSocket and beacons, form-action limits form posts, and img-src limits image requests. It cannot make a malicious script safe, so treat it as a way to shrink the damage, not remove the risk.
The channels a script can use to send data
A script running on your page can read whatever the page can read, including form fields. To get it out, it needs a request. These are the usual routes and the directive that governs each.
| Route | CSP directive |
|---|---|
| fetch, XMLHttpRequest, WebSocket, EventSource, sendBeacon, link ping | connect-src |
| Form submission to another URL | form-action |
| Image request with data in the URL | img-src |
| Loading another script or frame | script-src, frame-src |
MDN lists exactly which interfaces connect-src covers: the ping attribute, fetch, fetchLater, XMLHttpRequest, WebSocket, EventSource and sendBeacon.
Two traps in the table
form-action does not fall back to default-src. MDN states that not setting it allows anything, so set it explicitly. And connect-src falls back to default-src, but images do not use connect-src at all. A policy that locks connect-src and leaves img-src open still allows data in an image URL.
A starting policy for a typical app
Content-Security-Policy:
default-src 'self';
script-src 'nonce-RANDOM_PER_RESPONSE' 'strict-dynamic';
connect-src 'self' https://api.example.com;
img-src 'self' data:;
form-action 'self';
object-src 'none';
base-uri 'none';
frame-ancestors 'none'
Replace the placeholders with your own values. Your analytics and payment providers will need entries, and each one you add widens the set of places data can go.
What CSP will not do
- It does not judge intent. If you allow a vendor domain in connect-src, a compromised script from that vendor can send data to it.
- Navigation is a separate channel. A script can change the page location to a URL carrying data, and fetch directives do not stop that.
- MDN notes strict-dynamic trades convenience for trust: if a trusted script builds script elements from an XSS source, CSP will not stop them.
- A policy delivered as a meta element supports fewer features than the header, and a report-only policy cannot be set that way.
How to get there safely
- Start in report-only mode. The CSP report-only rollout steps cover this.
- Read the reports for a week or two, covering real traffic.
- Add each legitimate destination to the right directive, not to default-src.
- Enforce, and keep the report endpoint live.
- Review the allowed hosts each quarter and drop ones you no longer use.
For choosing between nonce, hash and allowlist, see CSP nonce vs hash vs host allowlist.
Safeguard's dependency scanning helps with the other side, catching known vulnerable or malicious packages before they reach a build. A free scan is at gold.safeguard.sh/scan.
Quick check
If I set connect-src to none, is my data safe?
No. Forms, images and navigation are separate channels. Set form-action and img-src too, and still defend against injected code.
Does default-src cover form-action?
No. MDN says form-action has no default-src fallback, so omitting it allows any target.
Sources
- MDN, CSP connect-src: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/connect-src
- MDN, CSP form-action: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/form-action
- MDN, Content Security Policy guide: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
Last reviewed: 19 October 2026.
