How (and why) do I set up the Content Security Policy (CSP)?

In the i-Reserve environment, it is possible to configure a Content Security Policy (CSP). A CSP is an additional security layer that helps prevent malicious scripts and unwanted content from being executed in the i-Reserve environment. The CSP tells the browser which sources of content (such as scripts, stylesheets, images, and videos) may or may not be loaded and executed.

To configure these allowed sources, go to configuration mode in the i-Reserve environment. Then navigate to System > Security Settings. At the bottom of this page, you will find the settings related to the CSP.

The setting Content Security Policy (CSP) – Allowed Domains allows you to enter the sources from which all scripts and content may be executed and/or loaded in the environment. If there are sources that should only be allowed to execute and/or load specific scripts and content, these can be added to the option Content Security Policy (CSP) – Override.

The setting Content Security Policy (CSP) – Allowed Widget Domains is specifically for the i-Reserve widget. In this setting, you can specify the domains from which the widget may be loaded.

Why We Use CSP in the i-Reserve Reservation Dialog

Disabling CSP can be quite risky. CSP is one of the most important security layers for modern websites. If you disable it completely, these are the main consequences:

1. Much Higher Risk of XSS Attacks (Cross-Site Scripting)

   CSP prevents malicious actors from executing their own JavaScript on your site. Without CSP, hackers could, for example:

   • inject malicious scripts via input fields,
   • misuse scripts in third-party widgets,
   • display phishing pop-ups within your site,
   • read cookies or tokens (if they are not HttpOnly).

2. Harmful External Scripts Can Be Loaded Easily

   CSP determines which domains are allowed to deliver scripts, styles, images, or iframes. If you disable CSP:

   • malicious advertisements or embedded external scripts can be executed,
   • any inline <script> or style can run without restriction,
   • third-party trackers can be secretly injected.

3. Inline Scripts and eval() Are Allowed Again

   CSP blocks unsafe constructs like eval(), inline scripts, and inline event handlers (e.g., onclick="..."). Without CSP, the chance increases that malware or unwanted scripts will embed themselves this way.

4. Loss of Protection Against Clickjacking

   Many CSP settings include frame-ancestors, which prevents your site from being loaded within an iframe. Without CSP:

   • your site can be loaded in an unsafe external environment,
   • the risk of clickjacking increases (visitors click on something they don't see).

5. Poorer Attack Detection

   CSP can report when scripts are blocked (report-uri / report-to). If you disable CSP:

   • you lose this detection logging,
   • you no longer see if injection attempts are occurring.

6. Potential Issues with Compliance or Security Audits

   Some sectors (fintech, government, healthcare) require CSP as part of their security baseline. Disabling it can therefore lead to:

   • failed penetration tests,
   • problems during audits,
   • failure to meet best practices.

Conclusion

Disabling CSP makes your website much more vulnerable to script injection, data theft, clickjacking, and misuse via external scripts. It is almost never necessary to turn CSP off completely. Usually, it is sufficient to configure it correctly.