Security logging voor webshops: wat log je en wanneer gaat er een alarm af?

Een hack die je pas na weken ontdekt, kost meer dan een hack die je binnen een uur ziet. Logging en alerting bepalen welke van de twee jou overkomt.

In de OWASP Top 10:2025 heet dit A09 Security Logging & Alerting Failures. Let op het woord alerting. Een log die niemand leest of waar nooit een alarm uit komt, heeft bij een incident weinig waarde.

Dit artikel beschrijft welke events je vastlegt, hoe lang je ze bewaart, waar je ze naartoe stuurt en welke alerts de moeite waard zijn. Voor Magento, Shopify en Laravel.

Waarom logging zo vaak ontbreekt

Bij audits zien we steeds hetzelfde beeld:

• De webserver-logs bestaan, maar roteren na een paar dagen weg.
• Er is geen overzicht van wie wat in de admin heeft gedaan.
• Logs staan alleen op de server die gehackt is, dus een aanvaller kan ze wissen.
• Alerts gaan naar een mailbox die niemand leest, of er zijn er zoveel dat iedereen ze negeert.

Het gevolg komt terug in elk incident: je weet dat je gehackt bent, maar niet sinds wanneer, hoe, en wat er is aangeraakt. Dat maakt herstel en de afweging rond de meldplicht (72 uur bij de Autoriteit Persoonsgegevens, AVG art. 33) veel moeilijker. Het hoort bij je incident response plan.

Welke events log je?

Begin met events die het meeste zeggen over misbruik. Een praktische lijst:

Authenticatie en toegang

• Admin-logins, geslaagd en mislukt, met IP en user-agent
• Wachtwoord-resets en wijzigingen van e-mailadres bij admin-accounts
• 2FA-wijzigingen (uitgeschakeld, nieuw apparaat)
• Aanmaken, wijzigen of verwijderen van admin-gebruikers en rollen
• Wijzigingen in API-integraties en tokens
• Klantlogins, in elk geval de mislukte, voor credential stuffing

Configuratie en betalingen

• Wijzigingen in betaalmethoden en betaalprovider-instellingen
• Wijzigingen in verzend- en prijsinstellingen waar fraude mee mogelijk is
• Wijzigingen in CSP, scripts en tracking-codes die op de checkout geladen worden
• Wijzigingen in CMS-blokken en pagina's met JavaScript (een favoriete plek voor skimmers)
• Wijzigingen aan systeemconfiguratie en cron

Bestanden en code

• Nieuwe of gewijzigde bestanden in webroot, app/, vendor/ en pub/
• Nieuwe PHP-bestanden in upload- of mediamappen (zou nooit moeten)
• Wijzigingen aan .htaccess, nginx-config en composer.json/composer.lock buiten een deploy

Applicatie en verkeer

• 5xx-fouten en pieken daarin
• Verdachte requests: pogingen op bekende exploit-paden, ongebruikelijke REST-aanroepen, grote aantallen 404's
• Uitgaande verbindingen vanaf de webserver naar onverwachte bestemmingen
• Grote exports (klanten, orders) en bulk-API-aanroepen

Wat log je niet?

Logging kan zelf een privacyprobleem zijn. Leg niet vast:

• wachtwoorden, ook niet bij mislukte logins (gebruikers typen soms hun wachtwoord in het e-mailveld)
• volledige kaartgegevens of CVV (dat is ook een PCI DSS-kwestie, zie PCI DSS 4.0 voor webshops)
• sessietokens, API-keys en andere secrets
• complete request-bodies met persoonsgegevens, tenzij je een duidelijke reden hebt
• meer persoonsgegevens dan nodig voor het doel

Maskeer of laat weg wat je niet nodig hebt. Logging die zelf een datalek veroorzaakt, werkt averechts.

Bewaartermijn en AVG

Er is geen wettelijk getal dat voor alle webshops geldt. Het hangt af van doel en risico. Een gangbare werkwijze:

Dit zijn praktische richtlijnen, geen juridisch advies. Een IP-adres is een persoonsgegeven, dus je hebt een grondslag nodig (gerechtvaardigd belang voor beveiliging is gebruikelijk), een bewaartermijn die je kunt onderbouwen, en je legt het vast in je verwerkingsregister en privacyverklaring. Leg de termijn vast en laat logs daarna ook echt verdwijnen.

Voor PCI DSS 4.0 gelden eigen eisen voor logging en bewaren. Heb je een QSA of acquirer, volg dan hun eisen. Lees ook onze PCI DSS-pagina.

Centraliseren: logs buiten de server

Dit is het belangrijkste architectuurpunt. Een aanvaller met toegang tot je server kan lokale logs aanpassen of verwijderen. Stuur logs daarom weg.

Opties, van licht naar zwaar:

• Logs doorsturen naar een externe logdienst (hosted log management). Weinig onderhoud, goed voor kleine teams.
• Een eigen stack zoals Loki/Grafana of een ELK-opzet. Meer controle, meer beheer.
• Syslog naar een aparte, beveiligde server met alleen-schrijven rechten voor de bron.

Wat je hoe dan ook wilt:

• Tijdsynchronisatie (NTP) op alle servers, anders kloppen tijdlijnen niet.
• Een vast logformat (bij voorkeur gestructureerd, zoals JSON), zodat je kunt zoeken en filteren.
• Toegang tot logs beperkt tot wie het nodig heeft. Logs bevatten gevoelige informatie.
• Een test: kun je een incident van vorige maand nog terugvinden?

Draai je op Hypernode of vergelijkbare managed hosting, dan bepaalt het platform welke logs je kunt bereiken. Zie Magento hosting. Vraag vooraf na hoe lang logs beschikbaar zijn en hoe je ze exporteert.

Specifiek per platform

Magento. In Magento Open Source mis je vaak een volledige audittrail van beheeracties. Dat kun je oplossen met een gecontroleerde extensie of maatwerk, en met logging op database- of webserverniveau. Let op var/log (systeem- en debuglogs) en de nginx/PHP-FPM-logs. Zet monitoring op wijzigingen aan bestanden in app/, pub/ en vendor/. Shopify. Je hebt geen servertoegang. Shopify toont activiteit van medewerkers en wijzigingen in de admin, en je ziet de installatie van apps. Zet notificaties aan voor nieuwe staff-accounts en app-installaties, en controleer periodiek wie toegang heeft. Zie Shopify security. Laravel en Filament. Je hebt veel zelf in de hand. Gebruik de logkanalen van Laravel (stack, daily, naar een externe dienst), leg audit-events vast voor beheeracties in Filament, en log mislukte logins en autorisatiefouten. Zie de Laravel security checklist en de Filament-checklist.

Alerts die je wel leest

Het doel is weinig alerts, hoge precisie. Wie elke dag vijftig meldingen krijgt, leest er binnen een maand geen één meer.

Een nuttige eerste set, gerangschikt naar urgentie: