Subresource Integrity in Magento: wat SRI doet en waar het misgaat

Eén gewijzigd teken in een JavaScript-bestand, en je checkout weigert het te laden. Dat is Subresource Integrity (SRI), en sinds Magento 2.4.7 staat het aan.

SRI is een eenvoudig idee. Je zet een hash van een script in de HTML. De browser downloadt het script, berekent zelf de hash en vergelijkt. Klopt het niet, dan draait het script niet. Zo vang je een script dat onderweg of op een CDN is aangepast.

Dit artikel legt uit hoe SRI in Magento werkt, welke fouten je in de praktijk tegenkomt en hoe je ze oplost.

Wat SRI wel en niet doet

Een SRI-tag ziet er zo uit:

<script src="https://cdn.example/app.js"
        integrity="sha384-BASE64HASH"
        crossorigin="anonymous"></script>

De browser doet drie dingen: hij haalt het bestand op, hij berekent de hash en hij vergelijkt die met integrity. Bij een verschil blokkeert hij het script.

Wat het oplost:

• Een CDN of opslagplek die wordt gecompromitteerd en een bestand aanpast.
• Een bestand dat op de server is aangepast nadat de HTML is gegenereerd.
• Een man-in-the-middle op een extern script.

Wat het niet oplost:

• Een aanvaller die ook je HTML kan wijzigen. Die past de hash gewoon mee aan.
• Een script dat zelf extra scripts nalaadt. Alleen het script waarop de hash staat, is gecontroleerd.
• Kwaadaardige code die al in je eigen bestanden zit voordat de hash werd berekend.

SRI is dus een integriteitscontrole, geen volledige beveiliging. Daarom werkt het het best samen met een Content Security Policy.

Wat Magento 2.4.7 doet

Sinds 2.4.7 genereert Magento SRI-hashes voor alle JavaScript-bestanden op betaalpagina's. Die hashes worden aangemaakt bij het deployen van static content. Magento houdt ze bij en voegt het integrity-attribuut toe aan de scripttags op de betaalpagina's.

Je kunt dit uitbreiden naar andere pagina's, zoals het winkelwagentje of het klantaccount. De standaard dekt de betaalpagina's.

De reden is dezelfde als bij CSP: PCI DSS 4.0. Eis 6.4.3 vraagt om autorisatie en integriteit van scripts op de betaalpagina, en 11.6.1 om detectie van wijzigingen. SRI geeft je een mechanisme voor de integriteit, in elk geval voor je eigen en lokaal geserveerde scripts. Of dat samen met je andere maatregelen genoeg is, bepaalt je QSA. Zie ook PCI DSS 4.0 voor webshops.

Waar het in de praktijk misgaat

Hashes kloppen niet meer na een deploy

Dit is de klassieker. De hashes worden gemaakt bij setup:static-content:deploy. Als je daarna nog iets aan de gegenereerde bestanden verandert, klopt de hash niet meer. Voorbeelden:

• Een build-stap die JavaScript minificeert of bundelt na het genereren van de hashes.
• Een deploy waarbij pub/static handmatig is aangepast of deels is gesynchroniseerd.
• Een CDN of reverse proxy die JavaScript herschrijft.

Het resultaat: de browser blokkeert het script en de checkout heeft geen werkende JavaScript. In de console zie je dan een melding dat de integriteitscontrole is mislukt.

CDN's die bestanden aanpassen

Sommige CDN's en optimalisatiediensten comprimeren, minificeren of herschrijven JavaScript on-the-fly. Dat is handig voor snelheid, maar het breekt SRI, omdat de bytes anders zijn dan wat Magento heeft gehasht.

De oplossing is simpel: zet minificatie en herschrijven van JavaScript uit voor het pad van je static content, of laat de CDN alleen cachen en niet transformeren. Lees ook onze stappen voor een Cloudflare-instelling voor je webshop, waar dit soort opties vaak aanstaan.

Controleer ook de crossorigin-instelling en CORS-headers. Een script van een ander domein vereist dat de server toestaat dat het wordt opgehaald voor een integriteitscheck. Ontbreekt die header, dan weigert de browser het script ook al klopt de hash.

Externe scripts van betaalproviders

Dit is het lastige deel. Veel betaalproviders laden hun JavaScript van hun eigen domein en wijzigen dat bestand zonder dat jij het weet. Een vaste hash op zo'n bestand betekent dat je checkout breekt zodra de provider een update uitrolt.

Daarom pinnen de meeste providers geen hash en bieden ze een stabiele URL zonder integriteit. Zet jij er zelf een hash op, dan gaat het mis bij de eerstvolgende wijziging aan hun kant.

Wat wél werkt:

• Gebruik de aanpak die de provider zelf voorschrijft, zoals een hosted payment page of iframe waarbij het betaalscript niet op jouw pagina draait.
• Laat de provider-scripts onder CSP vallen met een zo kleine mogelijke whitelist.
• Houd een inventaris bij van welke externe scripts je gebruikt en waarom. Dat heb je voor PCI 6.4.3 sowieso nodig.

