Beveiliging webapplicatie: waar moet je op letten?

Bij de beveiliging van een webapplicatie denken veel mensen aan hackers die zich via slimme trucs toegang verschaffen. In de praktijk gaat het meestal om iets minder spannends: een vergeten update, een rechtencontrole die alleen in de browser zat, of een back-up die nooit is getest. Het goede nieuws is dat je met een aantal duidelijke maatregelen de meeste risico’s sterk verkleint.

Dit artikel helpt je als opdrachtgever of eigenaar de juiste vragen te stellen. Je hoeft geen securityspecialist te zijn om te herkennen of er goed is nagedacht over web application security.

Waarom beveiliging van een webapplicatie ertoe doet

Een webapplicatie is per definitie bereikbaar via internet. Daarmee is ze ook bereikbaar voor geautomatiseerde tools die dag en nacht het web afzoeken naar zwakke punten. Je hoeft geen bekend bedrijf te zijn om doelwit te worden; een bekende kwetsbaarheid in een verouderde versie is genoeg.

De gevolgen van een beveiligingsincident zijn vaak groter dan alleen technische schade:

• Datalekken. Uitgelekte persoonlijke informatie van klanten of medewerkers. Onder de AVG moet je passende technische en organisatorische maatregelen nemen en een datalek in veel gevallen melden bij de Autoriteit Persoonsgegevens.
• Verlies van vertrouwen. Klanten die hun gegevens aan je toevertrouwen, verwachten dat je die beschermt.
• Stilstand. Als de applicatie het hart van je bedrijfsprocessen is, kost elke dag uitval direct omzet.
• Intellectuele eigendom. Berekeningsmodellen, prijsafspraken of bedrijfsgeheimen die in de applicatie zitten, wil je niet op straat.

Goede beveiliging is daarom van cruciaal belang. Niemand kan garanderen dat een applicatie nooit wordt gehackt, maar je kunt mogelijke risico’s wel flink verkleinen. Dat begint met een solide basis.

Beveiliging begint bij het ontwerp

De goedkoopste beveiligingsmaatregel is de maatregel die je al in het ontwerp meeneemt. Stel bij het begin van de ontwikkeling een paar vragen: welke gevoelige informatie slaat de applicatie op, wie zou daar misbruik van willen maken en via welke mogelijke aanvallen? Door mogelijke bedreigingen vroeg te identificeren, kun je maatregelen implementeren voordat er code ligt.

Denk aan keuzes als: welke rollen zijn er en wat mag elke rol, welke gegevens hoeven we helemaal niet op te slaan, welke onderdelen moeten bereikbaar zijn vanaf internet en welke alleen intern? Ook de infrastructuur hoort erbij: waar draait de applicatie, wie heeft toegang tot de servers en hoe zijn die afgeschermd?

De OWASP Top 10: de bekendste risico’s op een rij

OWASP (Open Worldwide Application Security Project) publiceert de OWASP Top 10, een veelgebruikte lijst van veelvoorkomende kwetsbaarheden en de belangrijkste beveiligingsrisico’s voor webapplicaties. Per oktober 2026 is de meest recente editie de OWASP Top 10:2025, met deze categorieën:

1. Broken Access Control: gebruikers kunnen gegevens of functies bereiken die niet voor hen bedoeld zijn.
2. Security Misconfiguration: onveilige beveiligingsinstellingen, open beheerpanelen of te uitgebreide foutmeldingen.
3. Software Supply Chain Failures: risico’s in de libraries, packages en tools waarop je applicatie draait.
4. Cryptographic Failures: gevoelige gegevens die niet of zwak versleuteld zijn.
5. Injection: kwaadaardige invoer die als opdracht wordt uitgevoerd, zoals SQL-injectie en cross-site scripting.
6. Insecure Design: fouten in het ontwerp zelf, die je met nette code niet meer oplost.
7. Authentication Failures: zwakke inlogprocessen, slecht sessiebeheer of ontbrekende bescherming tegen raden van wachtwoorden.
8. Software or Data Integrity Failures: updates, data of code waarvan niet wordt gecontroleerd of ze te vertrouwen zijn.
9. Security Logging and Alerting Failures: aanvallen die niet worden gezien omdat er niets wordt gelogd of niemand een melding krijgt.
10. Mishandling of Exceptional Conditions: de applicatie gaat onveilig om met fouten en onverwachte situaties.

Je hoeft deze lijst niet uit je hoofd te kennen. Wel is het een goede vraag aan je ontwikkelaar: hoe gaan jullie om met de OWASP Top 10? Een overtuigend antwoord gaat over concrete werkwijzen, niet over beloftes.

