11block includes
22 include ../_util-fns
33:marked
4+ # Security
45 Web application security has many aspects. This documentation describes Angular's built in
56 protections against common web application vulnerabilities and attacks, such as Cross Site
67 Scripting Attacks. It does not cover application level security, such as authentication (_Who is
@@ -66,6 +67,13 @@ h2#xss Preventing Cross-Site Scripting (XSS)
6667 is inserted into the DOM from a template, via property, attribute, style, or class binding, or via
6768 interpolation, Angular will sanitize and escape untrusted values.
6869
70+ **Angular templates are the same as executable code**: HTML, attributes, and binding expressions
71+ (but not the values bound!) in templates are trusted to be safe. That means applications must
72+ prevent potentially attacker controlled values from ever making it into the source code of a
73+ template. Never generate template source code by concatenating user input and templates! Using
74+ the [offline template compiler](#offline-template-compiler) is an effective way to prevent these
75+ vulnerabilities, also known as template injection.
76+
6977 ### Sanitization and security contexts
7078
7179 Sanitization inspects an untrusted value and turns it into a value that is safe to insert into
@@ -114,11 +122,10 @@ figure.image-display
114122
115123 ### Content Security Policy
116124
117- A [Content Security Policy (CSP)](https://developer.mozilla.org/en-
118- US/docs/Web/Security/CSP/Introducing_Content_Security_Policy) is a defense-in-depth technique to
119- prevent XSS. To enable CSP, configure your web server to return an appropriate
120- `Content-Security-Policy` HTTP header. Learn more at
121- [OWASP](https://www.owasp.org/index.php/Content_Security_Policy).
125+ A [Content Security Policy (CSP)]
126+ (http://www.html5rocks.com/en/tutorials/security/content-security-policy/) is a defense-in-depth
127+ technique to prevent XSS. To enable CSP, configure your web server to return an appropriate
128+ `Content-Security-Policy` HTTP header.
122129
123130 <a id="offline-template-compiler"></a>
124131 ### Use the Offline Template Compiler
@@ -132,11 +139,12 @@ figure.image-display
132139
133140 ### Server side XSS protection
134141
135- HTML constructed on the server is vulnerable to injection attacks. When generating server side
136- HTML, e.g. for the initial page load of the Angular application, make sure to use a templating
137- language that automatically escapes values to prevent XSS vulnerabilities on the server. Do not
138- generate Angular templates on the server side using a templating language, this carries a high
139- risk of introducing template injection vulnerabilities.
142+ HTML constructed on the server is vulnerable to injection attacks. Injecting template code into an
143+ Angular application is the same as injecting executable code (e.g. JavaScript) into the
144+ application; it gives the attacker full control over the application. To prevent this, make sure
145+ to use a templating language that automatically escapes values to prevent XSS vulnerabilities on
146+ the server. Do not generate Angular templates on the server side using a templating language, this
147+ carries a high risk of introducing template injection vulnerabilities.
140148
141149.l-main-section
142150h2#bypass-security-apis Trusting Safe Values
@@ -173,10 +181,10 @@ figure.image-display
173181:marked
174182 If we need to convert user input into a trusted value, it can be convenient to do so in a
175183 controller method. The template below allows users to enter a YouTube video ID, and load the
176- corresponding video in an `<iframe>`. `<iframe src>` is a resource URL, because an untrusted
177- source can e.g. smuggle in file downloads that unsuspecting users would execute. So we call a
178- method on the controller to construct a new, trusted video URL, which is then bound to the
179- `<iframe src>`.
184+ corresponding video in an `<iframe>`. The `<iframe src>` attribute is a resource URL security
185+ context, because an untrusted source can e.g. smuggle in file downloads that unsuspecting users
186+ would execute. So we call a method on the controller to construct a trusted video URL, which
187+ Angular then allows binding into `<iframe src>`.
180188
181189+ makeExample('security/ts/app/bypass-security.component.html' , 'iframe-videoid' )( format ="." )
182190+ makeExample('security/ts/app/bypass-security.component.ts' , 'trust-video-url' )( format ="." )
@@ -213,7 +221,9 @@ h3#xsrf Cross-site Request Forgery (XSRF)
213221
214222 Angular applications can customize cookie and header names by binding their own
215223 `CookieXSRFStrategy` value, or implement an entirely custom `XSRFStrategy` by providing a custom
216- binding for that type.
224+ binding for that type, by adding
225+ `provide(XSRFStrategy, {useValue: new CookieXSRFStrategy('myCookieName', 'My-Header-Name')})` or
226+ `provide(XSRFStrategy, {useClass: MyXSRFStrategy})` to your providers list.
217227
218228 Learn about Cross Site Request Forgery (XSRF) at the Open Web Application Security Project (OWASP)
219229 [here](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29) and
0 commit comments