Magento GraphQL en REST API beveiligen: endpoints en tokens

Je Magento-shop heeft twee grote deuren die altijd openstaan: REST en GraphQL. Beide zijn bedoeld voor anonieme bezoekers, en juist daarom wordt er veel misbruikt.

Dit artikel loopt langs wat er standaard publiek is, waar het misgaat en wat wij in de praktijk dichtzetten. Geen theorie over API-ontwerp, wel concrete maatregelen.

Waarom de API je grootste aanvalsoppervlak is

Een headless storefront, een PWA, een koppeling met je ERP, een app: ze praten allemaal via de API. Ook een gewone Luma- of Hyvä-shop gebruikt REST en GraphQL op de achtergrond voor winkelmand, checkout en zoeken.

Dat betekent twee dingen:

• Je kunt de API niet simpelweg uitzetten.
• Een deel van de endpoints is per definitie bereikbaar zonder inlog.

Het lek SessionReaper (CVE-2025-54236, CVSS 9.1, september 2025) laat zien hoe duur dat is. De kwetsbaarheid zat in onjuiste inputvalidatie in de REST API. Gevolg: accountovername, en bij file-based sessies zelfs remote code execution. Adobe publiceerde de fix in bulletin APSB25-88. Eind oktober 2025 werd het lek actief misbruikt. Shops die de patch nog niet hadden, stonden open.

De les is niet "REST is onveilig". De les is: het API-oppervlak verdient dezelfde aandacht als je admin. Lees ook ons overzicht van de grootste Magento-lekken.

Stap 1: weet wat er publiek is

Begin met een inventaris. Je kunt niet beschermen wat je niet kent.

• guest carts (/V1/guest-carts) voor gasten in de checkout;
• productlijsten en categorieën, afhankelijk van de ACL en de store-instelling;
• het aanmaken van een klantaccount;
• het opvragen van een klanttoken met e-mail en wachtwoord.

Dit doen wij bij een audit:

1. Alle routes uit de Swagger-documentatie van de shop ophalen en per route vaststellen of er auth nodig is.
2. De webserverlogs doorzoeken op welke API-routes daadwerkelijk worden aangeroepen.
3. Alle routes die niemand gebruikt, afschermen op webserver- of WAF-niveau.

Punt 3 wordt vaak vergeten. Gebruik je alleen GraphQL en geen REST voor de storefront? Dan kan REST voor het publiek vaak achter een allowlist. Check eerst of je betaalprovider of ERP-koppeling REST nodig heeft, want webhooks komen daar soms binnen.

Stap 2: tokens en integraties

Magento kent drie soorten toegang waar je op moet letten.

Integraties: least privilege

Maak voor elke koppeling een eigen integratie aan, met alleen de resources die nodig zijn. Een voorraadkoppeling heeft geen toegang tot klantgegevens nodig. Een boekhoudkoppeling hoeft geen producten aan te passen.

Wat we vaak zien bij audits: één integratie met "alle resources", gedeeld door vier leveranciers, nooit aangepast sinds de livegang. Als een van die leveranciers lekt, ligt je hele shop open.

Praktisch:

• één integratie per leverancier of systeem;
• minimale rechten;
• een lijst bijhouden wie welke sleutel heeft;
• sleutels intrekken en vernieuwen bij personeelswissel of leverancierswissel.

Admin tokens via de API

Admin-tokens zijn gevaarlijker dan je denkt. Een token dat je via de API ophaalt met admin-gebruikersnaam en wachtwoord, omzeilt in veel opzichten het gevoel van "we hebben 2FA aan". Gebruik voor koppelingen daarom integraties en geen persoonlijke admin-accounts. Zie ook ons artikel over admin beveiligen.

Levensduur van tokens

Magento heeft instellingen voor de geldigheid van admin- en klanttokens. Controleer in jouw versie wat er staat en kies een bewuste waarde. Een token dat nooit verloopt, is een wachtwoord dat je nooit meer kunt terugroepen.

Stap 3: GraphQL is geen REST met een ander jasje

GraphQL heeft eigen risico's, juist omdat de client de vorm van de query bepaalt.

Diepte en complexiteit

Een aanvaller kan een zwaar geneste query sturen die je database en PHP-workers vastzet. Het is geen exploit in de klassieke zin, maar een denial of service met één request.

Magento heeft instellingen om de maximale query-diepte en -complexiteit te begrenzen. Stel die in op waarden die jouw storefront werkelijk nodig heeft. Meet eerst wat je frontend verstuurt, en zet de limiet daar ruim boven maar niet oneindig.

Introspectie en foutmeldingen

Introspectie laat een client het hele schema opvragen. Dat is handig voor ontwikkelaars, en ook voor aanvallers. In productie hoeft dat niet voor iedereen open. Weet je dat je storefront het niet nodig heeft, blokkeer het dan op de WAF of de webserver. Is dit overkill voor een kleine shop zonder headless frontend? Vaak wel, het levert weinig op als je schema toch publiek gedocumenteerd is. Magento is open source en het standaardschema is bekend. Het gaat om je eigen custom schema-uitbreidingen.

Foutmeldingen horen in productie geen stacktraces te tonen. Controleer dat developer mode uit staat en dat custom resolvers geen interne details teruggeven.

Custom resolvers

Bij elke custom GraphQL-resolver stellen we dezelfde vragen:

• Controleert de resolver wie de aanvrager is?
• Controleert hij of de gevraagde order, het adres of de wishlist van díé klant is?
• Valideert hij alle argumenten, ook paginering en sortering?

Het tweede punt is een klassieker: broken access control. Een order-ID in een query die zonder eigenaarscontrole werkt, is een IDOR.

Stap 4: guest cart en checkout-abuse

