Checklist voor het beveiligen van de Magento-admin in 2026

Aanvallers die in de Magento-admin komen, kunnen een skimmer aan de checkout toevoegen, klantdata exporteren of een verborgen adminaccount aanmaken voor later. De meeste geslaagde inbraken beginnen bij een zwakke plek die een checklist had opgemerkt: een hergebruikt wachtwoord, een oude extensie, een gemiste beveiligingspatch of een vergeten testaccount.

Gebruik de lijst hieronder als audit. Bij elk punt staat wat je moet controleren en, waar dat helpt, het exacte commando. Voer commando's uit vanuit de Magento-root als eigenaar van het bestandssysteem, en test eerst op de stagingomgeving.

1. Dwing tweestapsverificatie af voor elke admingebruiker

Sinds 2.4.0 is de Magento_TwoFactorAuth module standaard ingeschakeld en vereist die 2FA voordat een admingebruiker kan inloggen via de UI of de web-API. Ondersteunde providers zijn onder meer Google Authenticator, Duo Security en U2F-hardwaresleutels zoals YubiKey. In 2.4.9 hoeven admingebruikers maar één van de ingeschakelde providers in te stellen om binnen te komen.

Controleer of de module niet is uitgeschakeld, vaak door een developer tijdens lokaal testen:

bin/magento module:status Magento_TwoFactorAuth
bin/magento security:tfa:providers
# Force specific providers (comma-separated codes)
bin/magento config:set twofactorauth/general/force_providers google,u2fkey

Raakt iemand zijn apparaat kwijt, reset dan alleen diens provider in plaats van de module uit te schakelen:

bin/magento security:tfa:reset <admin_username> google

2. Gebruik een afwijkend adminpad

Adobe raadt het gebruik af van admin, backend of een ander gangbaar woord. Een willekeurig pad houdt een gerichte aanvaller niet tegen, maar haalt je wel uit het gros van de geautomatiseerde inlogpogingen.

bin/magento info:adminuri
bin/magento setup:config:set --backend-frontname="ops_7k2m9x"
bin/magento cache:flush

De admin-URI accepteert alleen letters, cijfers en underscores.

3. Beperk admintoegang op IP-adres

De security best practices van Adobe raden IP-allowlisting aan. Magento heeft geen ingebouwd IP-filter voor de admin, dus regel het op de webserver, load balancer, CDN of WAF. Een voorbeeld voor Nginx:

location ~* ^/(index\.php/)?ops_7k2m9x {
    allow 203.0.113.10;     # office
    allow 198.51.100.0/24;  # VPN range
    deny all;
    try_files $uri $uri/ /index.php$is_args$args;
}

Test dit zorgvuldig. Het PHP-handlerblok in je Nginx-configuratie moet de toegestane verzoeken nog steeds verwerken. Werkt je team op afstand, leid admintoegang dan via een VPN in plaats van een lange lijst thuis-IP's bij te houden.

4. Scherp de beveiligingsinstellingen van de admin aan

Controleer onder Stores > Configuration > Advanced > Admin > Securityde sessieduur, vergrendeling, geldigheidsduur van wachtwoorden en het delen van accounts. Je kunt ze via de CLI instellen, zodat ze in versiebeheer staan via config.php of env.php:

bin/magento config:set admin/security/session_lifetime 900
bin/magento config:set admin/security/lockout_failures 5
bin/magento config:set admin/security/lockout_threshold 30
bin/magento config:set admin/security/password_lifetime 90
bin/magento config:set admin/security/password_is_forced 1
bin/magento config:set admin/security/admin_account_sharing 0
bin/magento config:set admin/security/use_form_key 1

PCI DSS v4.0.1 eis 8.3.6 vraagt om wachtwoorden van minstens 12 tekens (8 als het systeem geen 12 ondersteunt). Het historische minimum voor de Magento-admin is 7. Adobe Commerce 2.4.9 maakt de minimale wachtwoordlengte voor de admin instelbaar in dezelfde sectie Security, nog een reden om die upgrade in te plannen.