Voor merchants met een hosted payment page of iframe (SAQ A) is de eis in v4.0.1 aangepast. Vraag je QSA of betaalprovider wat voor jou geldt. Dit is geen juridisch advies.

Dynamische en inline scripts

SRI werkt op bestanden met een URL. Voor inline scripts geldt het niet, en daar komt CSP met hashes of nonces om de hoek kijken. Een shop met veel inline code van extensies heeft dus beide nodig.

SRI-fouten debuggen

Een integriteitsfout is onzichtbaar voor bezoekers en pijnlijk voor je omzet. Zo spoor je het op:

1. Open de browserconsole op de checkout. Een SRI-fout noemt het bestand en meldt dat de hash niet overeenkomt.
2. Haal het bestand zelf op met curl en vergelijk wat je krijgt met wat de server hoort te serveren. Verschilt de uitkomst tussen origin en CDN? Dan transformeert de CDN.
3. Bereken de hash zelf:

openssl dgst -sha384 -binary pub/static/frontend/Vendor/theme/nl_NL/js/bundle.js \
  | openssl base64 -A

1. Vergelijk met de integrity in de HTML. Zie je een ander resultaat? Dan is het bestand na het hashen veranderd.
2. Deploy opnieuw met een schone static content-run en zorg dat er geen stappen meer na komen.

In de praktijk blijkt het bijna altijd een van deze oorzaken: een CDN die herschrijft, een deploy die niet atomair is, of een aangepast bestand.

Deployment-tips die SRI-problemen voorkomen

• Bouw static content één keer, in je pipeline, en rol exact dat artefact uit. Niet op productie nogmaals genereren.
• Zorg dat de HTML en de static files uit dezelfde release komen. Een gedeeltelijke uitrol van alleen de HTML geeft hash-mismatches.
• Leeg na een deploy de full page cache en de CDN-cache voor JavaScript, zodat er geen oude HTML met nieuwe bestanden wordt geserveerd.
• Test de checkout na elke release met een echte testbetaling.

Dat laatste punt past bij wat we in Magento 2 security patches zonder downtime beschrijven: een voorspelbare, herhaalbare deploy voorkomt de meeste van dit soort fouten.

Uitbreiden naar andere pagina's

Wil je SRI ook op andere pagina's, bijvoorbeeld de cart of het account? Dat kan, maar denk eerst na over de prijs. Meer pagina's betekent meer kans op mismatches, meer pagina's om te testen en meer externe scripts waar je een oordeel over moet hebben.

Onze vuistregel: begin bij de pagina's waar betaalgegevens of inloggegevens worden ingevoerd. Voor een productpagina met een review-widget levert SRI minder op dan het opruimen van de scripts zelf. Soms is het minder werk om een script te verwijderen dan om het te beveiligen. Op een Hyvä-shop met weinig third-party JavaScript is het ook gewoon makkelijker om dit schoon te houden.

Wanneer is dit overkill?

Heb je een kleine shop met een volledig gehoste betaalpagina en geen eigen scripts op de checkout? Dan is het standaardgedrag van Magento ruim voldoende. Je hoeft niet te investeren in extra hashing. Je moet vooral zorgen dat de standaardfunctie niet wordt gesaboteerd door je CDN of deploy.

SRI en CSP zijn onderdeel van een groter geheel. Voor het totaalbeeld, zie onze Magento security checklist en de pagina Magento security.

Veelgestelde vragen

Wat is Subresource Integrity in Magento?

SRI voegt een hash van een JavaScript-bestand toe aan de scripttag. De browser controleert of het bestand overeenkomt met die hash. Klopt het niet, dan wordt het script geblokkeerd. Sinds Magento 2.4.7 gebeurt dit standaard voor alle JavaScript op betaalpagina's.

Waarom breekt mijn checkout door SRI?

Meestal is het bestand na het berekenen van de hash veranderd. Denk aan een CDN die JavaScript minificeert of herschrijft, een deploy waarbij bestanden niet bij de HTML passen, of een handmatige wijziging in pub/static. De browserconsole toont welk bestand het betreft.

Kan ik SRI op scripts van mijn betaalprovider zetten?

Dat is riskant. Als de provider het bestand zonder aankondiging wijzigt, breekt je checkout. Gebruik liever de aanpak die de provider voorschrijft, zoals een iframe of hosted page, en beperk de scripts via CSP.

Is SRI genoeg voor PCI DSS 6.4.3?

Niet alleen. SRI regelt de integriteit van scripts, maar de eis vraagt ook om een inventaris en autorisatie per script. Welke combinatie van maatregelen voor jou volstaat, bespreek je met je QSA of betaalprovider.

Moet ik SRI uitbreiden naar alle pagina's?

Nee, niet per se. Begin bij pagina's waar gevoelige gegevens worden ingevoerd. Elke extra pagina betekent meer testwerk en meer kans op hash-fouten, dus doe het gericht.

Loopt je checkout vast na een deploy of CDN-wijziging, of wil je weten hoe jouw shop ervoor staat? Wij kijken mee en lossen het op. Neem contact op via /contact.