Content security policy
On this page
If your site sends a Content-Security-Policy header, it may block the loader or the translation files. A blocked request looks like a network failure, so the page stays in the original language.
What to allow#
- Scripts: the address that serves the loader goes in
script-src. - Connections: the addresses that serve your translation files go in
connect-src: your own site (if it holds a copy) and each CDN.
Add these to your existing policy. Do not replace the policy. The loader adds no inline script.
The snippet generator in the repository can print the exact sources for your setup (its --csp option).
The language switcher#
Whether the switcher needs a style exception depends on its version: verify. Prefer a stylesheet link or a nonce.
A policy with nonces#
Give the script tag your nonce. Frameworks usually have a setting for this.
Pinning the script#
You can add an integrity check to a numbered loader address. See Install with the script tag. The server of the script must send a header that allows it to be read across sites, or the browser blocks it.
When you cannot change the header#
The custom-code pages of Wix and Squarespace do not say whether you can change this header, and Webflow's could not be checked: verify. Treat it as unavailable there. You do not need to, unless you add your own policy by other means.
Platforms that set a policy of their own#
- Magento and Adobe Commerce: on payment pages the policy is enforced from version 2.4.7, and scripts must be allowed by address or hash in a module. It is not an admin setting.
- BigCommerce: scripts on checkout and account pages need an integrity hash, which breaks when the loader file changes. Limit the script to storefront pages.
- Static exports (Next.js): the host sets the header, because the export cannot.
See the other platforms page.
How to find the blocked request#
Open the browser's developer tools. A blocked request appears in the console as a policy violation that names the rule. Add the named address to that rule.
Response headers on our side#
Files from the delivery hosts are meant to carry: open read access for any website, no content sniffing, and no cookies. Checking each provider's defaults is verify.