Guest carts zijn bewust anoniem. Dat maakt ze een favoriet voor misbruik:

• Carting en voorraad blokkeren. Bots vullen mandjes met schaarse producten, zodat echte klanten niets meer kunnen kopen.
• Carding. Gestolen creditcards worden via je checkout getest met kleine bestellingen. Jij betaalt de transactiekosten en krijgt de chargebacks.
• Coupon- en gift-card-guessing. Het raden van codes via de API.
• Database-druk. Honderdduizenden lege quotes in je database.

Hiertegen help je niet met één instelling. Het is een combinatie:

1. Rate limiting per IP en per sessie op de relevante endpoints (zie hieronder).
2. Bot-detectie en challenge (Turnstile, reCAPTCHA of vergelijkbaar) op account aanmaken, inloggen en betalen.
3. Opruimen van oude quotes via cron.
4. Monitoring op afwijkende patronen, bijvoorbeeld honderden guest carts per minuut.

Ons artikel over WAF en bescherming tegen carding en scraping gaat hier dieper op in.

Stap 5: rate limiting

Rate limiting op de API is waar veel shops tekortschieten. Magento biedt hier in de applicatie beperkt houvast. Wij leggen het daarom bijna altijd bovenop de applicatie.

Opties, van simpel naar uitgebreid:

• nginx limit_req voor specifieke routes zoals inloggen en token-aanvragen.
• WAF-regels bij Cloudflare of een vergelijkbare dienst, met een lage drempel voor /rest/V1/integration/ en /rest/V1/guest-carts.
• Fail2ban op basis van logs, voor herhaalde 401- en 403-responses.

Een voorbeeld voor nginx:

limit_req_zone $binary_remote_addr zone=api_login:10m rate=5r/m;

location ~ ^/rest/(.*/)?V1/integration/(customer|admin)/token {
    limit_req zone=api_login burst=5 nodelay;
    # daarna door naar PHP-FPM zoals gebruikelijk
    try_files $uri $uri/ /index.php$is_args$args;
}

Let op: rate limiting per IP werkt slecht als al je verkeer via een proxy of CDN binnenkomt. Zorg dat nginx het echte client-IP kent, bijvoorbeeld met real_ip_header, anders blokkeer je al je klanten tegelijk.

Zet drempels niet te strak. Een kantoor of een mobiel netwerk deelt één IP. Begin met loggen in plaats van blokkeren, kijk een week naar de data en trek dan pas de schroef aan.

Stap 6: patchen en monitoren

De beste API-beveiliging is een actuele Magento. SessionReaper, CosmicSting (CVE-2024-34102) en TrojanOrders (CVE-2022-24086) hadden gemeen dat ze via een publiek bereikbare route werden misbruikt, en dat de fix al beschikbaar was toen de massale aanvallen begonnen. Zie ons artikel over patchen zonder downtime.

Monitoring die we standaard inrichten:

• alerts op een piek van 4xx/5xx op API-routes;
• alerts op nieuwe integraties en nieuwe admin-tokens;
• logging van token-aanvragen met IP en user agent;
• een wekelijkse blik op de top-10 aangeroepen API-routes.

Checklist API-beveiliging

• [ ] Inventaris van publieke REST- en GraphQL-routes
• [ ] Ongebruikte routes afgeschermd op webserver of WAF
• [ ] Per koppeling een eigen integratie met minimale rechten
• [ ] Geen persoonlijke admin-accounts in koppelingen
• [ ] Token-levensduur bewust ingesteld
• [ ] GraphQL-diepte en -complexiteit begrensd
• [ ] Custom resolvers controleren eigenaarschap
• [ ] Rate limiting op login, token en guest cart
• [ ] Bot-challenge op registratie en checkout
• [ ] Oude quotes worden opgeruimd
• [ ] Magento-patches binnen dagen, niet maanden
• [ ] Logging en alerts op API-verkeer

Veelgestelde vragen

Moet ik de REST API uitzetten als ik alleen GraphQL gebruik?

Niet volledig uitzetten, maar wel afschermen voor het publiek. Magento gebruikt REST op meerdere plekken intern, en koppelingen of betaalproviders kunnen het nodig hebben. Check de logs, laat alleen toe wat je ziet, en blokkeer de rest op webserver- of WAF-niveau.

Is GraphQL veiliger dan REST?

Nee, anders. GraphQL heeft één endpoint en een flexibele querytaal, waardoor diepte, complexiteit en autorisatie per veld belangrijker worden. REST heeft veel routes en dus meer ACL-configuratie. Beide vragen om dezelfde basis: patchen, least privilege en rate limiting.

Helpt een WAF tegen API-misbruik?

Ja, voor volumeaanvallen, bekende exploit-patronen en bots. Het vervangt geen patch. Een WAF kan een nieuwe kwetsbaarheid soms dagen of uren dekken, maar een gerichte aanval op jouw custom endpoints vangt het niet altijd af.

Hoe vaak moeten integratietokens vervangen worden?

Altijd bij personeels- of leverancierswissel, na een incident en bij twijfel. Een vast ritme, bijvoorbeeld jaarlijks, is verstandig voor koppelingen die gevoelige data raken. Documenteer wie welke sleutel heeft, anders weet je niet wat je moet vervangen.

Waar begin ik als ik weinig tijd heb?

Bij drie dingen: Magento bijwerken naar de laatste security-patch, rate limiting op inloggen en token-aanvragen, en een opschoning van integraties met te ruime rechten. Dat dekt het grootste deel van het praktische risico.

Wil je weten wat er op jouw API open staat? Wij doen dat als onderdeel van een Magento security audit, of we regelen het doorlopend via Magento support. Je praat direct met degene die het uitvoert. Neem contact op via /contact. Meer over onze aanpak vind je op onze pagina Magento security.