Onderzoek: Security¶

Auteur: Nick van Hooff
Datum: 12-12-2025

Navigatie - Waar vind ik wat?¶

Belangrijk: Dit document bevat samenvattingen. Voor uitgebreide deelvragen, klik op de links in de tabel hieronder.

Onderdeel	Waar te vinden
Deelvraag 1 - OWASP Top 10 analyse	→ Klik hier voor Deelvraag 1
Deelvraag 2 - Static Analysis resultaten	→ Klik hier voor Deelvraag 2
Deelvraag 3 - ZAP Security Test	→ Klik hier voor Deelvraag 3
Deelvraag 3 - ZAP Report (HTML)	→ Klik hier voor ZAP Report HTML
Deelvraag 4 - Volgende stappen	Zie hieronder in dit document

Inleiding¶

Aanleiding en achtergrond¶

Dit document beschrijft de opzet van het beveiligingsonderzoek van de Factuur Beheer applicatie. De applicatie is een webgebaseerd systeem voor het beheren van facturen en maakt gebruik van Spring Boot voor de backend API en Nuxt 4 voor de frontend.

Context van de applicatie:

De applicatie verwerkt gevoelige financiële data (facturen, klantgegevens) - dit maakt beveiliging extra belangrijk
Momenteel bevat de applicatie nog geen login of andere authenticatie mechanismen - daarom is basisbeveiliging cruciaal
Alle endpoints zijn publiek toegankelijk zonder autorisatiecontroles - iedereen kan de API benaderen
De applicatie is in ontwikkeling en moet voorbereid worden op productiegebruik - dit onderzoek helpt om beveiligingsproblemen vroeg te vinden

Waarom dit onderzoek belangrijk is: Omdat de applicatie nog geen authenticatie bevat, is het cruciaal dat de basisbeveiliging van publieke endpoints en de frontend op orde is. Onveilige instellingen kunnen leiden tot:

Datalekken: Onbevoegde toegang tot gevoelige financiële informatie. Zonder juiste security headers en CORS configuratie kunnen externe websites ongewenst data opvragen van de API, wat kan leiden tot het lekken van factuur- en klantgegevens.
Injectie-aanvallen: Manipulatie van data via SQL injection, XSS of andere injectietechnieken. Als input validatie niet correct is geïmplementeerd, kunnen aanvallers kwaadaardige code injecteren die de database kan manipuleren of gebruikers kan misleiden.
Security misconfiguraties: Kwetsbaarheden door verkeerde configuraties (bijv. te ruime CORS-instellingen). Zelfs met goede code kunnen verkeerde configuraties leiden tot kwetsbaarheden, zoals het toestaan van alle cross-origin requests waardoor data kan worden opgevraagd vanaf andere websites.

Dit onderzoek richt zich daarom specifiek op de basisbeveiliging die nodig is voordat authenticatie wordt toegevoegd, om te voorkomen dat de applicatie kwetsbaar is voor veelvoorkomende aanvallen.

Doelstelling¶

Het doel van het onderzoek is inzicht te krijgen in mogelijke kwetsbaarheden van de applicatie op het gebied van datalekken en injectie-aanvallen, en concrete aanbevelingen te geven om deze risico's te verminderen of te voorkomen. Het onderzoek focust op de beveiliging van publieke endpoints en de frontend, zonder authenticatie als beschermingslaag.

Context van het onderzoek:

Wat wordt onderzocht: De beveiliging van de Spring Boot backend API en Nuxt 4 frontend, specifiek gericht op datalekken en injectie-aanvallen. Dit betekent dat wordt gekeken naar security headers, CORS configuratie, input validatie en bescherming tegen injectie-aanvallen zoals SQL injection en XSS.
Waarom deze focus: Deze zijn de meest relevante risico's voor een applicatie zonder authenticatie. Omdat er geen authenticatie laag is die aanvallen kan afvangen, moet de basisbeveiliging op orde zijn om te voorkomen dat gevoelige data wordt gelekt of dat de applicatie kwetsbaar is voor injectie-aanvallen.
Context: Alle endpoints zijn publiek toegankelijk zonder autorisatiecontroles. Dit betekent dat iedereen met toegang tot het netwerk de API kan benaderen, waardoor het extra belangrijk is dat security headers correct zijn geconfigureerd en dat input validatie goed werkt.

