Magento 2.4.8 SRI Bug: Multi-Website Checkout Blocked? Fix Your Security Hashes!

As e-commerce platforms evolve, new features are constantly introduced to enhance security and performance. Magento 2.4.8 brought Subresource Integrity (SRI) to its Content Security Policy (CSP) module, a welcome addition aimed at preventing malicious script injections. However, as highlighted in GitHub issue #40807, this new security layer inadvertently introduced a critical bug that could bring multi-website Magento installations to a grinding halt, specifically impacting the checkout process on non-base websites.

At Shopping Mover, we specialize in navigating the complexities of Magento, from seamless migrations to critical bug resolutions. Understanding such issues is paramount for maintaining a robust and secure e-commerce operation. Let's dive deep into the Magento 2.4.8 SRI hash mismatch bug and what it means for your multi-website setup.

The Core Problem: SRI Hash Misplacement in Magento 2.4.8

The issue, reported by jigardhaduk, details a severe problem affecting Magento 2.4.8 environments configured with multiple websites under a single installation. The setup typically involves:

• Magento Version: 2.4.8 (Adobe Commerce or Open Source)
• Module Affected: magento/module-csp
• PHP Version: 8.4.21 (though the issue is tied to Magento logic, not PHP version directly)
• Setup: Multiple websites (e.g., 3) on a single Magento install, sharing a single pub/static/ directory, all utilizing the Magento Luma theme and en_US locale. This configuration is common for businesses managing diverse brands or regional stores from a single backend.

Subresource Integrity (SRI) is a security feature that enables browsers to verify that resources they fetch (like JavaScript files) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash (e.g., SHA-256) that the browser compares against the fetched resource. If the hashes don't match, the browser blocks the resource, preventing potential supply chain attacks or malicious script injections.

The root cause of this particular Magento 2.4.8 bug lies in how the platform generates and places the sri-hashes.json file. Instead of placing this crucial file within the theme and locale-specific path (e.g., pub/static/frontend/Magento/luma/en_US/sri-hashes.json), it incorrectly writes it to the root of the static content directory: pub/static/frontend/sri-hashes.json. This misplacement leads to a critical integrity mismatch when browsers attempt to load JavaScript files on non-base websites.

Impact: Broken Checkout on Non-Base Websites – A Business Critical Failure

The consequences of this bug are immediate and severe. When users attempt to proceed with checkout on any website other than the one configured as the base scope, the browser console throws a SHA-256 integrity mismatch error. This isn't just a minor glitch; it's a complete blockage of critical JavaScript files required for the checkout process to function.

The browser console typically displays an error similar to this:

SHA-256 integrity '5TLFpQkwsvDijbV/X/uwSESFj7AZjTFhIcZDV8mqv2w='. The resource has been blocked.

This error means that the browser, acting on the integrity hash provided by Magento, has determined that the JavaScript file it received does not match the expected hash. Because the sri-hashes.json file is incorrectly placed and thus contains hashes relevant to the base website's static content, it provides incorrect integrity checks for non-base websites, even if they share the same theme and locale. The result? Essential checkout functionalities, such as payment gateways, shipping calculators, and form validations, simply cease to work.

For an e-commerce business, a broken checkout process translates directly into lost sales, frustrated customers, and significant damage to brand reputation. This is particularly critical for multi-brand or international stores relying on a single Magento instance.

Technical Deep Dive: Why the Path Matters

Magento's architecture, especially in multi-website setups, relies heavily on proper static content deployment. The pub/static/ directory is where all compiled CSS, JavaScript, images, and other static assets reside. For performance and consistency, these assets are often deployed using the command php bin/magento setup:static-content:deploy.

In a multi-website environment, even with a shared theme (like Luma) and locale (en_US), Magento generates static content specific to each store view or website if there are subtle differences or if the system is configured to handle them distinctly. The expectation for sri-hashes.json was that it would follow this pattern, being generated within its respective theme/locale path (e.g., pub/static/frontend/Magento/luma/en_US/sri-hashes.json). This ensures that each store view loads the correct integrity hashes corresponding to its specific static assets.

The bug causes the file to be written to a generic, root-level path (pub/static/frontend/sri-hashes.json). When a non-base website attempts to load its JavaScript, it looks for the integrity hash in this generic file. However, the hashes within this file are likely generated based on the base website's context, leading to mismatches for other websites, even if the underlying JS files are identical. The browser, prioritizing security, correctly blocks these resources.

Reproducing the Issue

For developers and administrators, reproducing this issue to confirm its presence in your environment involves these steps:

1. Install Magento 2.4.8 (Adobe Commerce or Open Source).
2. Create 3 distinct websites under a single Magento installation, each with its own domain.
3. Ensure all websites are configured to use the Magento Luma theme and the en_US locale.
4. Run the static content deployment command: php bin/magento setup:static-content:deploy en_US -f.
5. Attempt to complete the checkout process on any website other than the one configured as the base scope.

You will observe the browser console errors and a non-functional checkout on the non-base websites.

Temporary Workaround and the Official Fix

The GitHub issue notes that temporarily deleting the misplaced pub/static/frontend/sri-hashes.json file restores checkout functionality. While this confirms the file's role in the problem, it's a temporary measure that disables a crucial security feature (SRI) and is not a sustainable solution for a production environment.

Given the "Progress: done" and "Issue: ready for confirmation" labels on the GitHub issue, it indicates that Adobe Commerce developers have addressed this bug. Users are strongly advised to:

• Check for Official Patches: Look for official patches or hotfixes released by Adobe Commerce for Magento 2.4.8 or subsequent patch releases (e.g., 2.4.8-p1) that specifically address this SRI hash misplacement.
• Upgrade to Latest Stable Version: If feasible, upgrading your Magento instance to the latest stable version that includes the fix is the most recommended long-term solution.
• Apply Custom Fixes (with caution): If an immediate official patch isn't available and an upgrade isn't possible, a temporary custom fix might involve modifying the CSP module's logic to correctly generate the sri-hashes.json file in the theme/locale-specific path. However, this should only be done by experienced Magento developers and thoroughly tested.

Preventative Measures and Best Practices for Magento Security

This incident underscores several critical best practices for managing complex Magento environments:

• Thorough Testing: Always conduct comprehensive regression testing, especially on critical paths like checkout, after any Magento upgrade, patch application, or module installation.
• Monitor Browser Consoles: Regularly check browser developer consoles for errors, particularly after deployments. These often provide the first indication of front-end issues.
• Robust CI/CD Pipelines: Implement a strong Continuous Integration/Continuous Deployment (CI/CD) pipeline that includes automated testing for static content generation and integrity checks.
• Stay Updated: Keep your Magento instance updated to the latest stable versions and apply security patches promptly.
• Expert Partnership: For complex multi-website setups, migrations, or upgrades, partnering with experienced Magento development and migration experts like Shopping Mover can save significant time, resources, and prevent costly downtime. We ensure your platform remains secure, performant, and compliant.

Shopping Mover: Your Partner in Magento Excellence

Navigating the intricacies of Magento 2, especially with new features and potential bugs, requires deep expertise. At Shopping Mover, we are dedicated to providing seamless Magento migrations, upgrades, and ongoing support, ensuring your e-commerce platform operates flawlessly and securely. Don't let critical bugs like the SRI hash mismatch disrupt your business. Contact us today for expert assistance and keep your Magento store thriving.