What are security vulnerabilities in Angular apps, and how does DomSanitizer prevent XSS?

Q: What are security vulnerabilities in Angular apps, and how does DomSanitizer prevent XSS?

**Target Audience:** Angular developers preparing for security questions; no security background assumed. **Difficulty:** Medium > **How to read this doc:** Ideas are explained in plain language first, then tagged with 📌 Interview term: so you also learn the words an interviewer listens for. Sections 4 and 5 quote output from running both examples on Angular 22.2.3 (the first in AOT and playground modes, identical output). The CSP, XSRF and SSR findings came from a CLI 22.2.3 build, an HttpClient run with a recording fetch , and renderApplication . No real attack against a browser was performed; jsdom does not execute javascript: URLs or inline handlers the way a browser would. ## 1. Why This Even Matters — A Story First A noticeboard in an office lets anyone pin up a message. One day somebody pins a note that says, in small print, "whoever reads this, please hand your badge to the person standing behind you". Most people would laug

The problem

Question presented to candidate: "A security review found that user profiles accept HTML and links. Explain which vulnerabilities matter most in an Angular front end, how Angular protects against XSS by default, and when, if ever, you would use DomSanitizer's bypass methods."

What a strong answer should cover:

XSS as the main client-side threat; Angular's model: all bound values are untrusted by default.
Contextual sanitization: interpolation escapes text; HTML, URL and resource-URL contexts are sanitized or rejected (unsafe: prefix, stripped <script>/onerror, NG0904 for resource URLs).
DomSanitizer: sanitize() for manual cleaning; bypassSecurityTrust* only for values you control, and the risk of using it on user input.
Other defences: CSP (including autoCsp and nonces), Trusted Types, AOT and never compiling user templates, XSRF handling in HttpClient, SSR allowedHosts.
Practical hygiene: no direct innerHTML via ElementRef, dependency updates, server-side validation.

Clarifying questions expected:

"Do users need rich text, or would plain text plus markdown rendered safely do?"
"Is the app server-rendered? That adds host-header and request-forgery concerns."

Code / implementation expected: Yes — bindings that show sanitization, and one justified bypassSecurityTrustResourceUrl.

security
xss

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Angular developers preparing for security questions; no security background assumed. Difficulty: Medium

How to read this doc: Ideas are explained in plain language first, then tagged with 📌 Interview term: so you also learn the words an interviewer listens for. Sections 4 and 5 quote output from running both examples on Angular 22.2.3 (the first in AOT and playground modes, identical output). The CSP, XSRF and SSR findings came from a CLI 22.2.3 build, an HttpClient run with a recording fetch, and renderApplication. No real attack against a browser was performed; jsdom does not execute javascript: URLs or inline handlers the way a browser would.

1. Why This Even Matters — A Story First

A noticeboard in an office lets anyone pin up a message. One day somebody pins a note that says, in small print, "whoever reads this, please hand your badge to the per

The solution is hidden so you can try first

10 min read · 9 sections

Read the code

AngularWhat Angular does to untrusted HTML and URLs in bindings

Open in playground

import { Component } from "@angular/core";

// Untrusted input, e.g. a user bio or a link pasted into a comment.
const EVIL_HTML = `<b>Hi</b><img src="x" onerror="alert(1)"><script>alert(2)</script><a href="javascript:alert(3)">me</a>`;

@Component({
  selector: "app-root",
  template: `
    <!-- 1. Interpolation: always text, never parsed as HTML. -->
    <p id="interp">{{ html }}</p>

    <!-- 2. [innerHTML]: parsed, but run through the HTML sanitizer first. -->
    <div id="inner" [innerHTML]="html"></div>

    <!-- 3. [href]: URL context, dangerous schemes are neutralised. -->
    <a id="link" [href]="url">profile</a>
    <a id="safe" [href]="okUrl">docs</a>
  `,
})
export class AppComponent {
  html = EVIL_HTML;
  url = "javascript:alert(4)";
  okUrl = "https://example.com/docs";
}

AngularDomSanitizer by hand: sanitize() and the bypassSecurityTrust methods

import { Component, SecurityContext, inject } from "@angular/core";
import { DomSanitizer, SafeHtml, SafeResourceUrl } from "@angular/platform-browser";

const VIDEO = "https://www.youtube-nocookie.com/embed/abc123";

@Component({
  selector: "app-root",
  template: `
    <div id="trusted" [innerHTML]="trustedHtml"></div>
    <iframe id="video" [src]="videoUrl" title="Demo video"></iframe>
  `,
})
export class AppComponent {
  private sanitizer = inject(DomSanitizer);

  // sanitize(): the same cleaning Angular applies to bindings, called by hand.
  cleaned = {
    html: this.sanitizer.sanitize(SecurityContext.HTML, `<b onclick="steal()">bold</b><script>x()</script>`),
    url: this.sanitizer.sanitize(SecurityContext.URL, "javascript:alert(1)"),
    dataImage: this.sanitizer.sanitize(SecurityContext.URL, "data:image/png;base64,iVBORw0KGgo="),
    style: this.sanitizer.sanitize(SecurityContext.STYLE, "background: url(javascript:alert(1))"),
  };

  // bypassSecurityTrust*(): YOU vouch for the value; Angular stops checking it.
  // Only for values you control, never for user input.
  trustedHtml: SafeHtml = this.sanitizer.bypassSecurityTrustHtml(`<button onclick="track()">Trusted markup</button>`);
  // A resource URL (iframe src, script src) is never sanitized: it must be explicitly trusted.
  videoUrl: SafeResourceUrl = this.sanitizer.bypassSecurityTrustResourceUrl(VIDEO);
}

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.