Angular Security (XSS, Sanitization & CSP)

Q: What is cross site scripting, often called XSS, and how does Angular protect against it by default?

Cross site scripting happens when an attacker manages to inject malicious code into a page, which then runs in another user's browser, often stealing information or performing unwanted actions. Angular protects against this automatically by treating any value you bind through normal template interpolation as plain text, safely escaping special characters instead of running them as code.

Q: What is Angular's DomSanitizer service and when would you need to use it?

The DomSanitizer service lets you explicitly mark a value as safe to use in a specific context, like HTML, a URL, or a style, bypassing Angular's default automatic sanitization. It should only be used with content you fully trust, such as HTML generated by your own backend, never with raw, untrusted user input.

Q: How would you safely display user generated HTML content, such as a rich text comment, without exposing your app to XSS attacks?

You use a trusted sanitization library, like DOMPurify, to clean the HTML first, removing any dangerous scripts or unsafe attributes, before ever marking the result as trusted using Angular's DomSanitizer. This lets you safely support formatted content like bold text or links while blocking anything genuinely harmful.

Q: What is a Content Security Policy, often shortened to CSP, and how does it add another layer of protection to an Angular app?

A Content Security Policy is a set of rules, usually sent as an HTTP header from the server, that tells the browser exactly which sources of scripts, styles, and other content are allowed to load on a page. Even if an attacker somehow manages to inject a malicious script, a properly configured CSP can prevent that script from actually running or from communicating with an unapproved server.

Q: Why should you avoid storing sensitive information, like an authentication token, directly in an Angular app's local storage?

Data kept in local storage remains accessible to any JavaScript running on the page, meaning a successful cross site scripting attack could potentially read and steal that token. Storing sensitive tokens in a properly configured cookie that JavaScript cannot access at all offers stronger protection.

5 questions found

What is cross site scripting, often called XSS, and how does Angular protect against it by default?

Beginner

Cross site scripting happens when an attacker manages to inject malicious code into a page, which then runs in another user's browser, often stealing information or performing unwanted actions. Angular protects against this automatically by treating any value you bind through normal template interpolation as plain text, safely escaping special characters instead of running them as code.

@Component({
  selector: 'app-comment',
  template: `<p>{{ comment }}</p>` // Angular automatically escapes this safely
})
export class CommentComponent {
  comment = 'Hello there'; // even suspicious looking input is displayed as safe plain text
}

Real-world example A blog's comment section safely displays user submitted comments containing suspicious looking text, because Angular automatically escapes it as plain text instead of accidentally running it as real code in another visitor's browser.

Common follow-ups: What specifically does Angular do differently from directly inserting text into the DOM using plain JavaScript?;Are there any situations where Angular's automatic protection does not apply?

Data Binding;Components & Templates

What is Angular's DomSanitizer service and when would you need to use it?

Intermediate

The DomSanitizer service lets you explicitly mark a value as safe to use in a specific context, like HTML, a URL, or a style, bypassing Angular's default automatic sanitization. It should only be used with content you fully trust, such as HTML generated by your own backend, never with raw, untrusted user input.

import { DomSanitizer } from '@angular/platform-browser';

constructor(private sanitizer: DomSanitizer) {}

getSafeHtml(html: string) {
  return this.sanitizer.bypassSecurityTrustHtml(html);
}

Real-world example A blogging platform uses DomSanitizer to safely display rich formatted article content written by trusted staff writers through a content management system, while completely avoiding this approach for anything submitted by anonymous website visitors.

Common follow-ups: What are the different trust contexts DomSanitizer supports, besides HTML?;What happens to a value if you forget to sanitize it when binding to something like innerHTML directly?

Angular Security (XSS Sanitization & CSP);Directives

How would you safely display user generated HTML content, such as a rich text comment, without exposing your app to XSS attacks?

Advanced

You use a trusted sanitization library, like DOMPurify, to clean the HTML first, removing any dangerous scripts or unsafe attributes, before ever marking the result as trusted using Angular's DomSanitizer. This lets you safely support formatted content like bold text or links while blocking anything genuinely harmful.

import DOMPurify from 'dompurify';

getSafeComment(rawHtml: string) {
  const cleanHtml = DOMPurify.sanitize(rawHtml);
  return this.sanitizer.bypassSecurityTrustHtml(cleanHtml);
}

Real-world example A forum allows users to write formatted comments using basic HTML tags like bold and italics, safely cleaning every comment through DOMPurify before marking it as trusted, blocking any hidden malicious script a bad actor might try to sneak in.

Common follow-ups: What specific kinds of malicious content does a library like DOMPurify actually remove?;Is sanitizing on the server, in addition to the client, also recommended for extra safety?

Forms;HTTP Client & Interceptors

What is a Content Security Policy, often shortened to CSP, and how does it add another layer of protection to an Angular app?

Intermediate

A Content Security Policy is a set of rules, usually sent as an HTTP header from the server, that tells the browser exactly which sources of scripts, styles, and other content are allowed to load on a page. Even if an attacker somehow manages to inject a malicious script, a properly configured CSP can prevent that script from actually running or from communicating with an unapproved server.

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com

// This tells the browser to only allow scripts from the app's own origin
// and one specific trusted content delivery network

Real-world example A financial services company configures a strict Content Security Policy on their Angular app's server, ensuring that even if an unexpected vulnerability were exploited, any injected malicious script would be blocked from executing or sending data anywhere.

Common follow-ups: How would you configure a CSP to work correctly with Angular's own generated inline styles?;What tools can help you test whether a CSP is configured correctly?

HTTP Client & Interceptors;Build Environments & Deployment

Why should you avoid storing sensitive information, like an authentication token, directly in an Angular app's local storage?

Beginner

Data kept in local storage remains accessible to any JavaScript running on the page, meaning a successful cross site scripting attack could potentially read and steal that token. Storing sensitive tokens in a properly configured cookie that JavaScript cannot access at all offers stronger protection.

// Less secure, readable by any JavaScript running on the page, including malicious code
localStorage.setItem('authToken', token);

// More secure, the browser sends this cookie automatically, but JavaScript cannot read its value
// (this cookie must be set by the server with the HttpOnly flag)

Real-world example A banking app avoids storing its authentication token in a place JavaScript can read, choosing instead to rely on a secure cookie set by the server, reducing the damage a successful cross site scripting attack could cause.

Common follow-ups: What does the HttpOnly flag on a cookie actually prevent JavaScript from doing?;What other common security practices should an Angular app follow alongside this one?

HTTP Client & Interceptors;Dependency Injection Providers & Injection Tokens