Security misconfiguration: 12 instellingen die webshops openzetten

De meeste hacks beginnen niet met een slimme exploit. Ze beginnen met een instelling die nooit is dichtgezet. Zo staat misconfiguration op nummer 2 in de OWASP Top 10:2025.

Security Misconfiguration is categorie A02 in de OWASP Top 10:2025. Het is het soort fout dat een scanner in minuten vindt en dat een developer in minuten oplost, mits iemand het ziet. Hieronder twaalf instellingen die we bij webshops vaak tegenkomen, met hoe je ze controleert en dichtzet. Het overzicht van alle OWASP-categorieën staat op /security/owasp.

1. Developer mode of debug aan op productie

Een shop in developer mode toont uitgebreide foutmeldingen, laadt minder geoptimaliseerd en kan interne paden en queries lekken. In Magento zet je productie op production mode:

bin/magento deploy:mode:show
bin/magento deploy:mode:set production

In Laravel hoort APP_DEBUG=false op productie. Met APP_DEBUG=true toont een fout je environment-variabelen, soms inclusief geheimen. Controleer het in je .env en in je deploy-proces. Meer over Laravel: Laravel security checklist voor productie.

2. .git, .env en andere bestanden in de webroot

Een map .git die via de webserver bereikbaar is, laat een aanvaller je broncode downloaden. Bestanden als .env, composer.json, auth.json, env.php-backups en docker-compose.yml bevatten vaak geheimen.

Test het: open https://jouwshop.nl/.git/config en https://jouwshop.nl/.env. Je wilt een 403 of 404.

Blokkeer verborgen bestanden in nginx:

location ~ /\. {
    deny all;
    return 404;
}

Beter nog: zorg dat de webroot alleen de publieke map bevat. In Magento is dat pub/, in Laravel public/. Dan staat er überhaupt niets gevoeligs binnen bereik.

3. phpinfo en testbestanden

Een vergeten phpinfo.php, info.php of test.php toont PHP-versie, modules, paden en environment-variabelen. Zoek ze op en verwijder ze. Zie ook onze Magento 2 security checklist.

4. Open Elasticsearch of OpenSearch

Search-services draaien vaak op poort 9200. Luistert de service op alle interfaces zonder authenticatie, dan kan iedereen je index lezen of wijzigen. Bind hem aan localhost of een intern netwerk en zet firewallregels aan. Heb je een externe cluster, dan hoort daar authenticatie en TLS bij.

Controleer vanaf buiten welke poorten bereikbaar zijn. Je wilt alleen 80 en 443 (en SSH gericht).

5. Redis zonder wachtwoord

Magento gebruikt Redis voor cache en vaak sessies. Redis zonder authenticatie, gebonden aan een publiek IP, is een bekende bron van overnames. Een aanvaller kan sessies lezen of manipuleren en, afhankelijk van de configuratie, verder komen.

