Network inspector tools, ingebouwd in moderne browsers, stellen ontwikkelaars in staat om webverkeer, het laden van bronnen en beveiligingsproblemen te monitoren en te debuggen. Hoewel essentieel voor ontwikkeling en debugging, kunnen deze tools ook door aanvallers worden gebruikt om applicaties te analyseren. Beveiligingsmaatregelen moeten rekening houden met de informatie die via deze tools wordt blootgesteld.
Network-inspectortools zijn de panelen die in de ontwikkelaarstools van een browser zijn ingebouwd, zoals het Network-tabblad in Chrome DevTools of Firefox, die elk verzoek registreren dat een pagina doet. Voor elk verzoek tonen ze de URL, methode, status, headers, timing, payload, cookies en de responsbody, waardoor een ontwikkelaar precies kan zien wat de pagina heeft opgehaald en in welke volgorde. Ze werken samen met verwante panelen voor de DOM, console, opslag en JavaScript-debugging. De tools zijn onbevoorrecht: ze tonen alleen wat de huidige pagina en de eigen sessie van de persoon al kunnen benaderen, en ze draaien volledig op de client. Ze zijn onmisbaar voor het bouwen en debuggen van webapplicaties en voor het diagnosticeren van prestatie- en securityproblemen.
Omdat de inspector alles blootlegt wat de browser ziet, is het ook een verkenningstool. Iedereen kan hem openen en de API-endpoints lezen die een site aanroept, de vorm van zijn verzoeken, de tokens en cookies die in het spel zijn, en elk geheim dat een ontwikkelaar per ongeluk naar de client heeft verstuurd. Dit is een routinematige eerste stap bij het onderzoeken van een webapplicatie: breng het verkeer in kaart en herhaal of manipuleer vervolgens verzoeken. Het belangrijke punt is dat de inspector geen nieuwe toegang verleent; hij onthult alleen wat de client al bezit. Het risico is dus niet de tool, maar de aanname dat client-side code of data verborgen is. Alles wat naar de browser wordt gestuurd, inclusief verborgen formuliervelden en geminificeerde logica, is volledig zichtbaar voor de gebruiker.
De verdedigende les is om te ontwerpen alsof elk client-side verzoek en antwoord openbaar is, want voor de gebruiker is dat zo. Vertrouw nooit op onbekendheid: houd geheimen, ondertekeningssleutels en autorisatielogica op de server, dwing elke toegangscontrole server-side af, en ga ervan uit dat geminificeerde of geobfusceerde JavaScript gelezen kan worden. Stuur de browser alleen de data waar een bepaalde gebruiker recht op heeft en beperk de scope van tokens strak. Obfuscatie kan de inspanning van analyse verhogen, maar vervangt nooit een echte controle. Niets hiervan is iets wat een derde partij voor je kan afdichten: het is een eigenschap van hoe je de applicatie bouwt. Door de network-inspector te behandelen als een permanent, legitiem onderdeel van de browser van elke bezoeker, kom je tot eerlijkere en veiligere ontwerpen.
Niet effectief. Scripts die DevTools proberen te detecteren of te blokkeren, zijn eenvoudig te omzeilen en frustreren vooral legitieme gebruikers. Omdat de tools in de eigen browser van de gebruiker draaien, kun je ze niet betrouwbaar uitschakelen. Het duurzame antwoord is om zo te bouwen dat er om te beginnen niets gevoeligs aan de client wordt blootgesteld.
Nee. De verzoeken van elke webapp zijn per ontwerp zichtbaar in de inspector, en dat alleen is geen fout. Het wordt pas een probleem als die verzoeken geheimen onthullen of als de server erop vertrouwt dat de client zijn eigen rechten afdwingt. Een goed gebouwde API blijft veilig, zelfs wanneer hij volledig wordt geobserveerd.
We answer client-side security questions every day. Bring yours.