The CSP check: a Content-Security-Policy on every page, and what it says
A Content-Security-Policy tells the browser which sources a page may load from and what it may do. Sentinel, Anticode's security check, looks for one in every page it scans and passes the page only if the policy includes a default-src rule. Pages from the design engine carry a strict policy in their head, and published sites send a second policy as a response header.
What a Content-Security-Policy is for
Most attacks on a web page come down to getting it to load or run something its author didn't intend: a script injected through a form, a stylesheet from another server, a hidden frame. A CSP is an allow-list the page hands the browser up front. Anything not on the list is refused, even if an attacker manages to get it into the markup. It doesn't fix the hole that let the content in, but it stops much of what that content could do. The guide to Content Security Policy covers the directives in depth.
default-src is the fallback for every resource type the policy doesn't mention separately. Without it, anything not explicitly listed is allowed, which is why Sentinel insists on it: a policy with no default-src can leave most of the door open.
The policy in every design-engine page
Each page carries this policy in a meta tag in its head. Read it one directive at a time:
| Directive | Meaning |
|---|---|
default-src 'self' | Anything not covered below may load only from the site itself |
script-src 'none' | No JavaScript at all, from anywhere |
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com | The page's own styles, plus the Google Fonts stylesheet |
font-src https://fonts.gstatic.com | Font files only from Google's font server |
img-src 'self' data: https://images.unsplash.com | Images from the site, inline data images and the curated photo library |
form-action 'self' | Forms may submit only to the site itself |
base-uri 'none' | No base tag can redirect the page's relative links |
object-src 'none' | No plugins or embedded objects |
Allowing inline styles is a deliberate trade: with scripts banned outright, inline CSS can't be used to run code, and the design engine writes its styles into the page.
The header published sites add
A meta tag is only part of the story, because some directives can't be set that way. When a page is served from name.anticode.dev or a custom domain, the response also carries a Content-Security-Policy header. It starts from default-src 'none' rather than 'self', keeps script-src 'none', object-src 'none' and form-action 'self', and adds three more directives, one of which a meta tag can't set at all:
frame-src 'none': the page can't embed other pages, which is why YouTube, maps and booking widgets have to be linked rather than embedded.frame-ancestors 'none': other sites can't put your page inside a frame, the basis of clickjacking. This directive only works in a header.connect-src 'none': nothing on the page can open a network connection.
When both a meta policy and a header policy apply, the browser enforces both, so a resource has to satisfy each of them.
Checking any site's CSP yourself
Sentinel only scans Anticode builds, but you can check if a site has a CSP with any browser:
- Open the page and view its source. Search for
Content-Security-Policyto find a meta tag in the head. - Open the browser's developer tools, go to the Network panel, reload, and select the first request. Look for a
content-security-policyresponse header. - Read the policy for
default-src. If it's missing, or set to*, the policy restricts very little. - Look for
'unsafe-eval'or a broadscript-src; those weaken whatever else the policy says.
Limits
- The check looks at the meta tag. Sentinel's CSP check passes when the page's own meta policy exists and mentions
default-src. It doesn't grade the policy beyond that; the separate checks for scripts and form targets read specific directives. - It runs in the builder. The server's publish gate doesn't repeat this particular check, but published pages get the header policy regardless of what the page says.
- App builds differ. Apps run inside a sandboxed frame under their own policy and their own code gate, described on the app sandbox page.
- Anticode pages only. This website CSP checker doesn't scan other sites; use the steps above for those.
Questions people ask
Is a CSP meta tag as good as a header?
Mostly, but not entirely. Some directives, such as frame-ancestors, only work in a header. Anticode pages have both: a meta policy in the page and a stricter header when published.
Why can't I embed a YouTube video on my page?
The published policy sets frame-src 'none' and script-src 'none', so embeds are refused by the browser. Link to the video instead.
What does Sentinel's CSP check need to pass?
A Content-Security-Policy meta tag in the page that includes a default-src rule.