In today’s digital world, security measures such as Content Security Policy (CSP) are essential for ensuring the integrity and security of websites. However, a Composer update to, for example, Magento 2.4.6-p6 can cause inline scripts to no longer load, which can be particularly problematic during the checkout process of an online shop. This article explains how this problem can be resolved, why these changes are necessary, and which security aspect needs to be taken into account.
What is CSP and why is it important?
CSP stands for Content Security Policy and is a security standard that helps prevent certain types of attacks, such as Cross-Site Scripting (XSS). CSP enables website operators to control which resources, such as scripts, stylesheets, and images, may be loaded and executed on a website. This reduces the risk of malicious code being executed.
The problem after a Composer update
After a Composer update to Magento 2.4.6-p6, inline scripts may no longer be executed. This can be caused by CSP policies blocking the execution of inline scripts that have not been explicitly authorized. This is particularly problematic when important JavaScript functions in an online shop’s checkout are affected.
Console error message for CSP problems
When an inline script is blocked due to CSP settings, the browser will often display a corresponding error message in the developer console. A typical message may look like this:
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' https://example.com 'unsafe-hashes'". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution.
Explanation of the error message
- Refused to execute inline script: The inline script was blocked by the browser and was not executed.
- because it violates the following Content Security Policy directive: The script violates a configured CSP policy.
- script-src 'self': Scripts may, for example, only be loaded from the same domain or from explicitly authorized sources.
- 'unsafe-hashes': Certain inline handlers can be permitted through explicitly authorized hashes.
- 'unsafe-inline': This CSP directive would generally allow the execution of inline scripts, but it reduces the level of security and should therefore not be used indiscriminately as a solution.
- sha256-...: A hash can be used to explicitly authorize a specific inline script.
- nonce-...: Alternatively, a unique nonce value can be used, provided the application supports this approach.
Solution: Add SHA-256 hashes to the CSP configuration
One targeted approach is to authorize the hash values of the inline scripts that are actually required in the CSP configuration. A SHA-256 hash represents the exact content of the respective script. Only if the hash calculated by the browser matches the authorized value can the relevant script be executed in accordance with the CSP policy.
Step-by-step guide
1. Determine the SHA-256 hash of the inline script
First, you need to determine which inline scripts are being blocked by the browser. The browser’s developer console generally provides a corresponding CSP notice. The required SHA-256 hash can then be determined for the affected script.
Important: The hash must match the content of the script exactly. Even a small change, such as an additional space or line break, results in a different hash.
2. Adjust the CSP configuration
The Magento project’s CSP configuration must then be adjusted. In Magento, this can be done, for example, using a csp_whitelist.xml file within a custom module. The specific configuration should be appropriate for the Magento version being used and the existing CSP implementation.
3. Example of an inline script
Assume that the affected inline script is:
console.log("Checkout gestartet");
The SHA-256 hash determined for this script can then be stored in the CSP configuration as an authorized hash.
<value id="inlinescripts" type="host">
'sha256-XaZvjMjb4e+J9Fj5Gh7gudv5x09A=='
</value>
The specific hash in this example is for illustrative purposes only. For a script used in production, the actual hash of the exact script content must always be used.
4. Deploy the changes and clear the cache
After adjusting the CSP configuration, the changes must be deployed to the server or the relevant Magento environment. The relevant Magento caches should then be cleared and the application tested again in the browser.
Why shouldn't you simply use unsafe-inline?
The obvious solution would be to loosen the CSP policy by using 'unsafe-inline'. This would allow inline scripts to be executed again. However, this weakens a significant security benefit of a restrictive CSP.
Targeted authorization using hashes or, depending on the use case, nonces is therefore generally preferable. This means that not all inline JavaScript code is allowed indiscriminately; instead, only the code that is actually required and explicitly authorized is permitted.
The security aspect
Using SHA-256 hashes provides an additional layer of security. An attacker cannot simply inject arbitrary inline JavaScript code and expect it to be executed automatically because inline execution has been generally authorized. The injected code would have a different hash and therefore would not match the explicit CSP authorization.
Conclusion
After a Composer update to Magento 2.4.6-p6, stricter CSP rules can cause certain inline scripts to no longer be executed. This can lead to visible functionality issues, particularly during checkout.
A targeted solution is to authorize the inline scripts that are actually required using suitable CSP mechanisms such as SHA-256 hashes or, depending on the implementation, nonces. For security reasons, a blanket authorization using 'unsafe-inline' should be avoided whenever possible.
Our agency places great importance on operating websites and online shops securely and reliably. With a carefully configured CSP, security requirements and necessary functionality can be brought together.
👉 Contact us – we’ll be happy to advise you.
