Explain to a developer that ignoring XSS is a mistake

You run a web application scanner on your portal and discover several types of XSS flaws.

You point them to the website developer and his answer is: "Why bother? I have tested it myself and it does not work at all. Your scanner is wrong. And then, who would attack himself?"

How would you approach the issue?

If you happen to have this type of developers maybe they should start make their living doing something else. It sounds harsh but the truth is they must know better than that.

First of all, make sure the developer tested it properly, because using the notorious <script>alert(1)</script> simply does not work in modern browsers.

While browsers block the <script>alert(1)</script> test, real attackers use DOM‑based payloads, stored payloads, gadget chains, and frameworks quirks (React, Node.js/Express, Next.js to name a few) that browsers can’t detect.

Stored XSS and DOM XSS bypass browser protections completely. If we don’t fix it, nobody else can.

If we rely on browser filters to fix our bugs, we’re shipping broken code and hoping the client cleans it up. That’s not engineering — that’s gambling.

In addition, browsers tend to skip the XSS protection completely: Chrome removed XSS Auditor in 2020, Firefox never had one and Safari’s is minimal. They rely more on CSP and filter and parsing rules (blocking inline scripts not a XSS per se).

Who is in danger?

The people in danger are our users (or anyone who trusts our website and visits it) — their sessions, their data, their accounts.

XSS is not an attack on the server, the web server is just the delivery mechanism.

XSS is an attack on the user’s browser: the browser executes the malicious script because it trusts your domain.

Anyone who loads the page is a target and the more trusted the domain, the more valuable the existing XSS flaw is.

XSS Type Coverage

Modern browsers block simple reflected XSS payloads like <script>alert(1)</script> due to legacy built-in filters and improved HTML parsing rules, even if dedicated XSS auditors are deprecated.

Why It Fails

The payload often gets reflected but neutralized during parsing or execution. Browsers like Chrome, Safari, and Edge detect obvious script tags in reflected contexts (e.g., URL parameters echoed without escaping) and either strip them or prevent execution via heuristics from old XSS Auditor logic. Without an X-XSS-Protection header or CSP explicitly set to allow it, modern rendering escapes or ignores the tag in non-script contexts.

Protection Details