Schakel ook reCAPTCHA in voor het inlogformulier en het formulier voor een vergeten wachtwoord van de admin, onder Stores > Configuration > Security > Google reCAPTCHA Admin Panel.

5. Pas minimale rechten toe op rollen en integraties

• Geef iedereen een eigen account. Geen gedeelde logins voor “marketing” of “het bureau”.
• Maak rollen aan in System > Permissions > User Roles die alleen de onderdelen dekken die elk team nodig heeft. Contentredacteuren hebben geen toegang nodig tot System of Stores > Configuration.
• Verwijder of deactiveer accounts van oud-medewerkers en bureaus op de dag dat hun toegang eindigt.
• Beperk API-integraties tot de minimaal benodigde onderdelen en vernieuw hun tokens regelmatig.

Controleer de admingebruikers elk kwartaal. Een snelle query helpt accounts te vinden die niemand herkent:

SELECT user_id, username, email, is_active, created, logdate
FROM admin_user
ORDER BY created DESC;

Een onbekend account dat onlangs is aangemaakt, is een sterk teken van een inbraak. Behandel het als een beveiligingsincident en start je responsplan.

6. Houd Content Security Policy afgedwongen op betaalpagina's

Sinds 2.4.7 stelt Adobe CSP standaard in op restrict mode voor betaalpagina's in zowel de storefront als de admin, en elders op report-only. Adobe voerde deze wijziging door, samen met ondersteuning voor Subresource Integrity, om merchants te helpen met de eisen van PCI DSS 4.0. Eis 6.4.3 vraagt om een inventaris, autorisatie en integriteitscontrole voor elk script op betaalpagina's, en eis 11.6.1 vraagt om detectie van wijzigingen en manipulatie op betaalpagina's. Beide zijn van kracht sinds 31 maart 2025.

De veelgemaakte fout is de checkout terugzetten naar report-only omdat het inline script van een extensie stukging. Repareer in plaats daarvan het script door het op de allowlist te zetten, met SecureHtmlRenderer of een nonce uit CspNonceProvider. Controleer of geen enkele module de standaardinstelling heeft overschreven:

grep -rn "report_only" app/code vendor/*/*/etc/config.xml | grep -v "vendor/magento"

Ter referentie: zo ziet restrict mode voor de checkout van de storefront eruit in het modulebestand config.xml:

<csp>
  <mode>
    <storefront_checkout_index_index>
      <report_only>0</report_only>
    </storefront_checkout_index_index>
  </mode>
</csp>

7. Patch volgens een vast ritme

Adobe publiceert regelmatig security releases (2.4.8 kreeg bijvoorbeeld de patches -p1 tot en met -p5 tussen juni 2025 en mei 2026) en zo nodig losse beveiligingspatches buiten het schema om. In september 2026 bracht Adobe APSB26-146 uit, een kritieke fix voor een kwetsbaarheid die volgens Adobe actief werd misbruikt, en adviseerde merchants om naast de hotfix ook hun inloggegevens te vernieuwen.

Een werkbare routine:

• Abonneer je op de security bulletins van Adobe en de meldingen van Commerce Security Scan.
• Voer kritieke fixes binnen enkele dagen door.
• Controleer met de Quality Patches Tool welke patches zijn toegepast:

vendor/bin/magento-patches status
composer audit

Blijf op een ondersteunde releaselijn. Volgens het lifecyclebeleid van Adobe eindigde de standaardondersteuning voor 2.4.6 op 11 augustus 2026.

8. Maak productiecode alleen-lezen

Draai in production mode en haal de schrijfrechten van codemappen weg, zodat een exploit via het web niet zomaar bestanden kan plaatsen. Het gedocumenteerde commando van Adobe voor een opzet met twee gebruikers:

bin/magento deploy:mode:show
find app/code lib pub/static app/etc generated/code generated/metadata var/view_preprocessed \
  \( -type d -or -type f \) -exec chmod g-w {} + && chmod o-rwx app/etc/env.php