Hoofdvraag¶

"Hoe goed zijn de Spring Boot API en Nuxt 4 Frontend van de Factuur Beheer applicatie, zonder authenticatie, beschermd tegen datalekken en injectie-aanvallen?"

Methode¶

Onderzoeksopzet¶

Dit onderzoek maakt gebruik van het DOT Framework (Design, Operations, Technology) om verschillende aspecten van beveiliging te onderzoeken. Het DOT Framework categoriseert research strategies in verschillende categorieën, waarbij elke strategie geschikt is voor specifieke onderzoeksvragen.

DOT Framework Research Strategies:

Showroom Research: Onderzoek naar bestaande kennis en literatuur (theoretisch onderzoek)
Lab Research: Gecontroleerde experimenten in een gecontroleerde omgeving (testing)
Field Research: Onderzoek in de praktijkomgeving (real-world testing)

In dit onderzoek worden meerdere soorten testen gecombineerd volgens het DOT Framework. Eerst wordt in theorie bekeken wat belangrijk is (Showroom Research), daarna wordt de code gecontroleerd (Lab Research), en tot slot wordt de applicatie in een draaiende omgeving getest (Field Research). Door deze combinatie ontstaat een betrouwbaarder beeld dan met één losse test.

Deelvragen en onderzoeksmethoden¶

Om de hoofdvraag te beantwoorden, wordt het onderzoek opgesplitst in vier deelvragen die elk een ander aspect van de beveiliging onderzoeken. Elke deelvraag gebruikt een specifieke onderzoeksmethode die past bij de DOT Framework research strategies.

Belangrijk: Deelvragen 1-3 hebben een uitgebreide uitwerking op aparte pagina's. Deelvraag 4 staat volledig in dit document. Klik op de links in de kolom "Link naar deelvraag" om naar de volledige uitwerkingen te gaan.

#	Deelvraag	DOT Research Strategy	Methode	Link naar deelvraag
1	Welke beveiligingsrisico's uit de OWASP Top 10:2025 zijn relevant voor publieke API's zonder authenticatie?	Showroom Research	Literatuurstudie	→ Klik hier: Deelvraag 1 - OWASP Top 10 Project Analyse
2	Welke kwetsbaarheden gerelateerd aan datalekken en injectie-aanvallen komen naar voren bij statische analyse van de broncode?	Lab Research	Static Program Analysis	→ Klik hier: Deelvraag 2 - Static Analysis
3	Welke datalekken en injectie-aanvallen zijn daadwerkelijk mogelijk op de draaiende applicatie van buitenaf?	Field Research	Security Test	→ Klik hier: Deelvraag 3 - ZAP Report Toelichting
4	Wat zijn de volgende stappen die genomen kunnen worden in de applicatie en wat moet wel en niet worden toegepast?	Showroom Research	Analyse	Zie hieronder in dit document

Opmerking over tools: De tools die gebruikt zijn (zoals ESLint, SonarQube, OWASP ZAP) zijn tijdens het onderzoek gekozen op basis van geschiktheid voor de onderzoeksmethode. Deze waren niet vooraf bepaald maar zijn geselecteerd omdat ze passen bij de DOT Framework research strategies en de specifieke onderzoeksvragen.

Methoden per deelvraag¶

1. Literatuurstudie (Showroom Research)

DOT Framework categorie: Showroom Research - onderzoek naar bestaande kennis en standaarden
Methode: Analyse van de OWASP Top 10:2025 (OWASP Foundation, 2025) met focus op Java (Spring) en JavaScript (Nuxt/Vue)
Doel: Inzicht krijgen in de meest relevante beveiligingsrisico's, zoals injecties en verkeerde configuraties
Context: Deze methode is geschikt omdat OWASP Top 10 een erkende standaard is die gebaseerd is op praktijkervaringen en onderzoek

2. Static Program Analysis (Lab Research)

