API-beveiliging voor e-commerce integraties: wat je moet weten

API-beveiliging voor e-commerce integraties: wat je moet weten

94% van de webapplicaties bevat ten minste één kritieke kwetsbaarheid. Voor e-commerce API's zijn de gevolgen concreet: klantdata, betaalgegevens en orderhistorie liggen open voor wie weet waar hij moet kijken.

Een API-integratie zonder beveiliging is geen technisch probleem. Het is een juridisch, reputationeel en financieel risico. De GDPR boetes beginnen bij €20 miljoen of 4% van de wereldwijde jaaromzet — wat hoger is.

Dit artikel legt uit wat je nodig hebt. Geen theorie, maar concrete maatregelen gerangschikt op prioriteit.

Wat je leert in dit artikel

• Waarom API-beveiliging in e-commerce kritiek is
• OAuth 2.0 vs API keys vs JWT: wanneer gebruik je wat
• Rate limiting, input validatie en CORS correct instellen
• Webhook verificatie met HMAC signing
• Een prioriteitstabel zodat je weet waar je begint

Waarom e-commerce API's een specifiek risico zijn

Een e-commerce API verwerkt data die aanvallers direct geld oplevert.

Dit zijn geen theoretische aanvallen. Ze worden dagelijks uitgevoerd op onbeveiligde e-commerce systemen.

Authenticatie: OAuth 2.0 vs API keys vs JWT

Drie methoden domineren de markt. Ze hebben elk een ander toepassingsgebied.

API keys: eenvoudig maar gevaarlijk als ze lekken

API keys zijn strings die je meegeeft bij elk verzoek. Ze werken prima voor server-to-server communicatie waarbij beide kanten onder jouw controle staan.

Het risico: een API key die lekt in een Git repository of logbestand geeft volledige toegang. Roteer ze regelmatig. Sla ze nooit op in code.

// Correct: key ophalen uit omgevingsvariabele
$apiKey = config('services.erp.api_key');

// Nooit doen: key hardcoden in code
$apiKey = 'sk_live_abc123def456'; // Dit zit voor altijd in Git history

JWT: schaalbaar maar pas op met expiratie

JWTs bevatten de claims van een gebruiker of systeem, gesigneerd met een secret. De server hoeft geen sessie op te slaan — het token verifieert zichzelf.

Stel altijd een korte expiratie in. Een token dat nooit verloopt is een API key met extra stappen.

// Token aanmaken met korte levensduur
$token = JWT::encode([
    'sub' => $userId,
    'iat' => time(),
    'exp' => time() + 3600, // 1 uur geldig
    'scope' => 'orders:read',
], config('app.jwt_secret'), 'HS256');

OAuth 2.0: de standaard voor third-party toegang

Gebruik OAuth 2.0 als externe systemen namens een gebruiker toegang nodig hebben tot jouw API. De Client Credentials flow werkt voor machine-to-machine communicatie. De Authorization Code flow voor gebruikersautorisatie.

Laravel Passport implementeert OAuth 2.0 volledig. Voor eenvoudigere situaties is Laravel Sanctum een lichtgewichter alternatief.

Rate limiting: bescherming tegen misbruik en DDoS

Zonder rate limiting kan een aanvaller je API eindeloos bevragen. Dat levert hem data op en jou uitval.

Laravel heeft ingebouwde rate limiting via middleware. Stel het in op basis van gebruiker of IP-adres.

// In routes/api.php
Route::middleware(['auth:sanctum', 'throttle:60,1'])->group(function () {
    Route::get('/orders', [OrderController::class, 'index']);
    Route::post('/orders', [OrderController::class, 'store']);
});

// Aangepaste rate limiter per gebruikerstype
RateLimiter::for('api', function (Request $request) {
    return $request->user()
        ? Limit::perMinute(60)->by($request->user()->id)
        : Limit::perMinute(10)->by($request->ip());
});

