diff --git a/public/docs/ts/latest/guide/security.jade b/public/docs/ts/latest/guide/security.jade
index 47cc4d0bb9..6ede32c090 100644
--- a/public/docs/ts/latest/guide/security.jade
+++ b/public/docs/ts/latest/guide/security.jade
@@ -1,17 +1,17 @@
 block includes
   include ../_util-fns
 :marked
-  This section describes Angular's built-in
-  protections against common web application vulnerabilities and attacks such as cross-site
-  scripting attacks. It does not cover application-level security, such as authentication (_Who is
-  this user?_) or authorization (_What can this user do?_).
+  This page 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?_).
 
   For more information about the attacks and mitigations described below, see [OWASP Guide Project](https://www.owasp.org/index.php/Category:OWASP_Guide_Project).
 
 +ifDocsFor('ts')
   .l-main-section
   :marked
-    # Contents:
+    # Contents
 
     * [Reporting vulnerabilities](#report-issues).
     * [Best practices](#best-practices).
@@ -21,13 +21,12 @@ block includes
     * [Auditing Angular applications](#code-review).
 
 :marked
-  Try the <live-example></live-example> of the code shown in this page.
+  You can run the <live-example></live-example> in Plunker and download the code from there.
 
 .l-main-section
 h2#report-issues Reporting vulnerabilities
 :marked
-  Email us at [security@angular.io](mailto:security@angular.io) to report vulnerabilities in
-  Angular itself.
+  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/).
@@ -36,7 +35,7 @@ h2#report-issues Reporting vulnerabilities
 h2#best-practices Best practices
 :marked
   * **Keep current with the latest Angular library releases.**
-  We regularly update our Angular libraries, and these updates may fix security defects discovered in
+  We regularly update the Angular libraries, and these updates may fix security defects discovered in
   previous versions. Check the Angular [change
   log](https://github.com/angular/angular/blob/master/CHANGELOG.md) for security-related updates.
 
@@ -45,63 +44,65 @@ h2#best-practices Best practices
   important security fixes and enhancements. Instead, share your Angular improvements with the
   community and make a pull request.
 
-  * **Avoid Angular APIs marked in the documentation as “[_Security Risk_](#bypass-security-apis).”**
+  * **Avoid Angular APIs marked in the documentation as “_Security Risk_.”**
+  For more information, see the [Trusting safe values](#bypass-security-apis) section of this page.
 
 .l-main-section
 h2#xss Preventing cross-site scripting (XSS)
 :marked
   [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
-  particular, their login data) or perform actions impersonating the user. This is one of the most
+  particular, login data) or perform actions to impersonate the user. This is one of the most
   common attacks on the web.
 
-  To block XSS attacks, you must prevent malicious code from entering the DOM (Document Object Model). For example, if an
-  attacker can trick you into inserting a `<script>` tag in the DOM, they can run arbitrary code on
-  your website. The attack is not limited to `<script>` tags&mdash;many elements and properties in the
+  To block XSS attacks, you must prevent malicious code from entering the DOM (Document Object Model). For example, if
+  attackers can trick you into inserting a `<script>` tag in the DOM, they can run arbitrary code on
+  your website. The attack isn't limited to `<script>` tags&mdash;many elements and properties in the
   DOM allow code execution, for example, `<img onerror="...">` and `<a href="javascript:...">`. If
   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.
+  is inserted into the DOM from a template, via property, attribute, style, class binding, or interpolation, 
+  Angular sanitizes and escapes untrusted values.
 
   _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
+  (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! Using
-  the [offline template compiler](#offline-template-compiler) is an effective way to prevent these
-  vulnerabilities, also known as _template injection_.
+  template. Never generate template source code by concatenating user input and templates. 
+  To prevent these vulnerabilities, use
+  the [offline template compiler](#offline-template-compiler), also known as _template injection_.
 
   ### Sanitization and security contexts
 
-  _Sanitization_ is the inspection of an untrusted value, turning it into a value that is safe to insert into
-  the DOM. In many cases, sanitization does not change a value at all. Sanitization depends on context:
-  a value that is harmless in CSS is potentially dangerous in a URL.
+  _Sanitization_ is the inspection of an untrusted value, turning it into a value that's safe to insert into
+  the DOM. In many cases, sanitization doesn't change a value at all. Sanitization depends on context:
+  a value that's harmless in CSS is potentially dangerous in a URL.
 
-  Angular defines four security contexts&mdash;HTML, style, URL, and resource URL:
+  Angular defines the following security contexts:
 
-  * **HTML** is used when interpreting a value as HTML, for example, when binding to `innerHtml`
-  * **Style** is used when binding CSS into the `style` property
-  * **URL** is used for URL properties such as `<a href>`
-  * **Resource URL** is a URL that will be loaded and executed as code, for example, in `<script src>`
+  * **HTML** is used when interpreting a value as HTML, for example, when binding to `innerHtml`.
+  * **Style** is used when binding CSS into the `style` property.
+  * **URL** is used for URL properties, such as `<a href>`.
+  * **Resource URL** is a URL that will be loaded and executed as code, for example, in `<script src>`.
 
-  Angular sanitizes untrusted values for the first three items; sanitizing resource URLs is not
+  Angular sanitizes untrusted values for HTML, styles, and URLs; sanitizing resource URLs isn't
   possible because they contain arbitrary code. In development mode, Angular prints a console warning
   when it has to change a value during sanitization.
 
   ### Sanitization example
 
-  The template below binds the value of `htmlSnippet`, once by interpolating it into an element's
+  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:
 
 +makeExample('src/app/inner-html-binding.component.html')
 
 :marked
-  Interpolated content is always escaped&mdash;the HTML is not interpreted, and the browser displays
+  Interpolated content is always escaped&mdash;the HTML isn't interpreted and the browser displays
   angle brackets in the element's text content.
 
-  For the HTML to be interpreted, you must bind it to an HTML property such as `innerHTML`. But binding
+  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 `<script>` tag is executed:
 
@@ -110,7 +111,7 @@ h2#xss Preventing cross-site scripting (XSS)
 block html-sanitization
   :marked
     Angular recognizes the value as unsafe and automatically sanitizes it, which removes the `<script>`
-    tag but keeps safe content such as the text content of the `<script>` tag, or the `<b>` element.
+    tag but keeps safe content such as the text content of the `<script>` tag and the `<b>` element.
 
   figure.image-display
       img(src='/resources/images/devguide/security/binding-inner-html.png'
@@ -119,25 +120,28 @@ block html-sanitization
 :marked
   ### Avoid direct use of the DOM APIs
 
-  The built-in browser DOM APIs do not automatically protect you from security vulnerabilities.
+  The built-in browser DOM APIs don't automatically protect you from security vulnerabilities.
   For example, `document`, the node available through `ElementRef`, and many third-party APIs
   contain unsafe methods. Avoid directly interacting with the DOM and instead use Angular
   templates where possible.
 
   ### Content security policy
 
-  [Content Security Policy (CSP)](http://www.html5rocks.com/en/tutorials/security/content-security-policy/) is a defense-in-depth
+  Content Security Policy (CSP) is a defense-in-depth
   technique to prevent XSS. To enable CSP, configure your web server to return an appropriate
-  `Content-Security-Policy` HTTP header.
+  `Content-Security-Policy` HTTP header. Read more about content security policy at 
+  [An Introduction to Content Security Policy](http://www.html5rocks.com/en/tutorials/security/content-security-policy/)
+  on the HTML5Rocks website.
 
   <a id="offline-template-compiler"></a>
   ### Use the offline template compiler
 
   The offline template compiler prevents a whole class of vulnerabilities called template injection,
-  and also greatly improves application performance. Use the offline template compiler in production
-  deployments; do not dynamically generate templates. Angular trusts template code, so generating
-  templates, in particular templates containing user data, circumvents Angular's built-in protections. For information about how to dynamically construct forms in a safe way, see 
-  [Dynamic Forms Cookbook](../cookbook/dynamic-form.html).
+  and greatly improves application performance. Use the offline template compiler in production
+  deployments; don't dynamically generate templates. Angular trusts template code, so generating
+  templates, in particular templates containing user data, circumvents Angular's built-in protections. 
+  For information about dynamically constructing forms in a safe way, see the 
+  [Dynamic Forms](../cookbook/dynamic-form.html) cookbook page.
 
   ### Server-side XSS protection
 
@@ -145,7 +149,7 @@ block html-sanitization
   Angular application is the same as injecting executable code into the
   application: it gives the attacker full control over the application. To prevent this, 
   use a templating language that automatically escapes values to prevent XSS vulnerabilities on
-  the server. Do not generate Angular templates on the server side using a templating language; doing this
+  the server. Don't generate Angular templates on the server side using a templating language; doing this
   carries a high risk of introducing template-injection vulnerabilities.
 
 block bypass-security-apis
@@ -155,11 +159,11 @@ block bypass-security-apis
     Sometimes applications genuinely need to include executable code, display an `<iframe>` from some
     URL, or construct potentially dangerous URLs. To prevent automatic sanitization in any of these 
     situations, you can tell Angular that you inspected a value, checked how it was generated, and made 
-    sure it will always be secure. But **be careful**! If you trust a value that might be malicious, you 
+    sure it will always be secure. But *be careful*. If you trust a value that might be malicious, you 
     are introducing a security vulnerability into your application. If in doubt, find a professional 
     security reviewer.
 
-    You can mark a value as trusted by injecting `DomSanitizer` and calling one of the
+    To mark a value as trusted, inject `DomSanitizer` and call one of the
     following methods:
 
     * `bypassSecurityTrustHtml`
@@ -168,7 +172,7 @@ block bypass-security-apis
     * `bypassSecurityTrustUrl`
     * `bypassSecurityTrustResourceUrl`
 
-    Remember, whether a value is safe depends on context, so you need to choose the right context for
+    Remember, whether a value is safe depends on context, so choose the right context for
     your intended use of the value. Imagine that the following template needs to bind a URL to a
     `javascript:alert(...)` call:
 
@@ -177,7 +181,7 @@ block bypass-security-apis
   :marked
     Normally, Angular automatically sanitizes the URL, disables the dangerous code, and
     in development mode, logs this action to the console. To prevent
-    this, you can mark the URL value as a trusted URL using the `bypassSecurityTrustUrl` call:
+    this, mark the URL value as a trusted URL using the `bypassSecurityTrustUrl` call:
 
   +makeExcerpt('src/app/bypass-security.component.ts ()', 'trust-url')
 
@@ -187,11 +191,11 @@ block bypass-security-apis
 
   :marked
     If you need to convert user input into a trusted value, use a
-    controller method. The template below allows users to enter a YouTube video ID and load the
+    controller method. The following template allows users to enter a YouTube video ID and load the
     corresponding video in an `<iframe>`. The `<iframe src>` attribute is a resource URL security
     context, because an untrusted source can, for example, smuggle in file downloads that unsuspecting users 
-    could execute. So call a method on the controller to construct a trusted video URL, that causes
-    Angular to then allow binding into `<iframe src>`:
+    could execute. So call a method on the controller to construct a trusted video URL, which causes
+    Angular to allow binding into `<iframe src>`:
 
   +makeExcerpt('src/app/bypass-security.component.html', 'iframe')
   +makeExcerpt('src/app/bypass-security.component.ts ()', 'trust-video-url')
@@ -202,23 +206,23 @@ block http
   :marked
     Angular has built-in support to help prevent two common HTTP vulnerabilities, cross-site request
     forgery (CSRF or XSRF) and cross-site script inclusion (XSSI). Both of these must be mitigated primarily 
-    on the server side, but Angular ships helpers to make integration on the client side easier.
+    on the server side, but Angular provides helpers to make integration on the client side easier.
 
   h3#xsrf Cross-site request forgery
   :marked
     In a cross-site request forgery (CSRF or XSRF), an attacker tricks the user into visiting
-    a different web page (e.g. `evil.com`) with malignant code that secretly sends a malicious request 
-    to your application's web server (e.g. `example-bank.com`). 
+    a different web page (such as `evil.com`) with malignant code that secretly sends a malicious request 
+    to the application's web server (such as `example-bank.com`). 
 
     Assume the user is logged into the application at `example-bank.com`.
-    The user opens an email and clicks a link to `evil.com` which opens in a new tab.
+    The user opens an email and clicks a link to `evil.com`, which opens in a new tab.
 
     The `evil.com` page immediately sends a malicious request to `example-bank.com`.
     Perhaps it's a request to transfer money from the user's account to the attacker's account.
     The browser automatically sends the `example-bank.com` cookies (including the authentication cookie) with this request.
 
-    The `example-bank.com` server, if it lacks XSRF protection, can't tell the difference between a legitimate request from the application
-    and the forged request from `evil.com`.
+    If the `example-bank.com` server lacks XSRF protection, it can't tell the difference between a legitimate 
+    request from the application and the forged request from `evil.com`.
 
     To prevent this, the application must ensure that a user request originates from the real
     application, not from a different site. 
@@ -243,7 +247,7 @@ block http
     includes a matching `XSRF-TOKEN` cookie and `X-XSRF-TOKEN` header.
 
     XSRF/CSRF tokens should be unique per user and session, have a large random value generated by a
-    cryptographically secure random number generator, and should expire in a day or two.
+    cryptographically secure random number generator, and expire in a day or two.
 
     Your server may use a different cookie or header name for this purpose.
     An Angular application can customize cookie and header names by providing its own `CookieXSRFStrategy` values.
@@ -282,7 +286,7 @@ block http
     post](https://security.googleblog.com/2011/05/website-security-for-webmasters.html).
 
 .l-main-section
-h2#code-review Auditing angular applications
+h2#code-review Auditing Angular applications
 :marked
   Angular applications must follow the same security principles as regular web applications, and
   must be audited as such. Angular-specific APIs that should be audited in a security review,