DOT Framework categorie: Lab Research - gecontroleerde analyse van code in een gecontroleerde omgeving
Methode: De broncode wordt geanalyseerd met geautomatiseerde tools volgens het Shift-Left principe (ICT Research Methods, z.d.-a)
Tools gebruikt: ESLint met security-plugin voor de frontend, SonarLint voor de backend (deze tools zijn tijdens het onderzoek geselecteerd op basis van geschiktheid)
Doel: Onveilige patronen opsporen, bijvoorbeeld gebruik van v-html of SQL-injectie gevoelige queries
Context: Deze methode valt onder Lab Research omdat de code wordt geanalyseerd zonder dat de applicatie draait, in een gecontroleerde omgeving

3. Security Test (Field Research)

DOT Framework categorie: Field Research - onderzoek in de praktijkomgeving met een draaiende applicatie
Methode: Dynamische tests op de live omgeving worden uitgevoerd (ICT Research Methods, z.d.-b)
Tools gebruikt: OWASP ZAP en Postman (deze tools zijn tijdens het onderzoek geselecteerd omdat ze geschikt zijn voor security testing van draaiende applicaties)
Doel: Controleren of endpoints data lekken en of invoervelden kwetsbaar zijn voor XSS of andere aanvallen
Context: Deze methode valt onder Field Research omdat de applicatie in een draaiende omgeving wordt getest, waarbij real-world scenario's worden gesimuleerd

Resultaten¶

Belangrijk: Deze sectie bevat samenvattingen. Voor uitgebreide analyses met screenshots, codevoorbeelden en gedetailleerde bevindingen, klik op de links in de tabel hierboven bij "Deelvragen en tools".

Deelvraag 1: Literatuurstudie (Eisenlijst)¶

Deelvraag 1: "Welke beveiligingsrisico's uit de OWASP Top 10:2025 zijn relevant voor publieke API's zonder authenticatie?"

Relevante Risico's voor Dit Project¶

Volgens OWASP Top 10:2025 (OWASP Foundation, 2025) zijn voor publieke API's zonder authenticatie de volgende risico's het meest relevant:

OWASP Risico	Status in Project	Actie Vereist
A05 - Injection	Goed - Input validatie aanwezig	Geen actie
A02 - Security Misconfiguration	Probleem - CORS open, headers ontbreken	Aanpassen
A10 - Exception Handling	Goed - Error handling geïmplementeerd	Geen actie
A01 - Broken Access Control	Belangrijk - Geen authenticatie/autorisatie	Voor productie vereist
A07 - Authentication Failures	Belangrijk - Geen authenticatie geïmplementeerd	Voor productie vereist

Belangrijke Opmerking over Authenticatie:

A01 - Broken Access Control en A07 - Authentication Failures zijn volgens OWASP Top 10:2025 (OWASP Foundation, 2025) kritieke risico's voor productie applicaties, maar zijn niet onderzocht omdat er nog geen authenticatie is geïmplementeerd.

Conclusie: A02 (Security Misconfiguration) is het belangrijkste aandachtspunt voor dit onderzoek.

Voor volledige analyse met codevoorbeelden: → Klik hier voor Deelvraag 1 - OWASP Top 10 Project Analyse

Deelvraag 2: Static Program Analysis¶

Deelvraag 2: "Welke kwetsbaarheden gerelateerd aan datalekken en injectie-aanvallen komen naar voren bij statische analyse van de broncode?"

Code Review Resultaten¶

OWASP Risico	Status	Gevonden Probleem	Actie
A05 - Injection	Goed	Input validatie met `@Valid` werkt correct	Geen actie
A02 - Security Misconfiguration	Probleem	CORS volledig open (`allowedOriginPatterns("*")`)	Aanpassen
A02 - Security Misconfiguration	Probleem	Security headers ontbreken (CSP, X-Frame-Options)	Aanpassen
A10 - Exception Handling	Goed	Error handling geïmplementeerd	Geen actie

Aanpassingen Vereist¶

1. CORS instellingen aanscherpen (CorsConfig.java)

Probleem: allowedOriginPatterns("*") staat alle origins toe
Oplossing: Alleen specifieke origins toestaan (localhost:3000, productie domain)
OWASP Risico: A02 - Security Misconfiguration
Gevolg: Helpt voorkomen dat data vanaf een andere website ongewenst kan worden opgevraagd