Stel verschillende limieten in per endpoint. Een zoek-endpoint mag meer verzoeken verwerken dan een bestelendpoint. Kritieke endpoints zoals /checkout of /payment verdienen de strengste limieten.

Input validatie: vertrouw nooit de input

Elke waarde die via een API binnenkomt is potentieel kwaadaardig. SQL-injectie, XSS, malformed data — ze werken alleen als je input niet valideert.

Laravel's Form Requests maken validatie schaalbaar en testbaar.

class CreateOrderRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'product_id'   => ['required', 'integer', 'exists:products,id'],
            'quantity'     => ['required', 'integer', 'min:1', 'max:999'],
            'coupon_code'  => ['nullable', 'string', 'max:50', 'alpha_num'],
            'shipping'     => ['required', 'array'],
            'shipping.postcode' => ['required', 'string', 'regex:/^[1-9][0-9]{3}\s?[A-Z]{2}$/i'],
        ];
    }
}

Valideer op type, formaat, bereik en bestaan. Verwerp alles wat niet aan de verwachting voldoet. Stuur nooit een interne foutmelding terug in productie — log de fout intern, geef de gebruiker een generieke melding.

SQL-injectie voorkomen

Gebruik altijd Eloquent of query builder met parameter binding. Nooit ruwe SQL-strings met gebruikersinput.

// Veilig: parameter binding
$orders = Order::where('customer_id', $customerId)
               ->where('status', $status)
               ->get();

// Onveilig: directe interpolatie
$orders = DB::select("SELECT * FROM orders WHERE customer_id = $customerId");

HTTPS en CORS: de basishygiëne

HTTPS overal

Stuur nooit API-data over HTTP. Gebruik TLS 1.2 minimaal, bij voorkeur TLS 1.3. Voeg HSTS headers toe zodat browsers HTTP-verbindingen weigeren.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Zorg dat je certificaat automatisch verlengt. Een verlopen certificaat op een productie-API is een beveiligingsincident.

CORS correct configureren

Cross-Origin Resource Sharing bepaalt welke domeinen je API mogen bevragen vanuit de browser. Een te brede CORS-configuratie maakt je kwetsbaar voor Cross-Site Request Forgery.

// config/cors.php
return [
    'paths'           => ['api/*'],
    'allowed_origins' => [
        'https://jouwwebshop.nl',
        'https://www.jouwwebshop.nl',
    ],
    'allowed_methods' => ['GET', 'POST', 'PUT', 'DELETE'],
    'allowed_headers' => ['Content-Type', 'Authorization', 'X-Requested-With'],
    'max_age'         => 3600,
];

Gebruik nooit 'allowed_origins' => ['*'] op een productie-API die gevoelige data verwerkt. Dat geeft elk domein ter wereld toegang.

Webhook verificatie met HMAC signing

Webhooks van betaalproviders zijn een geliefd aanvalsvector. Een aanvaller stuurt een nep-betalingsbevestiging naar jouw webhook-endpoint. Als je niet verifieert of het verzoek echt van Mollie of Stripe komt, verwerk je een valse betaling.

HMAC signing is de oplossing. De provider ondertekent elk verzoek met een gedeeld secret. Jij verifieert de handtekening.

class WebhookController extends Controller
{
    public function handleMollie(Request $request): Response
    {
        // Haal de handtekening op uit de header
        $signature = $request->header('Mollie-Signature');

        // Bereken de verwachte handtekening
        $expectedSignature = hash_hmac(
            'sha256',
            $request->getContent(),
            config('services.mollie.webhook_secret')
        );

        // Vergelijk op tijdconstante manier (voorkomt timing attacks)
        if (! hash_equals($expectedSignature, $signature)) {
            return response('Ongeldige handtekening', 401);
        }

        // Verwerk de webhook pas na verificatie
        $paymentId = $request->input('id');
        ProcessMolliePayment::dispatch($paymentId);

        return response('OK', 200);
    }
}

Gebruik altijd hash_equals() voor vergelijking. Een normale stringvergelijking is kwetsbaar voor timing attacks waarmee een aanvaller de handtekening bit voor bit kan raden.

