Een magecart skimmer steelt kaartgegevens op je checkout zonder dat je het merkt. Zo detecteer je hem, verwijder je hem echt en voorkom je een herhaling.
Een magecart skimmer is vaak maar een paar regels JavaScript. Die regels staan op je checkout en sturen kaartgegevens van je klanten door naar een server van een ander. Je shop blijft gewoon werken. Orders komen binnen. Je merkt niets, tot je PSP, een bank of een klant aan de bel trekt.
Dit artikel gaat over die ene aanval: hoe een creditcard skimmer in je webshop komt, hoe je hem vindt en hoe je hem echt verwijdert. Heb je een breder incident en wil je weten wat er in de eerste 24 uur moet gebeuren? Lees dan Magento 2 gehackt: wat nu?. Hier gaan we dieper op de skimmer zelf.
Wat is een Magecart skimmer?
Magecart is de verzamelnaam voor groepen die betaalgegevens stelen met JavaScript in de browser van de klant. Het is client-side skimming. De aanvaller hoeft je database niet te lezen. Hij leest wat de klant intikt, op het moment dat de klant het intikt.
Twee eigenschappen maken dit lastig:
- Het is onzichtbaar voor de klant. De checkout ziet er normaal uit en werkt normaal.
- Het is onzichtbaar voor je servermonitoring. CPU, load en foutlogs blijven rustig.
Daarom blijven skimmers vaak lang zitten. Ze verdwijnen ook niet door een cache flush. De code staat ergens persistent: in een bestand, in de database of bij een externe partij.
Hoe een skimmer in je checkout komt
Er zijn vijf routes die we steeds terugzien in de bekende aanvalspatronen. De aanvaller wil één ding: eigen JavaScript laten draaien op de betaalpagina.
1. Gecompromitteerd admin-account
Een gelekt of hergebruikt wachtwoord is genoeg. Wie in de admin kan, kan scripts toevoegen aan de pagina. Geen exploit nodig. Zonder 2FA op de admin is dit de goedkoopste route.
2. Kwetsbare extensie of verouderde Magento-versie
Een kwetsbaarheid in een module of in de core geeft de aanvaller schrijfrechten op bestanden of database. Daarna plaatst hij zijn script. Tijdig patchen is je belangrijkste verdediging. Zie ook de Magento 2 security checklist.
3. Script van een derde partij
Je laadt een chat widget, tag manager of tracking pixel van een extern domein. Wordt die partij gehackt, dan draait de aanvaller code op jouw checkout. Jij hebt niets fout gedaan en toch lekt je shop.
4. Injectie in CMS-blokken en admin-velden
In Magento kun je HTML en scripts plaatsen via CMS-blokken, CMS-pagina's en de design-configuratie (head en footer). Een aanvaller met admin-toegang, of met een SQL-injectie, zet daar een script neer. Het staat dan in de database, niet in een bestand.
5. Directe wijziging in core_config_data
De design-instellingen voor extra scripts in de head en footer staan in de tabel core_config_data. Bijvoorbeeld onder de paden design/head/includes en design/footer/absolute_footer. Een file integrity check ziet dit niet. Veel schoonmaakacties missen het daardoor ook.
Detecteren: waar kijk je?
Een skimmer vind je niet met één tool. Je kijkt op vijf plekken. Doe ze alle vijf, want een aanvaller laat vaak meer dan één achterdeur achter.
| Plek | Wat je zoekt | Wat je daarvoor nodig hebt |
|---|---|---|
| Bestanden op de server | Gewijzigde of onbekende PHP- en JS-bestanden | Vergelijking met een schone release of Git-repo |
| Database | Scripts in CMS-blokken, pagina's en core_config_data | Zoekopdrachten op script-tags en externe domeinen |
| Checkout in de browser | Scripts van domeinen die je niet kent | Developer tools, tabblad Network |
| CSP-rapporten | Geblokkeerde of onverwachte bronnen | Een reporting-endpoint |
| Uitgaand verkeer | Verbindingen naar onbekende hosts | Server- of netwerklogs |
Stap 1: vergelijk bestanden met een schone bron
Heb je je code in Git en deploy je vanuit een pipeline? Dan is dit snel. Vergelijk wat op productie staat met wat je zou deployen. Elk verschil dat je niet kunt verklaren is verdacht.
Heb je geen schone bron, dan installeer je dezelfde Magento-versie en dezelfde extensies vers en vergelijk je de checksums. Let vooral op:
- bestanden in
pub/enapp/codedie niet bij een module horen; - recent gewijzigde bestanden met een datum die niet bij een deploy past;
- JS- en PHP-bestanden met onleesbare, versleutelde of sterk geobfusceerde inhoud;
- templates en layout XML die extra scripts laden.
Er bestaan ook scanners voor Magento. Gebruik ze als aanvulling. Een scanner die niets vindt bewijst niets: skimmers zijn vaak speciaal gebouwd om detectie te omzeilen.
Stap 2: scan de database
Doe dit apart van de bestanden. Zoek in:
core_config_data, op de design-paden voor head en footer;cms_blockencms_page, in de kolom met de inhoud;- eventueel extra tabellen van pagebuilder- of banner-modules.
Zoek op
Stap 3: bekijk de checkout als klant
Open de checkout in een schone browser. Open de developer tools en ga naar het tabblad Network. Doorloop de stappen tot en met de betaalstap.
Kijk naar:
- welke domeinen scripts leveren;
- welke requests er worden verstuurd op het moment dat je een veld invult of op betalen klikt;
- of er requests naar een domein gaan dat je niet kent.
Doe dit ook op mobiel en met een andere locatie of user agent als dat kan. Sommige skimmers laten zich alleen zien aan bepaalde bezoekers of alleen als de developer tools dicht zijn. Een schone check is dus geen garantie. Daarom heb je ook de volgende stappen nodig.
Stap 4: gebruik CSP-rapporten als alarm
Een Content Security Policy (CSP) bepaalt welke bronnen de browser mag laden. Een CSP met reporting werkt als alarm: elke niet-toegestane bron levert een rapport op.
Magento ondersteunt CSP in de core. Volgens de Adobe Commerce-documentatie draait CSP sinds versie 2.4.7 standaard in restrict-modus op betaalpagina's (storefront en admin) en in report-only-modus op de rest. Voor 2.4.7 was het overal report-only. Controleer de instellingen op jouw versie, want dit verschilt per release en per configuratie.
Een rapport van een onbekend domein op je checkout is een reden om direct te onderzoeken.
Stap 5: kijk naar uitgaand verkeer
Een skimmer moet de gestolen data ergens heen sturen. Dat gebeurt meestal vanuit de browser van de klant, dus je serverlogs zien dat niet. Gebruikt de aanvaller ook server-side code, dan zie je uitgaande verbindingen naar onbekende hosts. Bekijk daarvoor firewall- of hostinglogs. Vraag je hostingpartij om hulp als je die inzage niet zelf hebt.
Verwijderen: zo ruim je echt op
Eén gevonden script weghalen is niet genoeg. Als je alleen het symptoom verwijdert, staat de skimmer binnen een dag weer terug. Werk in deze volgorde.
- Maak een forensische kopie. Bewaar bestanden, database en logs voordat je iets wijzigt. Je hebt dit nodig om de route te achterhalen en voor eventuele meldingen.
- Zet de checkout tijdelijk veilig. Is het mogelijk om kaartinvoer op de betaalpagina van je PSP te laten doen (redirect of hosted fields)? Doe dat tijdens de opruiming. Dan komt er in elk geval geen nieuwe data meer langs je eigen pagina.
- Verwijder de gevonden code overal. Bestanden, CMS-blokken, design-configuratie, extra tabellen. Verwijder alle plekken, niet alleen de eerste.
- Vervang in plaats van schoonmaken. Herstel gewijzigde core- en vendorbestanden door een verse installatie van dezelfde versie via Composer. Handmatig "schoonpoetsen" laat restanten achter.
- Zoek de achterdeur. Controleer op onbekende admin-gebruikers, nieuwe API-integraties, cronjobs en PHP-bestanden op plekken waar ze niet horen. Anders komt de aanvaller terug.
- Sluit het lek. Patch Magento en alle extensies. Verwijder extensies die je niet gebruikt of waarvan de leverancier niet meer bijwerkt.
- Roteer alle credentials. Admin-wachtwoorden, database, API-keys, SSH-sleutels, PSP-koppelingen, de encryptiesleutel van Magento en tokens van integraties. Zet 2FA aan voor elke admin.
- Monitor daarna extra scherp. Laat CSP-rapporten en de checks uit stap 3 en 4 de komende weken vaker lopen.
De eerlijke versie: bij twijfel over de omvang is een volledige herbouw van de server vanuit een schone bron sneller en betrouwbaarder dan jagen op restanten.
Na de opruiming: melden en communiceren
Skimming betekent dat klantgegevens zijn gelekt. Dan gelden er meldverplichtingen. Dit is geen juridisch advies; leg je situatie voor aan je privacyfunctionaris of jurist.
- Autoriteit Persoonsgegevens. Onder de AVG (artikel 33) meld je een datalek zonder onnodige vertraging en uiterlijk 72 uur nadat je ervan op de hoogte bent, tenzij het lek waarschijnlijk geen risico oplevert voor de betrokkenen. Controleer de actuele werkwijze en het meldformulier op de website van de AP.
- Betrokkenen. Is het risico hoog, dan informeer je ook de klanten zonder onnodige vertraging.
- Je PSP en acquirer. Neem contact op met je betaalpartij. Kaarthouders en kaartschema's kunnen eigen procedures hebben. Controleer wat in jouw contract staat.
- Intern register. Leg elk datalek vast, ook als je niet meldt. Noteer wat er gebeurde en waarom je wel of niet meldde.
Wil je weten wat je als shop verder moet regelen rond persoonsgegevens? Zie GDPR voor e-commerce in 2026.
Voorkomen: maak het de aanvaller moeilijk
Preventie draait om één principe: weet precies welke scripts op je checkout draaien en blokkeer de rest.
- CSP in restrict-modus. Sta alleen domeinen toe die je nodig hebt. Zet reporting aan en lees de rapporten.
- Subresource Integrity (SRI). Laad je een extern script, voeg dan een integriteitshash toe. Verandert het bestand bij de leverancier, dan blokkeert de browser het. Dat werkt alleen voor bestanden die niet wekelijks veranderen.
- Minder scripts op de checkout. Trackers, chat widgets en A/B-tests horen niet op de betaalstap. Elk script is aanvalsoppervlak.
- Verwijder ongebruikte extensies en scripts. Wat niet draait kan niet gehackt worden.
- 2FA op admin, beperkte rechten. Niet iedereen hoeft design-configuratie te kunnen wijzigen.
- Patchen met een vaste cadans. Plan security updates in, geen ad-hoc beslissing.
- Gehoste betaalvelden. Laat de PSP de kaartinvoer verzorgen via hosted fields of een redirect. Dan staat het kaartnummer niet in een veld dat jouw JavaScript kan lezen. Het risico daalt sterk, maar verdwijnt niet: een script op je pagina kan nog steeds het formulier manipuleren of omleiden.
PCI DSS 4.0 en betaalpagina's
PCI DSS 4.0 bevat twee eisen die hier direct over gaan. Eis 6.4.3 vraagt om autorisatie, integriteitscontrole en een inventaris met onderbouwing van alle scripts op de betaalpagina. Eis 11.6.1 vraagt om detectie van ongeautoriseerde wijzigingen in de headers en inhoud van betaalpagina's. Bronnen geven aan dat beide sinds 31 maart 2025 verplicht zijn. Of en hoe dit voor jouw shop geldt, hangt af van je betaalopzet (bijvoorbeeld redirect of hosted fields) en je vragenlijst (SAQ). Controleer dat met je acquirer of QSA.
Checklist: skimmer-scan in 15 minuten
- [ ] Checkout geopend met developer tools, alle scriptdomeinen genoteerd
- [ ] Elk extern domein gekoppeld aan een bekende leverancier
- [ ]
core_config_datadoorzocht op scripts in head en footer - [ ] CMS-blokken en -pagina's doorzocht op
- [ ] Bestanden vergeleken met een schone release
- [ ] Admin-gebruikers en API-integraties gecontroleerd
- [ ] CSP met reporting actief op de checkout
- [ ] 2FA aan voor alle admin-accounts
Veelgestelde vragen
Hoe weet ik of mijn webshop een skimmer heeft?
Je ziet het vaak niet zelf. Controleer de checkout in de developer tools op onbekende scriptdomeinen, doorzoek core_config_data en CMS-blokken op scripts, en vergelijk je bestanden met een schone release. Signalen van buiten zijn meldingen van je PSP, een bank of klanten met misbruikte kaarten.
Is een skimmer weg na een cache flush of herinstallatie?
Nee. De code staat in bestanden, in de database of bij een externe leverancier. Een cache flush verandert daar niets aan. Verwijder de code overal, herstel gewijzigde bestanden vanuit een schone bron en roteer alle credentials, anders komt de aanvaller via dezelfde route terug.
Moet ik een skimmer melden bij de Autoriteit Persoonsgegevens?
Gaat het om gelekte persoonsgegevens, dan geldt onder de AVG meestal een meldplicht binnen 72 uur na ontdekking, tenzij het risico voor betrokkenen waarschijnlijk uitblijft. Dit is geen juridisch advies. Controleer de actuele regels bij de AP en vraag je jurist of privacyfunctionaris.
Beschermt een CSP volledig tegen Magecart?
Nee. Een strikte CSP blokkeert scripts van niet-toegestane domeinen en geeft rapporten. Maar een aanvaller kan code plaatsen vanaf een domein dat je al toestaat, of inline scripts gebruiken als die zijn toegestaan. CSP is een sterke laag, geen volledige oplossing. Combineer met SRI, monitoring en minder scripts.
Helpt een hosted betaalpagina van mijn PSP?
Ja, het verkleint het risico flink. Het kaartnummer wordt dan ingevoerd op een pagina of in velden van de PSP. Het verdwijnt niet helemaal: ook je eigen pagina kan worden gemanipuleerd, bijvoorbeeld met een nepformulier of een omleiding. Houd je checkout dus schoon.
Vermoed je een skimmer op je Magento-shop, of wil je weten wat er nu op je checkout draait? Neem contact met ons op. Meer over onze aanpak vind je op onze pagina's over security en Magento support.
Geschreven door Ruthger Idema
15+ jaar ervaring in e-commerce development. Gespecialiseerd in Magento, Shopify en Laravel maatwerk.
Meer over ons team →