2. Security Headers Toevoegen (nuxt.config.ts)

Probleem: CSP, X-Frame-Options headers ontbreken
Oplossing: Installeer @nuxtjs/security module
OWASP Risico: A02 - Security Misconfiguration
Gevolg: Helpt om XSS aanvallen te voorkomen

ESLint Security Analyse¶

Status: Uitgevoerd

ESLint is uitgevoerd met security plugins (eslint-plugin-security, eslint-plugin-security-node) voor de frontend code analyse:

Tool: npm run security:lint (ESLint met security plugins)
Doel: Detecteren van onveilige patronen in frontend code
OWASP Risico's: Analyseert A05 (Injection), A02 (Security Misconfiguration), A06 (Insecure Design)

Resultaten:

Beveiligingswaarschuwingen gevonden in de Nuxt code
De waarschuwingen zijn geen directe kwetsbaarheden, maar indicatoren voor code die verbeterd kan worden
ESLint helpt om onveilige patronen vroeg te detecteren tijdens development

Voor volledige analyse met screenshots en codevoorbeelden: → Klik hier voor Deelvraag 2 - Static Analysis

Deelvraag 3: Security Test (Field Research)¶

Deelvraag 3: "Welke datalekken en injectie-aanvallen zijn daadwerkelijk mogelijk op de draaiende applicatie van buitenaf?"

DOT Framework categorie: Field Research - onderzoek in de praktijkomgeving met een draaiende applicatie

Voor deze deelvraag is gebruik gemaakt van OWASP ZAP (Zed Attack Proxy), een geautomatiseerde security testing tool die de draaiende applicatie heeft gescand op http://host.docker.internal:3000. ZAP voert een passieve security scan uit door HTTP requests te analyseren, response headers te controleren en bekende kwetsbaarheidspatronen te detecteren.

Voor uitgebreide toelichting op het ZAP rapport: → Klik hier voor ZAP Report Toelichting
Voor het volledige ZAP rapport (HTML): → Klik hier voor ZAP Report HTML

Conclusie¶

De ZAP scan heeft geen kritieke kwetsbaarheden gevonden. Wel zijn er 3 Medium issues gevonden die allemaal te maken hebben met ontbrekende security headers (A02 - Security Misconfiguration): CSP header ontbreekt, CORS staat alles toe, en anti-clickjacking header ontbreekt. De injectie testen (SQL injection en XSS) zijn succesvol afgeweerd, wat betekent dat de code zelf goed beschermd is. Het probleem zit vooral in de configuratie - door de security headers toe te voegen en CORS te beperken kunnen deze issues worden opgelost.

Deelvraag 4: Volgende stappen voor de applicatie¶

Deelvraag 4: "Wat zijn de volgende stappen die genomen kunnen worden in de applicatie en wat moet wel en niet worden toegepast?"

Wat moet worden toegepast (Prioriteit 1)¶

1. Security headers toevoegen

Installeer @nuxtjs/security module in nuxt.config.ts
Lost op: CSP header, X-Frame-Options, X-Content-Type-Options
Impact: Voorkomt XSS en clickjacking aanvallen

2. CORS configuratie beperken

Wijzig CorsConfig.java: vervang allowedOriginPatterns("*") door specifieke origins
Impact: Voorkomt datalekken via cross-origin requests

Wat kan worden toegepast (Prioriteit 2)¶

3. ESLint security waarschuwingen adresseren

Analyseer en los de gevonden ESLint security waarschuwingen op
Impact: Verbetert code kwaliteit en vermindert risico's op toekomstige kwetsbaarheden

Conclusie: Focus eerst op Prioriteit 1 (security headers en CORS) om de gevonden kwetsbaarheden op te lossen.

Bespreking van de resultaten¶

Interpretatie van de resultaten¶

Combinatie van de drie methoden:

Literatuurstudie: laat zien dat A02 (Security Misconfiguration) belangrijk is voor dit project
Static analysis: vindt A02-problemen (CORS, headers) en laat zien dat A05 (Injection) in de code goed is ingericht
ZAP-testen: laten dezelfde A02-problemen zien en hebben geen succesvolle injectie‑aanvallen gevonden

