From b3b85091cad0cb407c760788982ba63f08b5f8b2 Mon Sep 17 00:00:00 2001 From: David Shevitz Date: Tue, 15 Dec 2020 23:29:23 +0000 Subject: [PATCH] docs: Update security.md to include Trusted Types (#40142) PR Close #40142 --- aio/content/guide/security.md | 210 ++++++++++++++++------------------ 1 file changed, 100 insertions(+), 110 deletions(-) diff --git a/aio/content/guide/security.md b/aio/content/guide/security.md index 1d7127c5c1..47f6fe3222 100644 --- a/aio/content/guide/security.md +++ b/aio/content/guide/security.md @@ -1,34 +1,29 @@ # Security -This page describes Angular's built-in +This topic describes Angular's built-in protections against common web-application vulnerabilities and attacks such as cross-site -scripting attacks. It doesn't cover application-level security, such as authentication (_Who is -this user?_) and authorization (_What can this user do?_). +scripting attacks. It doesn't cover application-level security, such as authentication and authorization. For more information about the attacks and mitigations described below, see [OWASP Guide Project](https://www.owasp.org/index.php/Category:OWASP_Guide_Project). You can run the in Stackblitz and download the code from there. +
- -

- Reporting vulnerabilities -

- - +{@a report-issues} +
Reporting vulnerabilities
To report vulnerabilities in Angular itself, email us at [security@angular.io](mailto:security@angular.io). For more information about how Google handles security issues, see [Google's security philosophy](https://www.google.com/about/appsecurity/). +
+
-

- Best practices -

- - +{@a best-practices} +
Best practices
* **Keep current with the latest Angular library releases.** We regularly update the Angular libraries, and these updates may fix security defects discovered in @@ -43,13 +38,9 @@ community and make a pull request. * **Avoid Angular APIs marked in the documentation as “_Security Risk_.”** For more information, see the [Trusting safe values](guide/security#bypass-security-apis) section of this page. +
- -

- Preventing cross-site scripting (XSS) -

- - +## Preventing cross-site scripting (XSS) [Cross-site scripting (XSS)](https://en.wikipedia.org/wiki/Cross-site_scripting) enables attackers to inject malicious code into web pages. Such code can then, for example, steal user data (in @@ -64,16 +55,11 @@ attacker-controlled data enters the DOM, expect security vulnerabilities. ### Angular’s cross-site scripting security model -To systematically block XSS bugs, Angular treats all values as untrusted by default. When a value -is inserted into the DOM from a template, via property, attribute, style, class binding, or interpolation, -Angular sanitizes and escapes untrusted values. +To systematically block XSS bugs, Angular treats all values as untrusted by default. When a value is inserted into the DOM from a template binding, or interpolation, Angular sanitizes and escapes untrusted values. If a value was already sanitized outside of Angular and is considered safe, you can communicate this to Angular by marking the [value as trusted](#bypass-security-apis). -_Angular templates are the same as executable code_: HTML, attributes, and binding expressions -(but not the values bound) in templates are trusted to be safe. This means that applications must -prevent values that an attacker can control from ever making it into the source code of a -template. Never generate template source code by concatenating user input and templates. -To prevent these vulnerabilities, use -the [offline template compiler](guide/security#offline-template-compiler), also known as _template injection_. +Unlike values to be used for rendering, Angular templates are considered trusted by default, and should be treated as executable code. Never generate templates by concatenating user input and template syntax. Doing this would enable attackers to [inject arbitrary code](https://en.wikipedia.org/wiki/Code_injection) into your application. To prevent these vulnerabilities, always use the default [AOT template compiler](/guide/security#offline-template-compiler) in production deployments. + +An additional layer of protection can be provided through the use of Content security policy and Trusted Types. These web platform features operate at the DOM level which is the most effective place to prevent XSS issues because they can't be bypassed using other, lower-level APIs. For this reason, we strongly encourage developers to take advantage of these features by configuring the [content security policy](#content-security-policy) for their application and enabling [trusted types enforcement](#trusted-types). ### Sanitization and security contexts @@ -97,35 +83,26 @@ when it has to change a value during sanitization. The following template binds the value of `htmlSnippet`, once by interpolating it into an element's content, and once by binding it to the `innerHTML` property of an element: - - - Interpolated content is always escaped—the HTML isn't interpreted and the browser displays angle brackets in the element's text content. For the HTML to be interpreted, bind it to an HTML property such as `innerHTML`. But binding a value that an attacker might control into `innerHTML` normally causes an XSS -vulnerability. For example, code contained in a `