XSS är ett område där små designval ofta avgör om kontrollen blir robust eller bara ser bra ut på papper. XSS är ett kontextproblem: data som är ofarlig i text kan bli körbar kod om den placeras i HTML, attribut, JavaScript eller URL utan rätt escaping.
XSS i praktiken
Första byggstenen: Output encoding måste matcha kontexten där värdet används. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: Template engines skyddar ofta HTML-text men inte alla råa insättningar. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: CSP kan minska konsekvensen men ersätter inte korrekt encoding. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: DOM-baserad XSS kan uppstå helt på klientsidan. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Praktisk införandeordning
- Kartlägg var användarstyrd data renderas.
- Undvik raw HTML-funktioner om innehållet inte är sanerat.
- Använd säkra DOM-API:er som textContent för text.
- Sanera uttryckligen när rich text verkligen krävs.
- Lägg CSP som ytterligare lager.
För XSS håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Så kan det se ut
Jag testar inte bara <script>-taggar. Ett värde kan hamna i exempelvis href, ett data-attribut eller en JavaScript-sträng, och varje kontext kräver sin egen säkra hantering.
Tre risker i implementationen
- Att HTML-escape:a data och sedan placera den direkt i JavaScript-kod.
- Att använda innerHTML för enkel text.
- Att lita på client-side validation som säkerhetsgräns.
När jag anser ändringen färdig
För XSS vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- Teststräng visas som text och körs inte.
- Samma värde provas i HTML-, attribut- och scriptkontext.
- CSP blockerar oväntad scriptkälla.
Ett negativt test hör också till XSS: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
XSS – när data blir kod i webbläsaren handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.