Hyvä security: CSP, Alpine.js en minder JavaScript

Elke regel JavaScript die je niet laadt, kan niet worden misbruikt. Dat is de kern van het security-argument voor Hyvä, en het is sterker dan het klinkt.

Dit artikel legt uit wat Hyvä wel en niet oplost, hoe Alpine.js samenwerkt met een Content Security Policy en waar je ook in een Hyvä-shop scherp moet blijven.

Minder JavaScript, kleiner aanvalsoppervlak

Een standaard Luma-shop laadt veel JavaScript: RequireJS, jQuery, Knockout, UI-componenten, plus de scripts van extensies en marketingtools. Elk script is een stuk code dat in de browser van je klant draait, met toegang tot de pagina.

Dat is precies wat Magecart-aanvallen uitbuiten. Een skimmer is JavaScript dat meeluistert met het betaalformulier en gegevens doorstuurt. Hoe meer scripts, hoe meer plekken waar zoiets kan binnenkomen, en hoe moeilijker het is om op te merken welk script er niet hoort. Zie ons artikel over Magecart-skimmers detecteren en verwijderen.

Hyvä is gebouwd met Alpine.js en Tailwind in plaats van de Luma-stack. Het resultaat:

• een veel kleinere JavaScript-basis;
• minder bibliotheken met eigen kwetsbaarheden en updatecyclus;
• minder afhankelijkheid van legacy-code;
• een overzichtelijker lijst van scripts die op de pagina horen.

Die kleinere basis helpt twee dingen: je loopt minder risico, en je kunt het risico makkelijker beoordelen. Een lijst van vijftien scripts is te controleren. Een lijst van tweehonderd niet.

Is Hyvä dan automatisch veilig? Nee. Het backend-gedeelte is nog steeds Magento, met dezelfde patch-verplichtingen. TrojanOrders, CosmicSting en SessionReaper zaten in de server-kant en raakten Luma- en Hyvä-shops net zo goed. Hyvä verkleint het frontend-oppervlak, niet het backend-risico.

Content Security Policy in een paar zinnen

Een CSP is een HTTP-header die de browser vertelt welke bronnen scripts, styles en afbeeldingen mogen laden en uitvoeren. Een script van een niet-toegestane bron wordt geblokkeerd. Zo beperkt CSP de schade van XSS en van geïnjecteerde skimmers.

Sinds Magento 2.4.7 staat CSP standaard in restrict mode op betaalpagina's en in report-only op de overige pagina's. Samen met Subresource Integrity voor JS op betaalpagina's is dat gericht op PCI DSS 4.0, eisen 6.4.3 en 11.6.1. Die eisen gaan over inventarisatie en integriteit van scripts op de betaalpagina en detectie van wijzigingen. Meer daarover in het artikel over PCI DSS 4.0 voor webshops en onze pagina over PCI DSS.

Een strikte CSP heeft een prijs: ze breekt dingen. Met name inline scripts en eval()-achtige constructies.

Waarom Alpine.js en CSP lastig samengaan

Alpine.js evalueert de expressies die je in HTML schrijft, zoals x-data="{ open: false }" of @click="open = !open". In de standaard build gebeurt dat met een constructie die in feite eval of new Function gebruikt. Een CSP die dat verbiedt, wat je met een strikte policy wilt, blokkeert dan de standaard-Alpine.

De klassieke oplossing is unsafe-eval toestaan in je script-src. Dat werkt, maar ondergraaft het doel. Met unsafe-eval mag de browser strings als code uitvoeren, en dat is precies wat een XSS-aanvaller wil.

De Alpine CSP-build

Alpine.js heeft een aparte CSP-compatibele build, die de expressies niet via eval uitvoert. Daardoor kun je een strikte policy hanteren zonder unsafe-eval. De afweging: je kunt in HTML-attributen minder vrij schrijven. Complexe inline-expressies moet je verplaatsen naar benoemde componenten in JavaScript, in plaats van ze direct in het attribuut te zetten.

Hyvä biedt een CSP-compatibele aanpak voor zijn Alpine-gebruik, zodat je geen unsafe-eval nodig hebt. Welke versies en welke thema- en moduleonderdelen dat precies dekken, verschilt per release. Check dus de actuele Hyvä-documentatie en de status van de modules die je gebruikt, voordat je op een bepaalde configuratie rekent.

Wat dat in de praktijk betekent voor ontwikkelaars:

• Componenten registreren via Alpine.data('naam', () => ({ ... })) in plaats van lange expressies in x-data.
• Handlers als functies, niet als inline-statements.
• Geen eval, new Function of string-timers in eigen code.
• Bij custom modules testen of de CSP-build ze nog aankan.

Dat is meer structuur, maar ook betere code: leesbaar, testbaar en te reviewen.

Hyvä Checkout en de betaalpagina

De betaalpagina is waar de meeste skimmers naar toe willen. Hier geldt ook voor Hyvä:

• Houd het aantal scripts op de checkout minimaal. Geen chatwidgets, heatmaps of A/B-tools op de betaalstap, tenzij je ze echt nodig hebt.
• Laad betaal-iframes van de PSP zelf: dan blijft de kaartinvoer buiten jouw scripts.
• Beperk script-src op de checkout tot je eigen domein en de betaalprovider.
• Zet SRI waar je externe scripts laadt en de leverancier stabiele bestanden levert.