In Nederland publiceert ook het NCSC ICT-beveiligingsrichtlijnen voor webapplicaties, die handig zijn als je eisen wilt vastleggen in een aanbesteding of contract.

Toegang en authenticatie goed regelen

Fouten in toegang staan niet voor niets bovenaan de lijst. Ze zijn veelvoorkomend en de gevolgen zijn direct: iemand ziet of wijzigt gegevens die niet van hem zijn. Het doel is ongeoorloofde toegang voorkomen, ook door gebruikers die wel mogen inloggen.

Sterke wachtwoorden en multi-factor authentication

Sterke authenticatie begint bij een goed wachtwoordbeleid: voldoende lengte, controle op bekende uitgelekte wachtwoorden en wachtwoorden die met een modern hash-algoritme worden opgeslagen, nooit leesbaar. Bescherm het inlogformulier tegen massaal raden, bijvoorbeeld door herhaalde pogingen te vertragen.

Multi-factor authentication (MFA, ook wel tweestapsverificatie) voegt een tweede stap toe, zoals een code uit een authenticator-app. Voor beheerders en gebruikers met toegang tot gevoelige gegevens is dat in onze ogen geen luxe maar standaard. Koppel waar mogelijk aan het bestaande account van je organisatie (single sign-on), zodat je medewerkers niet nog een wachtwoord hoeven te onthouden.

Rollen en rechten op de server

Elke actie in de applicatie moet aan de server side worden gecontroleerd: mag deze gebruiker dit record zien, deze order wijzigen, dit rapport downloaden? Een knop verbergen in de interface is geen beveiliging. Een klassiek voorbeeld: een klant die in de adresbalk het ordernummer verandert en daarmee de factuur van een andere klant ziet. Dat voorkom je alleen met consequente rechtencontroles in de backend.

Injectie en cross-site scripting voorkomen

Bij injectie stuurt een aanvaller invoer die de applicatie per ongeluk als opdracht uitvoert. Bij SQL-injectie is dat een databasequery, bij cross-site scripting (XSS) is dat JavaScript dat in de browser van andere gebruikers wordt uitgevoerd. OWASP rekent beide tot de categorie Injection.

De belangrijkste beste praktijken:

• Scheid data van opdrachten. Gebruik geparametriseerde queries of een ORM, zodat invoer nooit als SQL wordt geïnterpreteerd.
• Escape uitvoer standaard. Moderne template-engines doen dat automatisch; uitzonderingen moeten bewust en zeldzaam zijn.
• Valideer invoer aan de serverkant. Controleer of een veld echt een datum, getal of e-mailadres bevat.
• Gebruik een Content Security Policy. Die beperkt welke scripts een pagina mag laden en verkleint de schade als er toch iets doorheen glipt.

Frameworks als Symfony en Laravel bieden hier goede standaarden voor; veel veilige codeerpraktijken zitten er al in ingebakken. De meeste problemen ontstaan wanneer ontwikkelaars die standaarden omzeilen. Code reviews helpen om dat vroeg te zien.

Gegevens veilig opslaan en versturen

Versleuteling zorgt ervoor dat gegevens in een onleesbaar formaat staan voor iedereen zonder de juiste sleutel. Je hebt het op twee plekken nodig:

• Onderweg. Alle verkeer gaat via HTTPS met TLS, de opvolger van Secure Sockets Layer (SSL). Ook interne koppelingen tussen systemen horen versleuteld te zijn.
• In opslag. Databases, back-ups en geüploade bestanden met gevoelige gegevens worden versleuteld opgeslagen. Voor extra gevoelige velden, zoals BSN-nummers of medische gegevens, kun je versleuteling op veldniveau overwegen.

Minstens zo belangrijk voor gegevensbescherming: sla niet meer op dan nodig. Gegevens die je niet hebt, kunnen ook niet uitlekken. En houd geheimen zoals API-sleutels en wachtwoorden van databases uit de code; die horen in een afgeschermde configuratie of een kluis.

Updates en afhankelijkheden bijhouden

Een moderne webapplicatie bestaat voor een groot deel uit code van anderen: het framework, libraries, packages voor PDF’s of betalingen. Als in een van die onderdelen een kwetsbaarheid wordt gevonden, is jouw applicatie ook kwetsbaar. Dat is waarom de OWASP Top 10:2025 een aparte categorie heeft voor de software supply chain.

Concreet betekent dat:

• regelmatig updaten van het framework en de packages, niet alleen als er iets misgaat;
• geautomatiseerde tools die waarschuwen bij bekende kwetsbaarheden in je afhankelijkheden;
• op tijd overstappen naar ondersteunde versies van PHP en je framework, zodat je beveiligingspatches blijft ontvangen.

