Skip to content
This repository was archived by the owner on Dec 4, 2017. It is now read-only.

Commit 3905be8

Browse files
mprobstnaomiblack
authored andcommitted
docs(security): Clarify template injection.
Also link to html5rocks docs on CSP.
1 parent 1149816 commit 3905be8

File tree

1 file changed

+25
-15
lines changed

1 file changed

+25
-15
lines changed

public/docs/ts/latest/guide/security.jade

+25-15
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,7 @@
11
block 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
142150
h2#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

Comments
 (0)