yireo / magento2-csp-whitelist-inline-js
yireo/magento2-csp-whitelist-inline-js
Magento module to automatically add inline JS script to CSP whitelist
Yireo CspWhitelistInlineJs
When, in Magento 2, the CSP policy to disallow inline scripts is enabled, any script requires either a hash or a nonce (or something similar). This module scans any PHTML template for scripts on the fly and adds a nonce where needed, depending on your configuration.
Installation
composer require yireo/magento2-csp-whitelist-inline-js
bin/magento module:enable Yireo_CspWhitelistInlineJs
Configuration
- Mode
Custom whitelisting(recommended)Whitelist everything(dangerous)
- Logging: See below
Mode: Custom whitelisting
A block can be whitelisted automatically by this module, using one of the following techniques:
1. Custom whitelisting by XML layout
You can whitelist a specific block via the XML layout, by adding an argument csp_whitelist:
<?xml version="1.0"?>
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:module:View/Layout:etc/page_configuration.xsd">
<body>
<referenceBlock name="head.additional">
<arguments>
<argument name="csp_whitelist" xsi:type="boolean">true</argument>
</arguments>
</referenceBlock>
</body>
</page>
Note that there is still a security issue here, because the layout could be updated via the database as well (which could be hijacked via SQL injection).
2. Via DI plugin
You could also create a DI plugin afterAllow on \Yireo\CspWhitelistInlineJs\Util\AllowBlock::allow(Template $block).
Mode: Whitelist everything
With this mode, any inline script is simply allowed. It defeats the purpose of CSP, in general, but gets the job done. Do make sure to log things, so that you can use a different mode after a while. If you keep using this mode in production, you don't get it.
Mode: Whitelist everything
Important note on whitelisting everything & security
Note that automatically fixing inline scripts with this module does not take away the security risk that was meant to be fixed with CSP. The best solution is to apply this module to make sure CSP is not causing harm in production. And next, go through all of the inline scripts that don't have CSP-support yet and add CSP-support to it. And then remove this module again.
What about CMS content?
Whenever content is added to the HTML output of Magento, security checks would need to be in place. For instance, the content of CMS pages or CMS blocks might be compromised by hackers and with that, XSS attacks might be initiated by adding inline scripts to that content. By default, this module does not do anything specific for that CMS content. However, in a default situation, CMS pages and CMS blocks are not being outputted via templates and therefore an inline script in CMS content is not nonced by this module (which is a good thing). While the default is safe, any modification (custom theming, 3rd party modules, etc) could lead into compromised CMS content being outputted with nonced scripts anyway.
Logging
This module also allows logging of these inline scripts. Just enable logging via Yireo > Yireo CspWhitelistInlineJs > Settings > Logging (csp_whitelist_inline_js/settings/logging). Next, monitor the logfile var/log/yireo-csp-whitelist-inline-js.log. The log contains a listing of all block templates that have been picked up upon by this module.
The recommendation is to go through this file and make sure that each template is whitelisted by the extension or theme that is offering that template, so that - one day in the future - you are able to remove this Yireo_CspWhitelistInlineJs module.
Note that this file is regenerated at the end of every request by combining all existing lines with new lines.
Compatibility
- Luma theme
- Hyvä Themes
- Hyvä Checkout
Changelog
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog,
and this project adheres to Semantic Versioning.
[Unreleased]
[0.1.1] - 2 October 2024
Fixed
- Prevent null HTML from causing errors
[0.1.0] - 4 September 2024
Added
- New default mode
customto only allow blocks that are explicitly whitelisted - Change logging so that entries are de-duplicated and sorted
[0.0.3] - 2 August 2024
Fixed
- Add a logger for analysing which scripts are fixed
[0.0.2] - 4 July 2024
Fixed
- Extend from SecureHtmlRenderer\Proxy to delay the instantiation @hostep
[0.0.1] - 28 June 2024
Added
- Initial release
| Version | Stability | QA Status | Compatibility | Released |
|---|---|---|---|---|
| 0.1.1 | stable | Pass | Magento 2.4.7-2.4.9 Details | 2024-10-02 17:45:52 |
| 0.1.0 | stable | Not tested | Not yet tested Details | 2024-09-04 12:44:16 |
| 0.0.3 | stable | Not tested | Not yet tested Details | 2024-08-02 13:33:53 |
| 0.0.2 | stable | Not tested | Not yet tested Details | 2024-07-04 14:13:36 |
| 0.0.1 | stable | Not tested | Not yet tested Details | 2024-06-28 10:04:18 |
Requires 2
| Package | Constraint |
|---|---|
| magento/framework | ^102.0 || ^103.0 |
| yireo/magento2-csp-utilities | ^1.0 |
Compatibility
Each Magento release line is installed on its supported PHP versions, then the module is built (DI compilation + static-content deploy) and its unit and integration suites are run. The matrix shows the lines and PHP versions the module is confirmed to install and run on. Code-quality results further down (phpstan, phpcs, …) are reported separately and never affect compatibility.
Code Quality
Advisory checks against the module's source. Static analysis runs once across the whole module; PHPStan re-runs per Magento + PHP version because resolvable symbols differ between releases. These NEVER affect the Compatibility badge — a phpcs finding can't make a module incompatible.
Static analysis
Coding standards (phpcs), mess detection (phpmd), copy-pasted code (cpd), PHP cross-version compatibility, composer.json validity. Each runs once for the whole module.
PHPStan
Type-checks the module's PHP against a real Magento install at the configured gate level. Re-runs per Magento and PHP version because resolvable symbols differ between releases. Cell → details modal.
Tests
Unit and integration suites, run for each applicable Magento and PHP version. A test failure speaks to the module's behaviour, not its compatibility with a Magento line, so it is reported here separately and never reddens the compatibility matrix.
Unit tests
| Magento | PHP 8.2 | PHP 8.3 | PHP 8.4 | PHP 8.5 |
|---|---|---|---|---|
| 2.4.7 | N/A | N/A | ||
| 2.4.8 | N/A | N/A | ||
| 2.4.9 | N/A | N/A |
Integration tests
| Magento | PHP 8.2 | PHP 8.3 | PHP 8.4 | PHP 8.5 |
|---|---|---|---|---|
| 2.4.7 | N/A | N/A | ||
| 2.4.8 | N/A | N/A | ||
| 2.4.9 | N/A | N/A |
Security
Security checks run directly against the module: an audit of its declared dependencies for known vulnerabilities (composer audit) and a scan of its source for malware and web-shell signatures. Each runs once. A malware detection fails the version outright.
More from yireo
View vendorTurn an existing module into recurring revenue.
If you already maintain a Magento 2 module on GitHub or GitLab, listing it on Packagento takes about five minutes. We mirror your tags, handle distribution signing, and route paid licenses through Stripe Connect, so you can keep shipping the way you already do.