Bij applicaties die we overnemen, zien we hier regelmatig achterstand. Dat is begrijpelijk, maar het is ook het eerste wat je wilt oplossen. Wat onderhoud inhoudt en wat de kosten bepaalt, lees je in kosten van onderhoud van een webapplicatie.

Testen: van geautomatiseerde tests tot pentest

Je kunt een webapplicatie niet veilig verklaren zonder te testen. Verschillende soorten tests vullen elkaar aan.

Geautomatiseerde tests en code review

Geautomatiseerde tests controleren bij elke wijziging of rechten nog kloppen: kan gebruiker A echt niet bij de gegevens van gebruiker B? Statische analyse spoort potentiële kwetsbaarheden in de code op. En een code review door een tweede ontwikkelaar vangt menselijke fouten die tools missen. Zo ontdek je problemen in een vroeg stadium, wanneer ze het goedkoopst zijn om op te lossen.

Dynamic application security testing (DAST)

Bij dynamic application security testing wordt de draaiende applicatie van buitenaf aangevallen door een scanner, op dezelfde manier als een aanvaller dat zou doen. Dat vindt problemen in configuratie en gedrag die in de code niet zichtbaar zijn, zoals ontbrekende security headers of onveilige cookies.

Pentest

Bij een penetratietest probeert een specialist handmatig in te breken. Dat is vooral waardevol voor applicaties met gevoelige gegevens of veel gebruikers, en vóór een belangrijke livegang. Een pentest is een momentopname; zonder doorlopend onderhoud veroudert de uitkomst snel.

Extra beveiligingslaag: web application firewall en monitoring

Een web application firewall (WAF) zit tussen internet en je applicatie en blokkeert bekende aanvalspatronen, zoals veelvoorkomende injectiepogingen of massale inlogpogingen. Dat is een nuttige extra beveiligingslaag, zeker voor bereikbare inlogpagina’s en API’s. Je kunt er ook eigen beveiligingsregels in toepassen, bijvoorbeeld om het beheergedeelte alleen vanaf bepaalde netwerken bereikbaar te maken. Een WAF vervangt veilige code niet; hij vangt het grove werk af.

Daarnaast wil je weten wat er gebeurt. Goede logging en monitoring laten verdachte activiteiten zien, zoals plotseling veel mislukte inlogpogingen of een gebruiker die ineens duizenden records downloadt. Spreek ook af wie een melding krijgt en wat die persoon dan doet. Logging zonder opvolging helpt je alleen achteraf.

Back-ups en een plan voor als het misgaat

Ook met goede beveiligingsmaatregelen kan er iets misgaan: een aanval, een menselijke fout of een storing bij de hostingpartij. Dan wil je snel terug kunnen. Een getest herstelplan is daarom essentieel.

• Maak automatische back-ups van database én bestanden, op een andere locatie dan de applicatie zelf.
• Test het terugzetten. Een back-up die je nooit hebt teruggezet, is een hoop, geen plan.
• Leg vast wie wat doet bij een beveiligingsincident: wie beslist, wie communiceert met klanten, wie meldt bij de toezichthouder.

Checklist: beste praktijken voor een veilige webapplicatie

Gebruik deze lijst als startpunt voor het gesprek met je ontwikkelaar:

• Rechten worden voor elke actie op de server gecontroleerd.
• Inloggen met sterke wachtwoorden en MFA voor beheerders.
• Invoer wordt gevalideerd, uitvoer wordt standaard ge-escaped, queries zijn geparametriseerd.
• Alle verkeer gaat via HTTPS; gevoelige data is versleuteld opgeslagen.
• Framework, PHP-versie en packages worden actief bijgehouden.
• Er draaien geautomatiseerde tests en code reviews op elke wijziging.
• Logging en monitoring signaleren verdachte activiteiten, en iemand reageert erop.
• Back-ups worden automatisch gemaakt en het terugzetten is getest.
• Beveiliging is meegenomen in het ontwerp, niet alleen in de code. Zie ook ons artikel over webapplicatie architectuur.

Twijfel je hoe jouw bestaande applicatie ervoor staat? Met een codebase scan brengen we zwakke punten, verouderde onderdelen en risico’s in kaart.

Een veilige maatwerk webapplicatie laten bouwen

Veilige applicaties ontstaan niet door één maatregel, maar door een manier van werken: veilig ontwikkelen, testen en daarna blijven onderhouden. Zo bouwen we bij Inesta elke maatwerk webapplicatie: met beveiliging in het ontwerp, code reviews, actuele afhankelijkheden en een NDA als standaard. Wil je bespreken wat jouw applicatie nodig heeft? Je krijgt binnen één werkdag reactie.