Conclusie: alle drie de methoden wijzen naar hetzelfde probleem: A02 is het belangrijkste aandachtspunt.

Beperkingen¶

Authenticatie/Autorisatie niet onderzocht: Dit aspect is buiten scope gehouden omdat er nog geen authenticatie is geïmplementeerd in de applicatie. Voor productie is dit echter een kritieke vereiste volgens OWASP Top 10:2025 (A01 - Broken Access Control en A07 - Authentication Failures).
Alleen een passieve ZAP scan gedaan: Er zijn geen actieve aanvallen uitgevoerd waarbij ZAP daadwerkelijk probeert kwetsbaarheden te exploiteren. Een actieve scan zou mogelijk meer kwetsbaarheden kunnen vinden, maar vereist meer tijd en kan de applicatie belasten.
Alleen getest op een development omgeving: De tests zijn uitgevoerd op http://host.docker.internal:3000 in een development omgeving. Productie omgevingen kunnen andere configuraties hebben (bijv. reverse proxy, load balancer) die de security headers kunnen aanpassen of aanvullen.

Beantwoording van de deelvragen¶

Hieronder worden verwijzingen gegeven naar de beantwoording van elke deelvraag. Elke deelvraag heeft een uitgebreide uitwerking met conclusie op een aparte pagina.

Tip: Elke deelvraag heeft een link naar de uitgebreide uitwerking met gedetailleerde analyses, codevoorbeelden en conclusie.

Deelvraag 1: Welke beveiligingsrisico's uit de OWASP Top 10:2025 zijn relevant voor publieke API's zonder authenticatie?¶

→ Zie conclusie bij Deelvraag 1 - OWASP Top 10 Project Analyse

Deelvraag 2: Welke kwetsbaarheden gerelateerd aan datalekken en injectie-aanvallen komen naar voren bij statische analyse van de broncode?¶

→ Zie conclusie bij Deelvraag 2 - Static Analysis

Deelvraag 3: Welke datalekken en injectie-aanvallen zijn daadwerkelijk mogelijk op de draaiende applicatie van buitenaf?¶

→ Zie conclusie bij Deelvraag 3 - ZAP Report Toelichting

Deelvraag 4: Wat zijn de volgende stappen die genomen kunnen worden in de applicatie en wat moet wel en niet worden toegepast?¶

Antwoord:

Wat moet worden toegepast (direct implementeren):

Security headers toevoegen - Installeer @nuxtjs/security module. Lost de 3 Medium ZAP issues op (CSP, X-Frame-Options, X-Content-Type-Options).
CORS configuratie beperken - Wijzig CorsConfig.java om alleen specifieke origins toe te staan. Voorkomt datalekken via cross-origin requests.

Wat kan worden toegepast (optioneel):

ESLint security waarschuwingen adresseren - Analyseer en los de gevonden ESLint security waarschuwingen op voor verbeterde code kwaliteit.

Conclusie deelvraag 4: Focus eerst op de twee prioriteit 1 aanpassingen (security headers en CORS) om de gevonden kwetsbaarheden op te lossen. De andere aanbevelingen zijn optioneel.

Conclusie¶

Antwoord op Hoofdvraag¶

Hoofdvraag: "Hoe goed zijn de Spring Boot API en Nuxt 4 Frontend, zonder authenticatie, beschermd tegen datalekken en injectie-aanvallen?"

Antwoord:

Goed beschermd tegen injectie-aanvallen (A05 - Injection):

Input validatie met @Valid annotations voorkomt SQL injection
JPA/Hibernate gebruikt parameterized queries (geen SQL injection mogelijk)
Vue.js escaped automatisch user input (geen XSS mogelijk)
ZAP testen bevestigen: SQL injection en XSS aanvallen werken niet
Conclusie: De applicatie heeft een solide basis voor injectie preventie

Gedeeltelijk beschermd tegen datalekken (A02 - Security Misconfiguration):