Logging en monitoring

Je weet pas dat er iets mis gaat als je het meet.

Log alle API-verzoeken met statuscode, tijdsduur en gebruiker. Sla geen gevoelige data op in logs — geen wachtwoorden, geen volledige kaartnummers.

Stel alerts in voor:

• Opeenvolgende 401/403 responses van hetzelfde IP (mogelijk brute-force aanval)
• Ongebruikelijk hoge verzoekvolumes
• 500-errors in productie
• Requests buiten kantoortijden op kritieke endpoints

Tools als Sentry, Datadog of Laravel Telescope geven je inzicht. Zonder monitoring is beveiliging blind.

Prioriteitstabel: waar begin je?

Niet alles kan tegelijk. Hier is de volgorde op basis van risico en impact.

Begin bovenaan. Als je HTTPS nog niet hebt: stop alles en regel dat vandaag.

Beveiliging en GDPR

Elke API die persoonsdata verwerkt valt onder de GDPR. Dat betekent:

• Doelbinding: sla alleen data op die je nodig hebt voor het opgegeven doel.
• Dataminimalisatie: stuur nooit meer data terug dan de client nodig heeft.
• Bewaartermijnen: verwijder data na de afgesproken periode automatisch.
• Meldplicht: een datalek moet binnen 72 uur gemeld worden bij de AP.

Een goed beveiligde API is ook een compliant API. Dat zijn geen tegengestelde doelen.

Lees meer over onze Laravel maatwerkontwikkeling of hoe wij Magento veilig houden met regelmatige security patches en code audits.

Conclusie: beveiliging is architectuur, niet afterthought

API-beveiliging is geen checkbox na livegang. Het is een architectuurbeslissing die je van het begin af aan meeneemt.

De meest voorkomende fouten die wij zien bij code-audits: geen rate limiting, webhook-endpoints zonder verificatie, API keys hardcoded in Git, en CORS die alles toelaat. Elk van die fouten is binnen een middag te verhelpen.

Wil je weten hoe jouw API-beveiliging ervoor staat? Neem contact op voor een vrijblijvende code audit.

Veelgestelde vragen

Wat is het verschil tussen OAuth 2.0 en API keys?

API keys zijn eenvoudige tokens voor server-to-server communicatie. OAuth 2.0 is een protocol voor gedelegeerde autorisatie, waarbij een gebruiker of systeem specifieke rechten verleent aan een derde partij. Gebruik API keys voor interne koppelingen, OAuth 2.0 als externe partijen namens gebruikers toegang nodig hebben.

Hoe werkt HMAC webhook verificatie?

De webhookprovider en jij delen een secret key. De provider berekent een handtekening over de webhookinhoud met die key en stuurt die mee als header. Jij berekent dezelfde handtekening lokaal en vergelijkt. Als ze niet overeenkomen, weiger je het verzoek.

Is JWT veilig voor API-authenticatie?

Ja, mits correct geïmplementeerd. Gebruik een sterk secret of een asymmetrisch sleutelpaar, stel een korte expiratie in (1 uur of minder), en gebruik altijd HTTPS. Een JWT zonder expiratie of verstuurd over HTTP is onveilig.

Wat zijn de GDPR-verplichtingen bij een API-datalek?

Je bent verplicht het datalek binnen 72 uur te melden bij de Autoriteit Persoonsgegevens als er een risico is voor de rechten van betrokkenen. Betroffen personen moet je ook informeren als het risico hoog is. Documenteer elk incident, ook als je besluit dat melding niet verplicht is.

Hoe test ik de beveiliging van mijn API?

Tools als OWASP ZAP, Postman (voor handmatige tests) en PHPStan (voor statische code-analyse) geven een goed startpunt. Voor grondige penetratietests is een externe security-audit aan te raden. Wij voeren code audits uit waarbij we ook beveiligingskwetsbaarheden in beeld brengen.