Application security notes

If you ask any developer how to stop Cross-Site Scripting (XSS), you will usually get the same answer: "Just sanitize your inputs."

It sounds simple. Yet every year, large technology companies with serious security teams still report critical XSS vulnerabilities. If the rules are so well known, and modern frameworks like React and Angular are secure by default, why are we still fighting a bug that was discovered in the 1990s?

The truth is that defending against XSS is not just about memorizing a checklist. It is about understanding human behavior, architectural complexity, and building safety nets.

The Core Problem: Sources and Sinks

Before we talk defense, we have to understand the mechanics. XSS comes down to two things: sources, where untrusted data enters your app, and sinks, where that data is rendered on the screen.

The vulnerability happens when a dangerous sink blindly trusts an untrusted source.

For example, imagine a user names their task <script>alert('Hacked')</script>.

If your frontend uses .textContent to render it, the browser treats it as harmless text. The user just sees the literal characters on the screen. That is a safe sink.

If your frontend uses .innerHTML to render it, the browser assumes it is valid HTML and executes the code. That is a dangerous sink.

Modern frameworks try to push developers toward safe sinks, but teams often need to render rich text or custom HTML. That is where the risk comes back.

Why "Secure" Modern Apps Still Fail

If React escapes data by default, how do XSS payloads still slip through? It usually comes down to three things.

The Escape Hatch Problem

Business requirements often demand rich text formatting, such as a blog post or an email template. To make this work, developers may use a framework escape hatch like React's explicitly named dangerouslySetInnerHTML. If it is used under deadline pressure and the data is not sanitized first, the app can become vulnerable.

Supply Chain Trust

Modern apps are glued together with third-party code: marketing trackers, support widgets, analytics scripts, and other integrations. You might write careful code, but if a trusted third-party script is compromised, it can inject malicious behavior directly into the page.

The Data Hop

In larger systems, data does not just travel from the user to the database and back. It can move through API gateways, queues, and multiple services. One team assumes another team sanitized the data. Another team assumes the frontend will handle it. The value arrives at the UI unchanged, and the problem appears there.

The 5-Layer Defense Playbook

Because people make mistakes and systems get complex, a single line of defense is not enough. Good XSS prevention needs overlapping safety nets.

Layer 1: Context-Aware Encoding

Data should be neutralized right before it reaches the screen. The important detail is context. Data placed inside an HTML tag needs different handling than data placed inside a JavaScript variable. Use a templating engine or frontend framework that handles context-aware escaping instead of doing it manually.

Layer 2: Enforce Safe Sinks

Make dangerous DOM manipulation difficult to introduce. Linting and code review can flag risky APIs such as .innerHTML, document.write(), and eval(). The safer default is to use .textContent or framework-specific safe bindings.

Layer 3: Strict HTML Sanitization

When rich HTML is truly required, do not try to clean it with custom regular expressions. That approach is fragile. Use a well-tested sanitization library such as DOMPurify before the content is allowed into the DOM.

Layer 4: Content Security Policy

A Content Security Policy is a browser safety net. If an unsafe script is injected, a strong CSP can tell the browser not to execute inline scripts. It does not replace secure coding, but it can reduce damage when another control fails.

Layer 5: Damage Control with HttpOnly Cookies

Assume that a script might eventually execute. The next goal is to reduce what it can steal. Marking session cookies as HttpOnly tells the browser that JavaScript cannot read them, which helps protect session tokens even if an XSS payload fires.

The Takeaway

Security is never solved once and forgotten. It is a continuous process of managing complexity. As developers and security engineers, the better question is not only "Did someone sanitize this?" It is also, "If a developer makes a mistake here, what safety net catches it?"