1
1
block includes
2
2
include ../_util-fns
3
3
:marked
4
+ # Security
4
5
Web application security has many aspects. This documentation describes Angular's built in
5
6
protections against common web application vulnerabilities and attacks, such as Cross Site
6
7
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)
66
67
is inserted into the DOM from a template, via property, attribute, style, or class binding, or via
67
68
interpolation, Angular will sanitize and escape untrusted values.
68
69
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
+
69
77
### Sanitization and security contexts
70
78
71
79
Sanitization inspects an untrusted value and turns it into a value that is safe to insert into
@@ -114,11 +122,10 @@ figure.image-display
114
122
115
123
### Content Security Policy
116
124
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.
122
129
123
130
<a id="offline-template-compiler"></a>
124
131
### Use the Offline Template Compiler
@@ -132,11 +139,12 @@ figure.image-display
132
139
133
140
### Server side XSS protection
134
141
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.
140
148
141
149
.l-main-section
142
150
h2#bypass-security-apis Trusting Safe Values
@@ -173,10 +181,10 @@ figure.image-display
173
181
:marked
174
182
If we need to convert user input into a trusted value, it can be convenient to do so in a
175
183
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>`.
180
188
181
189
+ makeExample('security/ts/app/bypass-security.component.html' , 'iframe-videoid' )( format ="." )
182
190
+ makeExample('security/ts/app/bypass-security.component.ts' , 'trust-video-url' )( format ="." )
@@ -213,7 +221,9 @@ h3#xsrf Cross-site Request Forgery (XSRF)
213
221
214
222
Angular applications can customize cookie and header names by binding their own
215
223
`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.
217
227
218
228
Learn about Cross Site Request Forgery (XSRF) at the Open Web Application Security Project (OWASP)
219
229
[here](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29) and
0 commit comments