OWASP ASVS: security-eisen vastleggen voor je maatwerk webshop

"Het moet veilig zijn" is geen eis. Het is een wens, en niemand kan er bij oplevering iets mee controleren.

Wie een maatwerk webshop, portal of API laat bouwen, zet dat vaak zo in de offerte of het projectplan. Achteraf blijkt dat de een er rate limiting onder verstond, de ander een pentest, en de derde niets. De OWASP Application Security Verification Standard (ASVS) is gemaakt om dat gat te dichten.

Dit artikel legt uit wat ASVS is, hoe je het gebruikt als acceptatiecriteria en welk niveau bij welk project past.

Wat is OWASP ASVS?

ASVS is een lijst van concrete, toetsbare security-eisen voor webapplicaties en API's, uitgegeven door OWASP. Elke eis is zo geformuleerd dat je kunt controleren of ze is gehaald: ja, nee of niet van toepassing.

Het verschilt van de OWASP Top 10:

Met de Top 10 weet je waar je op moet letten. Met ASVS leg je vast wat de applicatie moet doen. De OWASP Top 10:2025 en ASVS vullen elkaar aan. Er verscheen in 2025 een nieuwe hoofdversie van ASVS (5.0). In de praktijk spreek je gewoon af op welke versie je toetst en noteer je die in het contract.

De hoofdstukken gaan grofweg over: architectuur en ontwerp, authenticatie, sessiebeheer, toegangscontrole, validatie en encoding van input en output, cryptografie, foutafhandeling en logging, gegevensbescherming, communicatie, kwaadaardige code, bedrijfslogica, bestanden, API's en configuratie. De exacte indeling verschilt per versie.

De drie niveaus

ASVS kent drie niveaus van verificatie. Je kiest per applicatie wat past.

Niveau 1: basis. Eisen die je met een redelijke test grotendeels kunt controleren, ook zonder broncode. Het dekt de vaak voorkomende kwetsbaarheden. Bedoeld als minimum voor elke applicatie met internettoegang. Niveau 2: standaard. Voor applicaties met gevoelige data of belangrijke bedrijfsprocessen. Het bevat meer eisen over ontwerp, cryptografie, logging en bedrijfslogica. Voor de meeste serieuze bedrijfsapplicaties is dit het juiste niveau. Niveau 3: hoog. Voor applicaties waar een fout grote gevolgen heeft: medische, financiële of kritieke systemen. Vraagt diepe verificatie van ontwerp en code. Voor een gewone webshop is dit meestal overkill.

Welk niveau past bij een webshop of portal?

Een eerlijke vuistregel, geen wet:

Je hoeft niet het hele project op één niveau te zetten. Het loont om de applicatie in onderdelen te knippen. De checkout en het beheergedeelte verdienen strengere eisen dan de contactpagina.

Voor een standaard Magento-, Shopify- of Hyvä-webshop is een volledige ASVS-toets meestal niet de eerste stap. Daar begin je met patches, configuratie en extensies, zie de Magento 2 security checklist. ASVS wordt interessant zodra er maatwerk komt: eigen modules, een Laravel-backend, een klantportaal, een koppeling met je ERP.

Waarom het beter werkt dan "maak het veilig"

Een offerteregel als "de applicatie wordt veilig gebouwd" kent drie problemen:

1. Niet toetsbaar. Niemand kan bij oplevering zeggen dat het wel of niet is gehaald.
2. Niet prijsbaar. Een bureau dat veel doet, is duurder dan een bureau dat niets doet, terwijl beide hetzelfde beloven.
3. Niet te onderhouden. Over een jaar weet niemand meer welke afspraken golden.

Met ASVS maak je het concreet. In plaats van "veilig" schrijf je: "De applicatie voldoet aan ASVS niveau 2 voor de hoofdstukken authenticatie, sessiebeheer, toegangscontrole, input-validatie en logging, met uitzondering van de onderdelen die in bijlage A als niet van toepassing zijn gemarkeerd."

Dat geeft beide kanten houvast. Als opdrachtgever weet je wat je krijgt. Als bouwer weet je waar je op wordt beoordeeld.

ASVS gebruiken als acceptatiecriteria

Zo passen we het praktisch toe, zonder bureaucratie.

1. Kies niveau en scope

Bepaal per onderdeel het niveau. Noteer ook wat buiten scope valt, zoals een SaaS-betaalprovider of een gehoste dienst waar jij geen controle over hebt.

2. Maak een kort overzicht per hoofdstuk

Niet alle eisen zijn relevant. Doorloop de lijst en markeer per eis: van toepassing, niet van toepassing (met reden) of geaccepteerd risico (met eigenaar). Dit levert een document op dat je bij oplevering terugpakt.

3. Vertaal naar het ontwerp

Een deel van de eisen beslis je vóór het coderen. Denk aan rollen en rechten, hoe sessies werken, waar gegevens worden opgeslagen, welke API's er komen en hoe fouten worden afgehandeld. Beter eerst vastleggen dan later aanpassen.

4. Bouw de eisen in de definition of done