Heb je een betaalmethode met een gehoste betaalpagina of iframe? Dan is de interpretatie van de PCI-eisen 6.4.3 en 11.6.1 in versie 4.0.1 aangepast voor merchants in die situatie, waarbij het draait om een verklaring dat de site niet vatbaar is voor scriptaanvallen. Overleg dit met je QSA of betaalprovider. Dit artikel is geen juridisch of auditadvies.

Waar je ook in Hyvä op moet blijven letten

Third-party scripts

Hyvä maakt je eigen frontend lichter, maar niets weerhoudt je ervan om via Google Tag Manager alsnog twintig marketingscripts te laden. Elke tag in GTM is een script met toegang tot je pagina. Wie mag GTM aanpassen? Wie krijgt een melding als een tag verandert? Dat is vaak de echte achterdeur.

Vragen die wij stellen:

• Welke scripts laadt de checkout echt?
• Wie heeft toegang tot GTM en andere tag managers, en heeft die persoon 2FA?
• Staan er tags van tools die niemand meer gebruikt?
• Worden scripts geladen van domeinen die niet van jou zijn en kunnen die veranderen?

XSS in Alpine-templates

Alpine kan HTML renderen met x-html. Zet je daar niet-vertrouwde data in, dan heb je XSS. Hetzelfde geldt voor data die je server-side in x-data serialiseert zonder correct te escapen. Gebruik x-text voor tekst, en gebruik x-html alleen met data die je zelf volledig vertrouwt.

Aan de PHP-kant heb je de bekende escape-functies nodig. Ons artikel over XSS in Magento voorkomen met $escaper gaat daar dieper op in, inclusief de valkuilen in Hyvä-templates waar PHP-data in een Alpine-attribuut terechtkomt.

Extensies en compatibiliteit

Hyvä-compatibiliteitsmodules vertalen Luma-extensies naar Alpine. Dat is nuttig, maar het blijft code van een andere partij. Controleer wie de module onderhoudt, hoe vaak hij wordt bijgewerkt en wat hij laadt. Lees extensies veilig kiezen voor een beoordelingsraam.

De backend blijft Magento

Alle patches voor Magento Open Source of Adobe Commerce gelden ook voor jouw Hyvä-shop. Een mooi licht frontend maakt een SessionReaper-achtig lek niet ongedaan. Zie Magento 2 security checklist.

Zo voer je een strikte CSP in op Hyvä: stappen

1. Begin in report-only. Stel een policy in, verzamel rapporten van echte bezoekers en bekijk welke bronnen er worden geladen.
2. Inventariseer scripts. Maak de lijst van wat nodig is. Wat niemand kan uitleggen, haal je weg.
3. Verplaats inline-code. Zet inline-scripts in bestanden of gebruik nonces/hashes waar Magento dat ondersteunt.
4. Gebruik de CSP-compatibele Alpine-aanpak en pas eigen componenten aan.
5. Test de volledige betaalflow per betaalmethode, op desktop en mobiel, inclusief 3-D Secure.
6. Ga stapsgewijs naar restrict, eerst op de checkout, later op andere pagina's.
7. Houd de rapportage actief. Een CSP-rapport dat een nieuw domein toont, is een vroege waarschuwing.

Een lege script-src 'self' zonder test breekt je checkout. Doe het dus altijd met rapportage eerst.

Wanneer is dit overkill?

Eerlijk is eerlijk: heb je een kleine catalogus, een hosted checkout bij je betaalprovider en weinig third-party scripts, dan is een volledige CSP-uitrol een gemiddelde investering voor een bescheiden winst. Begin dan met script-hygiëne (minder tags, 2FA op GTM) en patches. CSP is het zinvolst bij shops met een eigen checkout, veel scripts of PCI-verplichtingen.

Samenvatting in een tabel

Veelgestelde vragen

Is een Hyvä-shop veiliger dan een Luma-shop?

Aan de frontend-kant meestal wel, door minder JavaScript en een kleiner aanvalsoppervlak. De backend is hetzelfde Magento, dus patchen, serverbeveiliging en toegangsbeheer blijven even belangrijk. Beveiliging is meer dan het thema.

Heb ik unsafe-eval nodig voor Alpine.js?

Met de standaard Alpine-build wel. Met de CSP-compatibele build niet. Hyvä heeft een aanpak die CSP-compatibel kan werken, maar de details hangen af van je thema- en moduleversies. Controleer de actuele documentatie.

Helpt CSP tegen Magecart?

Ja, als je policy strikt genoeg is. Een skimmer die data naar een niet-toegestaan domein wil sturen of een script van een onbekende bron laadt, wordt geblokkeerd. CSP is geen volledige oplossing. Een skimmer die vanaf een toegestaan domein werkt, komt er wel doorheen. Combineer met SRI, monitoring en scriptbeheer.

Waar begin ik met CSP in Magento?

In report-only, op de checkout. Verzamel rapporten, inventariseer scripts en werk toe naar restrict. Lees ons uitgebreide artikel over CSP op de checkout.

Wat levert SRI naast CSP?

SRI controleert met een hash of een geladen script ongewijzigd is. CSP bepaalt welke bron mag laden, SRI of de inhoud klopt. Samen dekken ze verschillende aanvalsroutes. Zie SRI in Magento.

Wil je weten hoe jouw Hyvä-shop er qua security voor staat? Als Hyvä Silver Partner bouwen en beveiligen we Hyvä-shops zelf, met een vast team en korte lijnen. Bekijk onze Hyvä-pagina, onze aanpak voor Magento security of neem contact op via /contact.