Framework security: React, Angular, and the escape hatches

React, Angular, and Vue changed web security by escaping output automatically, which prevents most XSS for free. That shifts the tester’s job: instead of hunting for any unescaped output, you hunt for the specific escape hatches where a developer deliberately bypassed the framework’s protection. Knowing each framework’s dangerous APIs is the skill.

Safe by default

When you render data in a modern framework, it’s escaped automatically — a string with HTML in it shows as text, not markup.

// React — userName is escaped automatically, even if it contains HTML:
function Greeting({ userName }) {
  return <h1>Hello {userName}</h1>;   // safe: HTML in userName renders as text
}

The framework treats interpolated values as data, not markup. This is why framework apps have far less XSS than the old days of building HTML by hand — the safe path is the default path.

The escape hatches — where to look

Each framework has an API that says ‘render this as raw HTML, I know what I’m doing.’ Those are exactly where XSS hides:

React     dangerouslySetInnerHTML={{ __html: value }}
          (the name is a deliberate warning)
Angular   [innerHTML]="value"  with bypassSecurityTrustHtml()
Vue       v-html="value"
All       direct DOM access (ref then innerHTML), document.write

The names are honest — React’s dangerouslySetInnerHTML warns you in the API itself. When a developer uses one of these with data that traces back to user input, the framework’s protection is gone and XSS is back.

Key takeaways

• Modern frameworks escape rendered output by default, preventing most XSS.
• Each has an escape hatch: dangerouslySetInnerHTML, v-html, bypassSecurityTrust.
• Testing means finding those opt-outs and tracing them to user input.
• Watch also for template injection and server-side-rendering seams.

Next, reading the real thing — beautifying minified bundles and using source maps to recover readable code.