• Bind Redis aan localhost of een privé-netwerk.
• Zet een wachtwoord (requirepass of ACL's).
• Sluit de poort af in de firewall.

Sessies in Redis zijn trouwens een mooie reden om dit goed te doen. Bij kwetsbaarheden zoals SessionReaper (CVE-2025-54236) speelt het type sessie-opslag mee in de ernst van de impact. Zie security patches zonder downtime.

6. Directory listing aan

Staat autoindex on; aan in nginx of Options +Indexes in Apache, dan toont de server een bestandenlijst als er geen indexbestand is. Daarmee zien bezoekers uploads, exports en backups. Zet het uit:

autoindex off;

7. Staging zonder wachtwoord en geïndexeerd

Stagingomgevingen bevatten vaak productiedata en oudere code met bekende gaten. Staan ze open en indexeerbaar, dan vinden Google en aanvallers ze.

• Zet HTTP basic auth of een IP-beperking op staging.
• Zet noindex en een Disallow in robots (dat laatste beschermt niet, het voorkomt alleen indexering).
• Gebruik geen echte klantdata op staging, of maskeer die.
• Laat staging geen echte mails of betalingen versturen.

8. Standaardaccounts en zwakke wachtwoorden

Controleer:

• Een oud admin-account van een vertrokken medewerker of ontwikkelaar.
• Testaccounts met admin/admin123.
• Databasegebruikers met te brede rechten of hetzelfde wachtwoord als elders.
• Standaardlogins van tooling (monitoring, Kibana, phpMyAdmin, Adminer).

Zet 2FA aan voor alle admin-accounts. Dat is in Magento standaard actief sinds 2.4.0; schakel het niet uit. Meer in Magento admin beveiligen.

9. Verbose errors en stacktraces

Foutmeldingen met SQL, paden of stacktraces helpen een aanvaller. Toon bezoekers een nette foutpagina en stuur details naar je logs. Test dit door een niet-bestaande pagina of een ongeldige parameter aan te roepen. In Laravel regelt APP_DEBUG=false veel, in Magento production mode. Ook je API moet geen interne foutdetails teruggeven. Zie API-beveiliging voor e-commerce integraties.

10. CORS met op gevoelige endpoints

11. Oude backups in de webroot

Een backup.zip, db.sql of shop-2023.tar.gz in pub/ is een databasedump voor wie hem vindt. Dit is een van de simpelste routes naar een datalek. Bewaar backups buiten de webroot, versleuteld, op een andere locatie. Zoek op productie naar grote archief- en dumpbestanden in publiek bereikbare mappen en verwijder ze.

12. Ontbrekende security headers en een losse CSP

Headers zijn geen wondermiddel, maar een lijst ontbrekende headers laat zien dat niemand ernaar heeft gekeken. Denk aan Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy en een Content Security Policy.

Bij Magento 2.4.7 staat CSP standaard in restrict mode op betaalpagina's en report-only elders, samen met Subresource Integrity voor JavaScript op betaalpagina's. Dat is gericht op PCI DSS 4.0 eis 6.4.3 en 11.6.1. Strikte CSP breekt vaak extensies en inline scripts, dus test goed. Met Hyvä werk je zonder unsafe-eval dankzij de CSP-compatibele Alpine-aanpak. Meer over de eisen: /security/pci-dss en PCI DSS 4.0 voor webshops.

Snelle zelfcontrole in tien minuten

Je kunt veel zelf nagaan.

# Verborgen bestanden
curl -sI https://jouwshop.nl/.git/config | head -n 1
curl -sI https://jouwshop.nl/.env | head -n 1

# Headers
curl -sI https://jouwshop.nl | grep -iE 'strict-transport|x-content-type|referrer|content-security'

# Poorten (vanaf een machine buiten je netwerk, alleen op je eigen server)
nmap -p 22,80,443,3306,6379,9200 jouwshop.nl

Alleen scannen wat van jou is. Verwacht dat 3306 (MySQL), 6379 (Redis) en 9200 (OpenSearch) van buiten dicht zijn.

Prioriteer: wat sluit je eerst?

Alle twaalf zijn de moeite waard, maar niet allemaal even urgent. Onze volgorde:

1. Alles wat data direct weggeeft: .git, .env, backups en dumps in de webroot, open Elasticsearch of OpenSearch, Redis zonder wachtwoord. Een aanvaller hoeft hier niets slims te doen.
2. Alles wat toegang geeft: standaardaccounts, oude admin-accounts, ontbrekende 2FA, staging zonder wachtwoord.
3. Alles wat informatie lekt: debug aan, verbose errors, phpinfo, directory listing.
4. Alles wat de schade beperkt: headers, CSP, CORS.

Je doet de eerste groep in een middag. De rest past in een normale sprint. Het is goedkoop werk met een hoog rendement, juist omdat het niet om nieuwe code gaat maar om instellingen.

Zo houd je het dicht

Eenmalig opschonen is niet genoeg, want configuratie driftt. Drie gewoontes helpen.

• Controle in je deploy. Laat je pipeline falen als APP_DEBUG=true op productie staat, of als de Magento-mode niet production is. Een kleine check voorkomt een grote fout.
• Periodieke externe blik. Draai elk kwartaal een poortscan en een controle op verborgen bestanden van buitenaf, zoals een aanvaller dat doet. Wat je intern niet ziet, ziet de buitenwereld wel.
• Oplevercheck bij elke migratie. Nieuwe server, nieuwe hoster of nieuwe omgeving: doorloop dezelfde lijst opnieuw. Standaardwaarden verschillen per omgeving.

Heb je een incident gehad dat teruggaat op een open service? Dan hoort de les in je processen. Zie wat te doen als je Magento-shop gehackt is en /security/gehackt.

Waarom het blijft gebeuren

Misconfiguratie heeft zelden één schuldige. Typische oorzaken:

• Een snelle fix "tijdelijk" open gezet en nooit teruggedraaid.
• Een migratie of nieuwe server met afwijkende standaardwaarden.
• Verschillende omgevingen die uit elkaar lopen.
• Niemand voelt zich eigenaar van server en applicatie samen.
• Geen herhaalde controle; het is eenmalig ingesteld.

Wat helpt: configuratie als code (zodat je ziet wat er verandert), een vaste checklist bij oplevering en een periodieke controle. Een security audit bekijkt precies deze zaken. Wat dat inhoudt: wat er bij een Magento security audit wordt gecontroleerd.

Hosting en rolverdeling

Bij een beheerde hostingpartner is een deel van de serverconfiguratie al geregeld. Bij Hypernode (waar wij Silver Partner van zijn) draagt de host zorg voor onderdelen van het platform, maar de applicatie-instellingen blijven van jou en je developer. Spreek dus af wie wat beheert. Zie Magento hosting. Een WAF vangt veel aanvallen op, maar repareert geen misconfiguratie. Zie ook Cloudflare Pro instellen.

Veelgestelde vragen

Wat is security misconfiguration?

Het gaat om onveilige instellingen: standaardwachtwoorden, onnodige open services, te uitgebreide foutmeldingen of ontbrekende beveiligingsmaatregelen. Het is categorie A02 in de OWASP Top 10:2025.

Hoe vind ik misconfiguraties op mijn shop?

Begin met een zelfcontrole: verborgen bestanden, headers en open poorten. Voor een volledig beeld laat je een security audit uitvoeren, waarbij server, applicatie en processen worden beoordeeld.

Is production mode voldoende voor Magento?

Het is een noodzakelijke basis, maar niet genoeg. Je moet ook services afschermen, bestanden uit de webroot houden, accounts opschonen en headers instellen.

Moet staging beveiligd zijn?

Ja. Staging bevat vaak productiecode en soms productiedata. Zet toegangscontrole en noindex aan en gebruik geen echte klantdata.

Lost een WAF misconfiguratie op?

Nee. Een WAF filtert verkeer, maar een open Redis of een .env die bereikbaar is via een andere route blijft een probleem. Zie een WAF als aanvulling.

Wil je dat iemand je configuratie nakijkt? Neem contact op of lees meer over onze security-diensten. Je spreekt direct met degene die de controle doet.