Een beveiligingschecklist voor een web applicatie is een vaste lijst controles die een developer vóór de lancering en na elke grote release afloopt. In 2026 is de OWASP Top 10:2025 de beste basis, met broken access control op nummer 1. Volgens OWASP had 100% van de geteste applicaties een vorm van broken access control. Een complete checklist dekt vijf lagen. Stap 1 is toegangscontrole per API-route op de server, met standaard weigeren. Stap 2 is authenticatie, met MFA via Google Authenticator of een vergelijkbare app en veilige sessiecookies. Stap 3 is configuratie, met HTTPS en security headers. Stap 4 is het bewaken van third-party code, want in 2025 zat 91% van de nieuwe WordPress-kwetsbaarheden in plugins (Patchstack 2026). Stap 5 is logging, zodat je een datalek binnen de 72-uurstermijn van de AVG kunt melden. Een klantportaal voor 200 klanten, gebouwd met Next.js en PostgreSQL, heeft bijvoorbeeld alle vijf lagen nodig.
Wat is een beveiligingschecklist voor een web applicatie?
Een beveiligingschecklist voor een web applicatie is een praktische lijst controles waar elke release van een web app doorheen moet. De lijst maakt abstract risico concreet, met een ja-of-nee-vraag per API-route: controleert de server de rol van de gebruiker? De OWASP Top 10:2025 is in 2026 de beste basis voor zo'n lijst, met data over ruim 2,8 miljoen applicaties. Een checklist is vooral belangrijk voor het mkb. Volgens het CBS nam in 2025 86% van de grote bedrijven minstens tien van de twaalf onderzochte beveiligingsmaatregelen, tegen 13% van de bedrijven met 2 tot 10 werknemers. Eén gelekte klantentabel kan leiden tot een datalekmelding, verloren vertrouwen en een dure herbouw. De checklist hieronder past op elke moderne stack, bijvoorbeeld een klantportaal voor 500 gebruikers met inloggen via Google of Microsoft, gebouwd met Next.js en PostgreSQL. Het artikel volgt drie stappen: 1) de risico's uit de OWASP-lijst, 2) concrete controles per laag en 3) wat de AVG verwacht na een datalek.
Wat is er veranderd in de OWASP Top 10:2025?
De OWASP Top 10:2025 is de ranglijst van de tien grootste beveiligingsrisico's voor web applicaties, gepubliceerd door de OWASP Foundation. Broken access control blijft nummer 1, en server-side request forgery (SSRF) valt nu onder dezelfde categorie. In de data van 2025 had volgens OWASP 100% van de geteste applicaties een vorm van broken access control. Security misconfiguration steeg van plaats 5 naar plaats 2, denk aan een publiek leesbare opslagbucket in Google Cloud of Microsoft Azure. Twee categorieën zijn nieuw: Software Supply Chain Failures en Mishandling of Exceptional Conditions. In de enquête onder vakgenoten zette precies 50% van de respondenten supply chain op nummer 1. De les voor een ondernemer is eenvoudig. De meeste inbraken beginnen met gewone fouten: te ruime rechten, een vergeten instelling of een besmet pakket dat via GitHub of npm binnenkomt. Exotische aanvallen zijn zeldzaam. De tabel hieronder geeft per OWASP-categorie een concrete controle, bijvoorbeeld voor een web app op Next.js.
Hoe beveilig je toegangscontrole en authenticatie?
Toegangscontrole is het geheel aan regels op de server dat bepaalt wat elke gebruiker mag zien en wijzigen. Het kernprincipe volgens OWASP is: weiger standaard alles, behalve publieke onderdelen. OWASP koppelt 40 bekende zwakheden aan deze categorie en telde ruim 1,8 miljoen gevallen in de data van 2025. De controle moet in vertrouwde servercode draaien, want een verborgen knop in de browser houdt niemand tegen. Elke query moet ook het eigenaarschap van records afdwingen. Zo kan klant A nooit een factuur van klant B openen door een ID in de URL te veranderen. Authenticatie is stap 2 van de checklist. De Autoriteit Persoonsgegevens omschrijft MFA als een combinatie van minimaal 2 typen factoren, bijvoorbeeld een wachtwoord plus een code via Google Authenticator of Microsoft Authenticator. Volgens het CBS gebruikte in 2025 97% van de grote bedrijven MFA, tegen 56% van de bedrijven met 2 tot 10 werknemers. Beperk daarnaast het aantal inlogpogingen per IP-adres en per account. Bewaar sessies in cookies met Secure, HttpOnly en SameSite.
Welke instellingen en HTTP-headers moet je controleren?
Security misconfiguration betekent dat een applicatie draait met onveilige standaardinstellingen, open opslag of ontbrekende beveiliging, ook als de code zelf in orde is. In de data van 2025 had volgens OWASP 100% van de geteste applicaties een vorm van misconfiguratie. De categorie steeg van plaats 5 naar plaats 2. Ten eerste: lever elke pagina via HTTPS en voeg een HSTS-header toe, zodat browsers als Google Chrome nooit terugvallen op onversleuteld HTTP. Ten tweede: stel een Content-Security-Policy in, die bepaalt waarvandaan scripts mogen laden en cross-site scripting afremt. Ten derde: voeg X-Content-Type-Options, een Referrer-Policy en frame-ancestors toe tegen clickjacking. Volgens de Web Almanac stuurt maar 36% van de mobiele pagina's een HSTS-header, en gebruikt 21,9% een Content-Security-Policy. In Next.js stel je de headers per URL-patroon in, in één configuratiebestand. Controleer het resultaat na elke deploy via Mozilla Observatory, want een hostingwijziging kan ongemerkt een header weghalen.
Hoe bescherm je dependencies, invoer en foutafhandeling?
Een software supply chain failure is een compromittering van de pakketten, buildtools of distributiekanalen waar een applicatie op leunt. OWASP voegde de categorie in 2025 toe, en precies 50% van de respondenten in de enquête zette dit risico op nummer 1. De npm-worm Shai-Hulud bereikte dat jaar volgens OWASP meer dan 500 pakketversies. Ook bij WordPress zit het risico in code van derden: 91% van de nieuwe kwetsbaarheden zat in plugins (Patchstack 2026). De verdediging heeft drie onderdelen: 1) een gecommitte lockfile, 2) een software bill of materials (SBOM) en 3) automatische meldingen via Dependabot of Renovate. Injection is het volgende risico. Bouw nooit SQL door strings aan elkaar te plakken, maar gebruik geparametriseerde queries via de databasedriver of een ORM zoals Prisma. Valideer elke invoer per API-route op de server met een schema, bijvoorbeeld met Zod. Tot slot gaat de nieuwe categorie Mishandling of Exceptional Conditions over code die bij een fout openvalt. Een gecrashte rechtencontrole moet het verzoek blokkeren, zonder stacktrace voor de gebruiker.
Wat eist de AVG als er een datalek is?
De AVG verplicht de verwerkingsverantwoordelijke om een datalek binnen 72 uur na kennisname te melden. De enige uitzondering is een lek waarbij een risico voor de betrokkenen onwaarschijnlijk is. Kennisname betekent hier: redelijk zeker weten dat een beveiligingsincident persoonsgegevens heeft geraakt. In Nederland gaat de melding via een online formulier naar de Autoriteit Persoonsgegevens (AP). Ook bij ransomware moet volgens de AP de eerste, voorlopige melding binnen 72 uur binnen zijn, en weekend of ziekte gelden niet als reden voor een late melding. Toezichthouder BfDI (Duitsland) waarschuwt voor boetes tot 10 miljoen euro of 2% van de wereldwijde jaaromzet bij overtreding van de meldplicht. Snel melden vraagt om goede logging, en OWASP zet logging- en alertfouten op A09:2025. Toch hield volgens het CBS in 2025 maar 26% van de bedrijven met 2 tot 10 werknemers logbestanden bij, tegen 92% van de grote bedrijven. Log daarom inlogpogingen, rechtenfouten en data-exports, zonder persoonsgegevens in de logs. Stuur alerts via Slack of Microsoft Teams naar iemand die echt reageert.
Veelgestelde vragen
Hoe vaak moet je de beveiliging van een web applicatie controleren?
Een beveiligingscontrole is een terugkerende review, geen eenmalige taak vóór de lancering. Een verstandig ritme in 2026 bestaat uit drie lagen. Ten eerste draaien automatische meldingen continu, via Dependabot voor dependencies en Google Search Console voor gehackte pagina's. Ten tweede loop je de volledige checklist af vóór elke grote release, zoals een nieuwe gebruikersrol, betaalstroom of API-koppeling. Ten derde volgt minstens één keer per jaar een diepere review of externe pentest voor applicaties met persoonsgegevens of financiële data. Volgens het CBS liet in 2025 maar 20% van de bedrijven met 2 tot 10 werknemers de eigen ICT-veiligheid beoordelen, tegen 89% van de grote bedrijven. Ook kleine web apps op Next.js of WordPress hebben maandelijks updates nodig. Patchstack telde 11.334 nieuwe WordPress-kwetsbaarheden in 2025. Bovendien kreeg 46% daarvan geen oplossing vóór de openbare bekendmaking (Patchstack 2026). Leg het werk vast in een onderhoudsafspraak, zodat er na de lancering altijd iemand verantwoordelijk is.
Is HTTPS genoeg om een web applicatie te beveiligen?
HTTPS is noodzakelijk, maar dekt maar één laag van de beveiliging van een web applicatie. HTTPS versleutelt het verkeer tussen browser en server en beschermt zo wachtwoorden en persoonsgegevens tegen afluisteren op openbare wifi. Volgens de Web Almanac draaide in 2025 al 97,3% van de mobiele homepages op HTTPS. Toch doet HTTPS niets tegen broken access control, het grootste risico in de OWASP Top 10:2025. Een aanvaller met een geldig account kan via een versleutelde verbinding nog steeds de gegevens van een andere klant opvragen. Volgens OWASP had 100% van de geteste applicaties een vorm van broken access control. HTTPS beschermt ook niet tegen injection, kwetsbare npm-pakketten of zwakke wachtwoorden. Zie het slotje dus als het eerste punt op de checklist, niet als het laatste. Voeg daarna per API-route rechtencontroles toe, plus MFA via Google Authenticator, security headers, dependency-monitoring en logging. Een Next.js-app krijgt bij hosting via Vercel of Netlify standaard HTTPS, maar alle andere controles blijven nodig.
Wie is verantwoordelijk voor beveiliging als je development uitbesteedt?
De opdrachtgever blijft onder de AVG verantwoordelijk voor beveiliging, want de eigenaar van de applicatie en de persoonsgegevens blijft verwerkingsverantwoordelijke. Stap 1 is de rollen bepalen. Host of onderhoudt het bureau de applicatie met toegang tot persoonsgegevens, dan kan het bureau verwerker zijn. Verantwoordelijke en verwerker sluiten dan een verwerkersovereenkomst, zoals de AVG voorschrijft in artikel 28. Overtreding van die verplichtingen kan een boete opleveren tot 10 miljoen euro of 2% van de wereldwijde jaaromzet. Stap 2 is concrete maatregelen vastleggen, bijvoorbeeld MFA via Microsoft Authenticator voor beheeraccounts, versleutelde back-ups en een reactietijd bij incidenten. Stap 3 is vóór de lancering per OWASP-categorie nalopen of de applicatie voldoet. In de data van 2025 had volgens OWASP namelijk 100% van de geteste applicaties een vorm van broken access control. VirtuoLab werkt met een vaste prijs vooraf en direct contact met de developer die de applicatie bouwt. Tot slot ben je na oplevering eigenaar van de broncode en de data, waardoor een onafhankelijke audit altijd mogelijk blijft.