Cross-site scripting has been around long enough to feel embarrassing. The technique was first written up in the late 1990s, and yet XSS findings still appear in roughly seven out of ten web application tests we deliver. Modern frameworks have improved the default position, but the gaps that remain are sharper, harder to spot and often more damaging than the reflected payloads of the past.
DOM-Based XSS Slips Past Server Defences
Server side filters cannot stop attacks that never reach the server. DOM-based XSS lives entirely in the browser, with the payload often arriving inside a URL fragment that the application reads, parses and writes back to the page. Single page applications are particularly exposed because their templating, routing and state handling all run client side. A good web application pen testing engagement should probe each of these layers, not just submit a few common script tags into form fields.
Content Security Policy Is Only Half a Defence
A well configured Content Security Policy reduces the blast radius of XSS, but it is not a substitute for proper output encoding. Far too many policies allow unsafe-inline because the team could not be bothered to refactor inline event handlers. Far too many use script-src with overly permissive sources. CSP is a useful safety net but the floor still needs to be solid.
Expert Commentary
William Fieldhouse, Director of Aardwolf Security Ltd
When clients ask why their CSP did not save them, the answer is usually that the policy allowed every CDN under the sun, including one that hosted the attacker payload. Treat your allow lists as a security control in their own right, and review them with the same care you would give to firewall rules.
Stored XSS Carries The Longest Tail
Reflected XSS gets fixed quickly because the attack surface is obvious. Stored XSS lives in databases, message threads, comment fields and any other location where user input gets persisted and rendered later. The fix involves more than encoding at the rendering layer. It requires understanding where user input enters the system, how it flows through the application and how every consumer renders it. A stored XSS that affects an internal admin interface is particularly dangerous because the audience is privileged. The vulnerability becomes a privilege escalation path. Treat user submitted content as untrusted at every point it appears, not just at the point of submission. Worth running periodic content audits on user generated areas of your application, because the XSS payload that was harmless when planted six months ago can become dangerous after a template change makes it render in a different context.
Encoding Context Is Where Most Teams Trip
HTML encoding is not the same as JavaScript encoding, which is not the same as URL encoding. The right approach depends entirely on where the data lands in the response. A value that lands inside an HTML attribute, inside a JavaScript block, inside a JSON response and inside a URL all need different treatment. Treat encoding as context aware or accept that the gaps will be found eventually.
Worth pairing application testing with regular vulnerability scan services across your perimeter so reflected payloads from forgotten subdomains do not creep back in unnoticed. XSS remediation is rarely complete in one pass. Treat it as a recurring activity, with regular review cycles tied to your release schedule. Web application security is a discipline that rewards patient investment. The teams that treat it as ongoing work consistently outperform the ones that treat it as a project with an end date.
