Twintig kwetsbaarheden zeggen meer dan alleen een getal
Webapplicaties zijn allang niet meer alleen publieke websites waarop bezoekers informatie lezen. Ze geven toegang tot webshops, klantaccounts, selfserviceomgevingen, API's en andere interactieve diensten die gekoppeld kunnen zijn aan bedrijfsprocessen en gevoelige informatie. Een kwetsbaarheid in zo'n omgeving kan daardoor gevolgen hebben die verder reiken dan alleen de webpagina waarop de fout zich bevindt.
Dat maakt het gemiddelde van twintig gevonden kwetsbaarheden per applicatie relevant. Het getal betekent niet dat iedere onderzochte webapplicatie twintig direct misbruikbare, kritieke beveiligingslekken bevat. De ernst en praktische misbruikbaarheid kunnen per bevinding verschillen. Het risico zit juist ook in het aantal mogelijke aanknopingspunten dat een aanvaller krijgt.
Dat het misbruik van softwarekwetsbaarheden een steeds belangrijkere ingang vormt, blijkt ook uit de Verizon Data Breach Investigations Report 2026. Daarin begon 31 procent van de onderzochte breaches met het uitbuiten van softwarekwetsbaarheden, waarmee deze aanvalsmethode in Verizons dataset gestolen inloggegevens als belangrijkste initiële toegangsmethode passeerde.
Een aanvaller hoeft namelijk niet altijd één ernstig beveiligingslek te vinden dat direct volledige toegang geeft. Verschillende kleinere problemen kunnen achter elkaar worden gebruikt. Een informatielek kan bijvoorbeeld eerst iets vertellen over de technische omgeving. Die kennis kan vervolgens helpen om een verborgen endpoint of interessante beheerfunctie te vinden, waarna een andere fout nodig is om een volgende stap te zetten.
Het aanvalsoppervlak van een applicatie wordt daarmee niet alleen bepaald door de zwaarste individuele kwetsbaarheid, maar ook door de combinatie van zwakke plekken die aanwezig is. Volgens Barracuda kunnen aanvallers zulke mogelijkheden onderzoeken, testen en combineren om gevoelige informatie te verzamelen, inloggegevens te bemachtigen of ongeoorloofde toegang te verkrijgen.
Zeven typen fouten vormen ongeveer 90 procent van de kwetsbaarheden
Voor het onderzoek analyseerden onderzoekers gedurende vijf maanden in 2026 honderden scans die waren uitgevoerd met Barracuda Application Security Insight. Daaruit kwamen zeven typen beveiligingsproblemen naar voren die samen ongeveer 90 procent van alle gedetecteerde kwetsbaarheden vertegenwoordigden.
De resultaten moeten daarbij in hun context worden gelezen. Het gaat om bevindingen uit honderden scans die met Barracuda Application Security Insight zijn geanalyseerd en niet om een universele inventarisatie van alle webapplicaties wereldwijd. De percentages laten wel zien welke soorten fouten binnen de onderzochte applicaties relatief vaak werden aangetroffen.
Opvallend is bovendien dat de grootste categorieën niet bestaan uit één spectaculaire technische kwetsbaarheid. Het gaat juist vaak om fouten waarbij applicaties te veel informatie prijsgeven, onvoldoende bescherming bieden tegen misbruik van identiteit of data onnodig toegankelijk maken.
Dat configuratiefouten breder als belangrijk applicatierisico worden gezien, blijkt ook uit de OWASP Top 10:2025. Security Misconfiguration steeg daarin van de vijfde plaats in 2021 naar de tweede plaats in 2025. Software Supply Chain Failures staat op de derde plaats. Daarmee staan niet alleen fouten in eigen applicatiecode centraal, maar nadrukkelijk ook configuraties, externe componenten en afhankelijkheden waarvan moderne software gebruikmaakt. Voor de beveiliging van webapplicaties betekent dit dat ook configuraties en externe afhankelijkheden structureel in beveiligingscontroles moeten worden meegenomen.
Informatielekken geven aanvallers een kaart van de omgeving
Met 25 procent vormen informatielekken de grootste categorie binnen de gedetecteerde beveiligingsfouten. Bij zo'n lek geeft een applicatie meer informatie over zichzelf of de achterliggende omgeving prijs dan noodzakelijk is. Dat kan betrekking hebben op systemen en domeinen, maar ook op verborgen pagina's, routes, diensten of endpoints.
Die informatie hoeft op zichzelf geen directe toegang tot een systeem te geven om waardevol te zijn. Voor een aanvaller kan ze onderdeel worden van de verkenningsfase van een aanval. Hoe meer informatie beschikbaar is over de opbouw van een applicatie en de diensten eromheen, hoe gerichter kan worden gezocht naar zwakke plekken.
Een applicatie die bijvoorbeeld verwijzingen naar verborgen endpoints of beheeronderdelen prijsgeeft, vertelt een aanvaller waar verder onderzoek interessant kan zijn. Hetzelfde geldt voor technische details die meer inzicht geven in de inrichting van de omgeving. De kwetsbaarheid zit dan niet alleen in de afzonderlijke informatie die wordt blootgelegd, maar ook in de mogelijkheid om daarmee een steeds completer beeld van het doelwit op te bouwen.
Dat maakt information disclosure een goed voorbeeld van een beveiligingsprobleem dat afzonderlijk misschien niet altijd als kritiek wordt beoordeeld, maar wel een belangrijke bouwsteen kan worden voor een grotere aanval.
Merkvervalsing en spoofing misbruiken het vertrouwen van gebruikers
Bijna even groot is de categorie merkvervalsing en spoofing, die volgens het onderzoek 24 procent van de gevonden securityfouten vertegenwoordigt. Hierbij gaat het om zwakke plekken die het makkelijker kunnen maken om zich voor te doen als een vertrouwd merk, domein of een bestaande website.
Het doelwit is daarbij niet noodzakelijk alleen de technische infrastructuur van de organisatie. Ook het vertrouwen dat gebruikers in een website of merk hebben, kan worden misbruikt. Wanneer een aanvaller een geloofwaardige kopie van een webpagina kan maken of gebruikers naar een schadelijke omgeving kan leiden, wordt de herkenbaarheid van het legitieme merk onderdeel van de aanval.
Barracuda noemt onder meer het klonen van webpagina's, het omleiden van gebruikers naar kwaadaardige websites en het verzamelen van inloggegevens als mogelijke gevolgen. Ook kan een nagebootste identiteit worden gebruikt om phishingberichten overtuigender te maken. Een e-mail of website die sterk lijkt op een bekende organisatie heeft immers een grotere kans om door een gebruiker als betrouwbaar te worden beschouwd.
De beveiliging van webapplicaties raakt daarmee niet alleen de applicatiecode zelf. Ook identiteit, domeinen en de manier waarop gebruikers kunnen controleren dat zij werkelijk met de bedoelde organisatie communiceren, spelen een rol in het verkleinen van het aanvalsoppervlak.
Client-side kwetsbaarheden verplaatsen de aanval naar de browser
Client-side aanvallen zijn volgens de scans goed voor 14 procent van de gevonden kwetsbaarheden. Hierbij zit het probleem in de manier waarop een webpagina content verwerkt, weergeeft of uitvoert in de browser van de gebruiker.
Een bekend voorbeeld is Cross-Site Scripting, meestal afgekort tot XSS. Daarbij slaagt een aanvaller erin ongewenste code of scripts binnen de context van een webpagina te laten uitvoeren. Omdat die code in de browser van de gebruiker draait, kan de aanval plaatsvinden binnen een omgeving die voor die gebruiker op het eerste gezicht legitiem lijkt.
Dat kan verschillende gevolgen hebben. Een aanvaller kan proberen sessiecookies te bemachtigen, weergegeven content te veranderen of gebruikers tot een bepaalde actie te verleiden. Barracuda noemt daarnaast scenario's waarbij gebruikers worden misleid om op verborgen knoppen te klikken of waarbij misleidende bestanden via de applicatie worden geüpload.
Het lastige aan client-side kwetsbaarheden is daarmee dat een deel van de aanval zich niet diep in een achterliggend systeem hoeft af te spelen. De browser wordt zelf een onderdeel van het aanvalspad. Goede serverbeveiliging alleen is daarom niet voldoende wanneer een applicatie onbetrouwbare invoer op een onveilige manier naar de browser doorstuurt of laat uitvoeren.
Het hardnekkige karakter van XSS betekent niet dat dit type kwetsbaarheid onvermijdelijk is. CISA en de FBI beschouwen XSS juist als een voorkombare kwetsbaarheidsklasse. Ze adviseren onder meer moderne webframeworks met functies voor veilige output encoding, goede invoervalidatie, code reviews en grondige securitytests gedurende de ontwikkelingscyclus. Daarmee verschuift de aanpak van het achteraf blokkeren van afzonderlijke aanvallen naar het structureel voorkomen dat zulke fouten in applicaties terechtkomen.
Blootgestelde data levert aanvallers direct bruikbare informatie op
Een andere categorie is de onnodige blootstelling van gevoelige gegevens. Deze vorm van data exposure vertegenwoordigt 10 procent van de gedetecteerde beveiligingsfouten.
Het verschil met een algemeen informatielek zit vooral in het soort informatie dat beschikbaar komt. Bij data exposure gaat het nadrukkelijk om gevoelige gegevens die via de applicatie toegankelijk of zichtbaar worden terwijl dat niet noodzakelijk is.
Dat kan op verschillende plaatsen gebeuren. Webpagina's en API's liggen voor de hand, maar ook logbestanden, cookies, trackingscripts en verkeerd geconfigureerde responses kunnen gegevens prijsgeven. Daardoor kan gevoelige informatie op meer plekken terechtkomen dan alleen in de database waarin ze oorspronkelijk is opgeslagen.
Volgens Barracuda kunnen aanvallers op die manier onder meer persoonsgegevens, tokens, privécontent, geheimen, e-mailadressen en configuratie-instellingen verzamelen. Sommige van die gegevens zijn direct waardevol. Andere informatie kan opnieuw dienen als hulpmiddel voor een vervolgstap in een aanval.
Daarbij speelt ook privacy een rol. Verkeerd ingestelde tracking of onnodige blootstelling van gegevens kan ertoe leiden dat gebruikers zonder hun toestemming worden gevolgd. Volgens Barracuda kunnen aanvallers dergelijke zwakke plekken bovendien misbruiken om toegangsbeheersmaatregelen en beleidsregels rond gegevensbewaring te manipuleren. Daarmee raakt data exposure niet alleen de vertrouwelijkheid van gegevens, maar ook de controle over wie toegang heeft tot die informatie en hoe lang deze beschikbaar blijft. Ook dataminimalisatie speelt daarmee een belangrijke rol bij de beveiliging van webapplicaties.
De beveiliging van webapplicaties draait daardoor niet alleen om het voorkomen dat een aanvaller het systeem binnendringt. Organisaties moeten ook kritisch kijken naar welke gegevens een applicatie überhaupt beschikbaar stelt, aan wie en onder welke omstandigheden.
Encryptie, softwarebeheer en sessies blijven basishygiëne
De resterende drie grote categorieën vertegenwoordigen afzonderlijk een kleiner deel van de bevindingen, maar raken stuk voor stuk fundamentele onderdelen van applicatiebeveiliging.
Zwakke of ontbrekende versleuteling is goed voor 6 procent van de gevonden kwetsbaarheden. Wanneer verkeer of gevoelige gegevens niet voldoende zijn beschermd, kan het risico ontstaan dat informatie wordt onderschept of gemanipuleerd. Alleen de aanwezigheid van encryptie is daarbij niet genoeg: de bescherming moet correct zijn geïmplementeerd en geconfigureerd op de plaatsen waar gevoelige gegevens worden verzonden of verwerkt.
Dependencies vergroten het software-supply-chainrisico
Nog eens 6 procent bestaat uit verouderde software en onveilige configuraties. Dat raakt niet alleen de zelfontwikkelde applicatiecode. Moderne webapplicaties zijn doorgaans afhankelijk van frameworks, libraries, modules en andere componenten. Zodra bekende beveiligingsproblemen in zulke onderdelen beschikbaar zijn maar updates uitblijven, kunnen kwetsbaarheden blijven bestaan die in nieuwere versies al zijn verholpen.
Het dependency-risico wordt inmiddels breder bekeken dan alleen het controleren op een verouderde library. OWASP heeft de voormalige categorie Vulnerable and Outdated Components in de Top 10:2025 uitgebreid naar Software Supply Chain Failures. Daaronder vallen ook risico's rond buildsystemen, distributieprocessen en indirecte of transitive dependencies. Daardoor moet een organisatie niet alleen weten welke componenten zij zelf aan een applicatie heeft toegevoegd, maar ook welke software via de onderliggende afhankelijkheidsketen wordt binnengehaald. Voor de beveiliging van webapplicaties is het daarom belangrijk om niet alleen directe dependencies, maar ook de achterliggende afhankelijkheidsketen in beeld te hebben.
Configuratiebeheer verdient daarbij afzonderlijke aandacht. Software kan technisch volledig bijgewerkt zijn en toch onveilig worden gebruikt wanneer beveiligingsinstellingen verkeerd staan, onnodige functies actief blijven of bepaalde onderdelen breder toegankelijk zijn dan bedoeld. Patchmanagement en configuratiebeheer vullen elkaar daarom aan.
Sessiebeveiliging stopt niet na het inloggen
De laatste categorie, goed voor 5 procent van de gevonden problemen, heeft betrekking op het beheer van gebruikerssessies en de bescherming van cookies en inloggegevens. Na een succesvolle login moet een applicatie immers gedurende een bepaalde periode kunnen herkennen welke gebruiker is aangemeld. Sessiecookies en tokens spelen daarbij vaak een belangrijke rol.
Wanneer zulke gegevens onvoldoende worden beschermd, kan een aanvaller proberen een bestaande sessie over te nemen of buitgemaakte authenticatiegegevens te misbruiken. Het risico houdt dus niet op zodra een gebruiker succesvol door het loginproces is gekomen. Ook de volledige levensduur van de sessie moet veilig worden beheerd.
Dat vraagt ook om concrete browsermaatregelen. OWASP adviseert sessiecookies onder meer te beschermen met eigenschappen als Secure, HttpOnly en SameSite, naast het gebruik van HTTPS en een goed ingerichte sessielevensduur. Secure zorgt ervoor dat een sessiecookie alleen over een versleutelde verbinding wordt verzonden, HttpOnly beperkt directe toegang vanuit scripts en SameSite helpt het meesturen van cookies bij ongewenste cross-site requests te beperken. Zulke maatregelen verkleinen daarmee verschillende mogelijkheden om een sessie-identifier te onderscheppen, uit te lezen of buiten de bedoelde context te misbruiken.
Juist deze drie categorieën laten zien dat basishygiëne in de beveiliging van webapplicaties relevant blijft. Encryptie, patchmanagement, configuratiebeheer en sessiebeveiliging zijn bekende onderwerpen, maar fouten op deze gebieden blijven in de praktijk voor risico zorgen.
Het werkelijke risico zit vaak in de combinatie van zwakke plekken
Twintig gevonden kwetsbaarheden per applicatie moeten daarom niet worden gelezen als twintig afzonderlijke kritieke exploits. De betekenis zit voor een belangrijk deel in de mogelijkheden om verschillende bevindingen met elkaar te combineren.
Barracuda wijst erop dat aanvallers meerdere kwetsbaarheden met een laag of gemiddeld risico kunnen samenbrengen om uiteindelijk gevoelige informatie, inloggegevens of toegang te verkrijgen. Dat principe maakt prioritering ingewikkelder dan alleen het oplossen van de kwetsbaarheden met het hoogste individuele risicolabel. Voor de beveiliging van webapplicaties is het daarom belangrijk om niet alleen naar afzonderlijke kwetsbaarheden te kijken, maar ook naar de aanvalsketens die door een combinatie van zwakke plekken kunnen ontstaan.
Een denkbaar aanvalspad kan bijvoorbeeld beginnen met een informatielek. Daardoor ontdekt een aanvaller informatie over de structuur van een applicatie of een verborgen endpoint. Vervolgens blijkt een onderdeel verouderd of verkeerd geconfigureerd te zijn. Een andere fout rond de browser, een sessie of blootgestelde gegevens kan daarna de volgende stap mogelijk maken.
Geen van die problemen hoeft afzonderlijk volledige controle over de applicatie op te leveren. Samen vormen ze echter een keten waarin de ene kwetsbaarheid de voorwaarden creëert voor het misbruiken van de volgende.
Dat betekent niet dat ieder informatielek automatisch uitmondt in een succesvolle aanval. Het onderstreept wel waarom organisaties ook laag- en middelrisicobevindingen niet onbeperkt kunnen laten liggen. Naarmate verschillende zwakke plekken naast elkaar blijven bestaan, krijgt een aanvaller meer mogelijkheden om alternatieve routes door de beveiliging te zoeken.
Kwetsbaarheden in webapplicaties vragen om continue beveiliging
Het terugdringen van die mogelijkheden begint bij regelmatig inzicht in de eigen applicaties. Barracuda adviseert organisaties daarom om niet alleen periodiek naar bekende kwetsbaarheden te zoeken, maar ook naar verkeerde securityconfiguraties.
Een eenmalige beveiligingsscan is daarbij onvoldoende. Webapplicaties veranderen voortdurend. Nieuwe functionaliteit wordt toegevoegd, dependencies krijgen updates, configuraties worden aangepast en API's kunnen worden uitgebreid. Een applicatie die bij de ene controle geen belangrijk probleem bevat, kan na een volgende release opnieuw een kwetsbaarheid introduceren. De beveiliging van webapplicaties moet daarom met die veranderingen meebewegen en niet alleen op vaste controlemomenten worden beoordeeld.
Daarnaast blijft snel patchen en updaten belangrijk. Barracuda adviseert organisaties om applicaties, frameworks en afhankelijkheden direct te patchen en bij te werken zodra dat nodig is. In de praktijk betekent dit dat patchmanagement niet alleen de zichtbare applicatie moet omvatten, maar ook de onderliggende componenten waarop de software steunt. Juist doordat moderne applicaties uit meerdere dependencies kunnen bestaan, kan een bekende kwetsbaarheid in één zo'n component onderdeel worden van het totale aanvalsoppervlak.
Een derde aandachtspunt is het beperken van onnodige informatieprijsgeving. Applicaties hoeven niet meer over hun interne werking prijs te geven dan noodzakelijk is. Foutmeldingen, technische metadata, routes en andere systeeminformatie moeten daarom worden bekeken vanuit de vraag of externe gebruikers deze informatie daadwerkelijk nodig hebben.
Hetzelfde principe geldt voor gevoelige gegevens. Organisaties moeten controleren welke data via webpagina's, API's, cookies, logs, trackingscripts en responses beschikbaar komt. Data die niet noodzakelijk toegankelijk hoeft te zijn, kan beter niet worden blootgesteld. Daarmee wordt niet alleen de kans op direct gegevensverlies kleiner, maar krijgt een aanvaller ook minder informatie waarmee een vervolgaanval kan worden voorbereid.
Encryptie, authenticatie en sessiebeveiliging vormen vervolgens afzonderlijke verdedigingslagen. Versleuteling beschermt gegevens en verbindingen, authenticatie bepaalt wie toegang krijgt en veilig sessiebeheer moet voorkomen dat die toegang na het inloggen kan worden overgenomen of misbruikt. Een zwakke plek in één laag hoeft niet meteen fataal te zijn wanneer de andere verdedigingslagen hun werk blijven doen.
Monitoring en secure development maken beveiliging continu
Daarom is ook monitoring noodzakelijk. Alleen controleren tijdens ontwikkeling of rond een nieuwe release geeft geen volledig beeld van wat er daarna met een applicatie gebeurt. Door webapplicaties continu te volgen op verdachte activiteiten en veranderende dreigingen kan sneller zichtbaar worden wanneer iemand bekende zwakke plekken probeert te verkennen of te misbruiken.
Daarbij is alleen logging niet genoeg. OWASP houdt Security Logging & Alerting Failures in de Top 10:2025 op de negende plaats en benadrukt specifiek het belang van alerting om actie op relevante logevents mogelijk te maken. Monitoring levert uiteindelijk pas beveiligingswaarde op wanneer verdachte gebeurtenissen niet alleen worden vastgelegd, maar ook worden herkend, onderzocht en waar nodig opgevolgd.
Daarmee verschuift applicatiebeveiliging van een reeks losse controles naar een proces dat tijdens de volledige ontwikkelingscyclus moet worden meegenomen. NIST beschrijft die aanpak in het Secure Software Development Framework (SSDF): securitypraktijken worden geïntegreerd in de software development lifecycle om het aantal kwetsbaarheden in uitgebrachte software te verkleinen, de gevolgen van nog onbekende of niet opgeloste kwetsbaarheden te beperken en onderliggende oorzaken aan te pakken zodat problemen minder snel terugkeren.
In de praktijk komt die aanpak neer op meerdere maatregelen die elkaar versterken:
scan regelmatig op kwetsbaarheden én verkeerde beveiligingsconfiguraties;
patch applicaties, frameworks en afhankelijkheden tijdig;
beperk technische informatie die onnodig naar buiten komt;
minimaliseer de blootstelling van gevoelige data;
versterk encryptie, authenticatie en sessiebeveiliging;
monitor webapplicaties continu op verdachte activiteiten en nieuwe dreigingen.
Die maatregelen vormen samen een gelaagde aanpak. Preventie moet het aantal kwetsbaarheden verkleinen, monitoring moet misbruik sneller zichtbaar maken en goed beheer moet ervoor zorgen dat gevonden problemen daadwerkelijk worden opgelost.
Simpele fouten zijn niet automatisch kleine risico's
De belangrijkste rode draad in de onderzoeksresultaten is uiteindelijk niet dat webapplicaties alleen worden bedreigd door uiterst complexe beveiligingslekken. Een aanzienlijk deel van de gevonden problemen heeft juist betrekking op fouten die in veel gevallen vermijdbaar zijn: te veel informatie prijsgeven, gevoelige data onnodig blootstellen, software niet tijdig bijwerken of beveiligingsinstellingen onvoldoende aanscherpen.
Dat maakt zulke fouten niet ongevaarlijk. Een afzonderlijk probleem kan beperkt lijken, terwijl het in combinatie met andere kwetsbaarheden precies de informatie of toegang oplevert die een aanvaller nodig heeft voor een volgende stap.
Kwetsbaarheden in webapplicaties vragen daarom om meer dan het incidenteel installeren van een patch. Applicatiebeveiliging moet onderdeel zijn van ontwikkeling, configuratiebeheer, onderhoud en monitoring gedurende de volledige levenscyclus van een applicatie. Juist door gewone fouten vroeg te vinden en structureel op te lossen, worden ook de aanvalsketens moeilijker die uit meerdere ogenschijnlijk kleine zwakke plekken bestaan.