Geef alleen tijdens deployments schrijfrechten terug en vergrendel daarna weer.

9. Schakel uit wat je niet gebruikt

Elke ingeschakelde module en elk endpoint is aanvalsoppervlak. Maak een lijst van wat actief is en schakel na het controleren van afhankelijkheden de modules uit die je niet gebruikt:

bin/magento module:status --enabled
bin/magento module:disable Vendor_UnusedModule
bin/magento setup:upgrade && bin/magento setup:di:compile

Controleer ook dat anonieme toegang tot REST-resources uit blijft staan:

bin/magento config:show webapi/webapisecurity/allow_insecure   # expect 0 or empty

Verwijder ongebruikte extensies van derden met Composer in plaats van ze uitgeschakeld te laten staan. Uitgeschakelde code gaat nog steeds mee in je release en moet nog steeds gepatcht worden.

10. Monitor, log en maak back-ups

• Scannen op malware en integriteit. De gratis Commerce Security Scan van Adobe controleert sites op bekende risico's en malware. Server-side scanners zoals Sansec eComscan zoeken in bestanden en de database naar malware, kwetsbare extensies en ongeautoriseerde adminaccounts.
• Activiteit in de admin. Adobe Commerce heeft de Admin Action Log. Stuur op Magento Open Source de logs van de webserver en var/log naar een centraal systeem en stel alerts in voor admin-logins vanaf nieuwe IP-adressen.
• Wijzigingsdetectie. Stel alerts in bij wijzigingen in checkout-templates, CMS-blokken en core_config_data records die scripts bevatten.
• Back-ups. Bewaar versleutelde back-ups van database en media buiten de server, bewaar app/etc/env.php (daarin staat je encryptiesleutel) in een aparte beveiligde kluis, en test minstens één keer per kwartaal een volledige restore.

Beknopte checklist

Veelgestelde vragen

Kan ik 2FA voor developers op de stagingomgeving uitschakelen?

Veel teams doen dat op lokale machines, maar laat het aan staan in elke omgeving die vanaf internet bereikbaar is. Een stagingomgeving bevat vaak een kopie van de productiedata en dezelfde admin-gebruikersnamen, en is daardoor een aantrekkelijk doelwit.

Is een eigen admin-URL genoeg bescherming?

Nee. Het vermindert geautomatiseerde ruis. Combineer het met 2FA, een IP-allowlist of VPN, vergrendelingsinstellingen en monitoring.

Maakt CSP alleen mijn checkout PCI-compliant?

Nee. CSP restrict mode en SRI helpen bij de autorisatie en integriteit van scripts op betaalpagina's, maar PCI DSS omvat veel meer, en je scope hangt af van hoe je betalingen ontvangt. Stem je verplichtingen af met je acquirer of QSA.

Hoe snel moeten we beveiligingspatches van Adobe doorvoeren?

Mik bij kritieke bulletins op enkele dagen, vooral bij kwetsbaarheden die Adobe als actief misbruikt aanmerkt. Reguliere security releases kunnen je normale test- en deploycyclus volgen, zolang die cyclus minstens maandelijks draait.

Bronnen

• Adobe Experience League: je Commerce-site en infrastructuur beveiligen
• Adobe Experience League: tweestapsverificatie
• Adobe Experience League: de admin-URI weergeven of wijzigen
• Adobe Experience League: admin-beveiliging configureren
• Adobe Developer: Content Security Policies
• Releasenotes Adobe Commerce 2.4.7
• Release notes van Adobe Commerce 2.4.9
• Adobe Experience League: uitgebrachte versies
• Adobe Experience League: lifecyclebeleid voor software
• Adobe: Critical security update APSB26-146
• Adobe Experience League: toegangsrechten voor het bestandssysteem
• PCI SSC: beveiliging van betaalpagina's en e-skimming voorkomen (6.4.3 en 11.6.1)
• SecurityMetrics: wachtwoordeisen in PCI DSS 4.0.1
• Sansec eComscan