What are CSP and SRI?

Running Magento or Adobe Commerce and considering CSP?

Content Security Policy (CSP) and Subresource Integrity (SRI) in a nutshell.

What is CSP

A typical site contains many elements (Javascript code, fonts, images, styles). A CSP tells a browser which elements to trust and which not.

The goal of a CSP is to mitigate specific attacks where criminals inject code in order to steal private data. Common attacks are cross site scripting (XSS) and digital skimming (Magecart).

A site can transmit CSP as a HTTP header to the browser. The header can be generated by the webserver or an application. Here is a sample CSP header which only accepts local sources, Google Analytics scripts and Google fonts:

Content-Security-Policy:
    default-src 'self';
    script-src https://www.google-analytics.com;
    font-src fonts.gstatic.com;

What is SRI

To make sure that embedded scripts and styles have not been tampered with, you can add a hash (a unique summary) to your HTML code. If the hash doesn't match the actual script code, the browser refuses to run it.

A sample script element in your html may look like this:

<script
  src="https://example.com/script.js"
  integrity="sha512-abcdefg1234567..."
  crossorigin="anonymous"
></script>

If the code changes, so does the hash. So it is important to track changes (and regenerate a hash) or your site may stop working. Hashes can be generated by your application code or by a site such as SRIhash.

Purpose of CSP

CSP was designed to protect against XSS attacks. While these attacks happen incidentally on Magento stores, they are outnumbered by digital skimming (Magecart) attacks (we observed 120,000 skimming attacks since 2015).

Luckily, CSP can provide a level of protection against many digital skimming attacks as well, that is why the PCI DSS recommends using CSP in requirement 6.4.3 and 11.3.1.

While it is technically possible to bypass CSP, the current state of affairs is that the majority of all digital skimming attacks to date would have been stopped by a proper CSP implementation. We consider CSP as a an extra barrier to stop skimming attacks.

Modes of operation

CSP can work in 3 ways

1. Using a list of trusted sites ("allow-list"). Everything not on the list gets blocked.
   • PRO: Relatively easy to maintain.
   • CON: Trust of source does not guarantee integrity, as attackers may find ways to inject code into one of your trusted sites. This is easier than you think, for example if any of your trusted sites has a JSONP endpoint or runs AngularJS.
   • CON: Does not work well with Google Analytics 4 when Google Signals is enabled, see below.
2. Using nonces (number-used-once). You tag every trusted element with a unique key that is generated for every page view, elements without this key are blocked. In combination with the strict-dynamic keyword, trust is propagated through all the sources that are loaded by your sources.
   • PRO: Requires almost no maintenance. Is recommended by Google.
   • CON: Does not protect against a supply chain injection.
   • CON: Does not guarantee integrity.
   • CON: If your framework does not support it out of the box, it can be complex to set up.
   • CON: Notably, it is not compatible with Magento's page cache (because nonces have to be regenerated upon every page view).
3. Hash-based trust: you maintain a list of hashes (a cryptographic identifier of the content) for all your trusted elements. These hashes are added to your CSP header and every trusted element (also called subresource integrity or SRI). When using strict-dynamic, the trust will propagate to nested sources.
   • PRO: This is the only method that guarantees the integrity of directly embedded sources.
   • CON: It does not guarantee the integrity of nested sources.
   • CON: It breaks your site when the embedded source is updated (or is even generated dynamically) so in practice, this method is only useful for inline (local) scripts and styles.

Reporting or not

CSP can operate in two modes: enforce and report-only. While enforce mode blocks disallowed content, report-only mode logs violations for review but does not block them. This can be useful for:

• Debugging and Development: Ensuring your CSP doesn't break your site functionality.
• Continuous Monitoring: Keeping track of evolving scripts and third-party services without disrupting user experience.