Security headers ontbreken (CSP, X-Frame-Options, X-Content-Type-Options)
CORS te permissief ingesteld (alle origins toegestaan via allowedOriginPatterns("*"))
ZAP scan: 3 Medium issues gevonden, allemaal gerelateerd aan A02
Conclusie: Security configuratie moet worden verbeterd om volledig beschermd te zijn tegen datalekken

Algemene Conclusie:

De applicatie heeft een solide basis en de huidige inputvalidatie is correct opgezet, waardoor injectie-aanvallen (A05) worden afgevangen. De securityconfiguratie (A02) is echter nog niet op het niveau dat nodig is om datalekken volledig te voorkomen. Met de aanbevolen aanpassingen (security headers en CORS beperking) kan de applicatie volledig beschermd worden tegen de risico's die binnen de scope van dit onderzoek vallen.

Aanbevelingen¶

Prioriteit 1 (Direct implementeren):

Security headers toevoegen
Installeer @nuxtjs/security module
OWASP Risico: A02 - Security Misconfiguration
Lost op: ontbrekende CSP en X-Frame-Options headers (ZAP Issue 1, 3)
Gevolg: Helpt XSS en clickjacking-aanvallen te voorkomen
CORS configuratie beperken
Wijzig CorsConfig.java - alleen specifieke origins
OWASP Risico: A02 - Security Misconfiguration
Lost op: te ruime CORS-instellingen (ZAP Issue 2)
Gevolg: Helpt voorkomen dat data vanaf een andere website ongewenst kan worden opgevraagd

Prioriteit 2 (Voor productie):

ESLint security waarschuwingen adresseren
Analyseer en los de gevonden ESLint security waarschuwingen op
OWASP Risico: Kan problemen vinden voor A05, A02, A06
Gevolg: Verbetert code kwaliteit en vermindert risico's op toekomstige kwetsbaarheden

Prioriteit 3 (Best practices):

HTTPS/TLS inschakelen: In productie moet altijd HTTPS worden gebruikt om data te versleutelen tijdens transport. Dit voorkomt dat data kan worden onderschept door man-in-the-middle aanvallen.
Rate limiting toevoegen: Rate limiting beperkt het aantal requests dat een client kan maken binnen een bepaalde tijd. Dit helpt om brute force aanvallen en denial-of-service aanvallen te voorkomen.
Uitgebreidere security testing doen: Naast de passieve ZAP scan kan een actieve scan worden uitgevoerd waarbij ZAP daadwerkelijk probeert kwetsbaarheden te exploiteren. Dit kan meer kwetsbaarheden vinden maar vereist meer tijd en planning.

Bronnen¶

ICT Research Methods. (z.d.-a). Method: Static Program Analysis. https://ictresearchmethods.nl/showroom/static-program-analysis
ICT Research Methods. (z.d.-b). Method: Security Test. https://ictresearchmethods.nl/lab/security-test/
OWASP Foundation. (2025). OWASP Top 10:2025. https://owasp.org/Top10/2025/

Buiten scope van dit onderzoek¶

Tijdens het onderzoek zijn de volgende onderwerpen bewust buiten de scope gehouden:

Authenticatie/Autorisatie: Niet onderzocht omdat dit nog niet geïmplementeerd is in de applicatie
HTTPS/TLS: Niet getest omdat het onderzoek plaatsvond in een development omgeving
Rate limiting: Architectuur keuze, valt buiten de scope van dit onderzoek

Bijlagen¶

Klik op de links om naar de bijlagen te gaan.

Document	Beschrijving	Link
Deelvraag 1 - OWASP Top 10 Literatuurstudie	OWASP Top 10:2025 analyse voor publieke API's	→ Klik hier
Deelvraag 1 - OWASP Top 10 Project Analyse	Project specifieke code review	→ Klik hier
Deelvraag 2 - Static Analysis	Resultaten static analysis (SonarQube/ESLint)	→ Klik hier
Deelvraag 3 - ZAP Report Toelichting	Uitleg van ZAP scan resultaten en bevindingen	→ Klik hier
Deelvraag 3 - ZAP Security Test (HTML)	Volledig ZAP scan rapport	→ Klik hier
Deelvraag 3 - ZAP Automatisering	ZAP setup en gebruik	→ Klik hier