Per ticket of feature: welke ASVS-punten raakt dit? Een nieuwe API-endpoint raakt toegangscontrole, input-validatie en logging. Zet dat in je review-checklist, zie veilig bouwen met een klein team.

5. Test en verifieer

Combineer geautomatiseerde checks, code review en handmatige tests. Voor een deel van de eisen is een pentest de juiste verificatie, voor andere een code review. Een pentest dekt nooit alle ASVS-eisen; ze toetst wat een aanvaller kan bereiken.

6. Leg het resultaat vast

Per eis: gehaald, niet gehaald, niet van toepassing. Eventuele afwijkingen krijgen een eigenaar en een datum. Dit document is waardevol voor audits, voor klanten die vragen om bewijs en voor je opvolger.

Voorbeeld: ASVS-eisen voor een Laravel-klantportaal

Wat betekent dit in de praktijk? Geen volledige lijst, wel de aard van de eisen, vertaald naar acceptatiecriteria:

• Toegangscontrole: een gebruiker kan alleen gegevens van de eigen organisatie zien. Dit wordt per endpoint server-side afgedwongen, niet alleen verborgen in de interface. Test: een gebruiker van organisatie A vraagt met een geraden ID een record van B op en krijgt een fout.
• Authenticatie: wachtwoorden worden gehasht met een moderne, gangbare hash-functie. Er is rate limiting op login, en 2FA beschikbaar voor beheerders. Zie ook credential stuffing.
• Sessies: sessies verlopen, worden bij uitloggen ongeldig en bij een wachtwoordwijziging vernieuwd.
• Input en output: alle invoer wordt server-side gevalideerd, queries gebruiken parameters, en uitvoer wordt gecodeerd naar de context.
• Foutafhandeling: foutmeldingen tonen geen stacktraces of interne details aan gebruikers.
• Logging: inlogpogingen, rechtenwijzigingen en gevoelige acties worden gelogd zonder wachtwoorden of tokens, zie security logging.
• Configuratie: debug uit op productie, secrets buiten de repository, afhankelijkheden gecontroleerd op bekende kwetsbaarheden, zie de supply chain-aanpak.
• Bestanden: uploads worden gecontroleerd op type en grootte en opgeslagen buiten de webroot of met uitgeschakelde uitvoering.

Voor Laravel en Filament vind je hier meer: Laravel security, de productie-checklist en de Filament-checklist.

Wat ASVS niet is

Eerlijk blijven:

• Het is geen certificaat. Je kunt "voldoen aan ASVS niveau 2" claimen op basis van een toets, maar er is geen officiële certificering die je automatisch kunt halen.
• Het is geen vervanging van een pentest. Het is een lijst met eisen. Een pentest laat zien of ze in de praktijk standhouden.
• Het is geen reden om elk project zwaar te maken. Een kleine site heeft aan niveau 1 en gezond verstand genoeg. Een overdreven checklist vertraagt en levert niets.
• Het is geen juridisch of compliance-kader. Het helpt bij PCI DSS of NIS2, maar vervangt ze niet. Zie PCI DSS 4.0 en NIS2.

Wat levert het op?

• Een offerte waarin security prijsbaar en vergelijkbaar is.
• Minder discussie bij oplevering, omdat de criteria vooraf vaststaan.
• Een document dat je kunt tonen aan klanten, verzekeraars en auditors.
• Betere afstemming tussen bouwer, opdrachtgever en tester.

Veelgestelde vragen

Wat is het verschil tussen OWASP Top 10 en ASVS?

De Top 10 is een lijst van de grootste risicocategorieën, bedoeld om bewustzijn te creëren. ASVS is een lijst van toetsbare eisen die je kunt gebruiken om een applicatie te specificeren en te verifiëren.

Welk ASVS-niveau heb ik nodig voor mijn webshop?

Voor een standaard webshop met een externe betaalprovider is niveau 1 een redelijke basis, met niveau 2 voor onderdelen als klantaccounts, tegoeden, beheer en API's. Een B2B-portal of maatwerkplatform met gevoelige data valt meestal onder niveau 2.

Moet een Magento- of Shopify-shop aan ASVS voldoen?

Niet als geheel. Bij een standaardplatform ligt het zwaartepunt bij patches, configuratie en extensies. ASVS is vooral nuttig voor je maatwerkcode: eigen modules, een Laravel-backend of koppelingen.

Kan ik ASVS-certificering krijgen?

Er is geen officiële ASVS-certificering. Je kunt wel een onafhankelijke toets laten uitvoeren en laten vastleggen aan welk niveau en welke versie de applicatie voldoet.

Hoe neem ik ASVS op in een offerte of opdracht?

Noem het niveau, de versie, de scope per onderdeel en de wijze van verificatie (code review, geautomatiseerde tests, pentest). Voeg een lijst toe van eisen die niet van toepassing zijn, met de reden.

Laat je een maatwerk webshop of portal bouwen en wil je security-eisen vastleggen die je bij oplevering kunt toetsen? Bekijk onze Laravel-maatwerk en neem contact op via /contact.