Content Security Policy (CSP)

A Content Security Policy (CSP) is a security rule set configured on your web server that controls which external scripts and resources your website is allowed to load. When a CSP is in place and Triptease's script domains are not included in its allowlist, your browser will block the Triptease script from running — even if the script tag is correctly installed on your site.

CSP blocks are one of the most common reasons Triptease features stop working after a website update, a server configuration change, or a cookie consent interaction.

CSP is enforced by the browser, but set on the server so must be applied at the server level. Editing or re-adding the Triptease script tag will not resolve it.

When a visitor loads your hotel website, the browser sends a request to your server. The server responds with the page content and a set of response headers. One of those headers — Content-Security-Policy — tells the browser which external domains it is allowed to load scripts from.

If Triptease's domains are not included in that header, the browser will block the Triptease script from executing without any visible change to the page. This will cause Triptease features — including on-site messages, Price Match, Paid Search tracking, and conversion data — to stop working, even though the script tag itself is still present in your HTML.

CSPs are most commonly managed by one of the following platforms on your server:

If you are unsure which platform manages your server, contact your IT or development team.

You can check for a CSP block directly in your browser without any specialist tools.

Fixing a CSP block requires your IT or development team to update your server configuration. Triptease cannot make this change on your behalf.

Ask your team to add the following Triptease domains to your server's existing Content-Security-Policy header under the script-src , connect-src, frame-src and default-src directives:

Once the change has been deployed, reload your website, open the Console tab again, and confirm the CSP error has cleared. Then contact your Triptease Customer Success Manager (CSM) or the Support team to verify that the script is loading correctly and that data is flowing into the platform.

📌 Note: If your website uses a cookie consent platform (such as Cookiebot, OneTrust, or TrustArc), a CSP block can interact with consent settings in unexpected ways. In some cases, the script may only be blocked after the visitor accepts or declines cookies — not on the initial page load. If you notice that Triptease stops working specifically after cookie consent is given, this is a likely cause. Make sure your consent configuration also permits Triptease's domains to load after consent is granted.

A consent management platform (CMP) such as Cookiebot, OneTrust or TrustArc can also stop the Triptease script from running — but it does so by a completely different mechanism, and the fix is in a different place. Consent platforms do not use CSP.

A CMP blocks a script by holding it back until the visitor consents: typically by rewriting the tag's type attribute to text/plain, proxying it, or not injecting it at all until a consent category is accepted. Nothing is refused by the browser, so no CSP error appears.

How to tell them apart in DevTools:

If it's a consent block: check how Triptease is categorised in your CMP and that the category maps to what you intend. Triptease should load once the visitor has given the relevant consent — see the Consent Mode Guide for how to configure this.

Both can apply at once. A CMP that correctly releases the Triptease script after consent will still be blocked by CSP if your policy doesn't allow Triptease's domains — so if the script only starts working after consent and you see a CSP error, fix both.

Q: The Triptease script tag is on my website — why aren't Triptease features working?

A: A CSP block can prevent the script from executing even when the tag is correctly installed. Open your browser's Console tab, reload the page, and check for any "Content Security Policy" error messages. If you see one referencing a Triptease domain, the fix needs to be made in your server configuration.

Q: Who is responsible for updating the CSP?

A: Your IT or development team controls the server configuration where the CSP is set. Triptease cannot update your CSP directly. Share the list of Triptease domains above with your team and ask them to add them to the script-src allowlist.

Q: How do I know which domains to add to the allowlist?

A: Add *.triptease.io and *.triptease.net to cover all current and future Triptease subdomains. If your IT team requires a more specific list, contact Triptease Support and we can provide the full list of domains in use for your property.

Q: Does a CSP block affect all Triptease features or just some?

A: It depends on which domains are blocked and how your CSP is configured. In many cases a full block will prevent all Triptease features from running. However, it is also possible for only specific features — such as Paid Search tracking or on-site messages — to be affected if only certain Triptease domains are excluded.

Q: Could my cookie consent banner be causing the block?

A: Yes, but by a different mechanism than CSP, with a different fix. See "Is it a CSP block, or your cookie consent banner?" section above.