Add missing apostrophes to the CSP article (#1438)

* Trim trailing whitespaces

* Add missing apostrophes to the CSP article

content/tutorials/security/content-security-policy/en/index.html

@@ -3,7 +3,7 @@
 {% block head %}
 <script>
 function customPrettyPrintLanguage() {
-  PR['registerLangHandler'](                                                                                                       
+  PR['registerLangHandler'](
     PR['createSimpleLexer'](
       [],
       [
@@ -62,13 +62,13 @@ <h3 id="policy-applies-to-a-wide-variety-of-resources">Policy applies to a wide
   <li><strong><code>connect-src</code></strong> limits the origins to which you can connect (via XHR, WebSockets, and EventSource).</li>
   <li><strong><code>font-src</code></strong> specifies the origins that can serve web fonts. Google&#8217;s Web Fonts could be enabled via <code>font-src https://themes.googleusercontent.com</code></li>
   <li><strong><code>form-action</code></strong> lists valid endpoints for submission from <code>&lt;form&gt;</code> tags.</li>
-  <li><strong><code>frame-ancestors</code></strong>  specifies the sources that can embed the current page. This directive applies to <code>&lt;frame&gt;</code>, <code>&lt;iframe&gt;</code>, <code>&lt;embed&gt;</code>, and <code>&lt;applet&gt;</code> tags. This directive cant be used in <code>&lt;meta&gt;</code> tags and applies only to non-HTML resources.</li>
+  <li><strong><code>frame-ancestors</code></strong> specifies the sources that can embed the current page. This directive applies to <code>&lt;frame&gt;</code>, <code>&lt;iframe&gt;</code>, <code>&lt;embed&gt;</code>, and <code>&lt;applet&gt;</code> tags. This directive can&#8217;t be used in <code>&lt;meta&gt;</code> tags and applies only to non-HTML resources.</li>
   <li><strong><code>frame-src</code></strong> deprecated. Use <strong><code>child-src</code></strong> instead.</li>
   <li><strong><code>img-src</code></strong> defines the origins from which images can be loaded.</li>
   <li><strong><code>media-src</code></strong> restricts the origins allowed to deliver video and audio.</li>
   <li><strong><code>object-src</code></strong> allows control over Flash and other plugins.</li>
   <li><strong><code>plugin-types</code></strong> limits the kinds of plugins a page may invoke.</li>
-  <li><strong><code>report-uri</code></strong> specifies a URL where a browser will send reports when a content security policy is violated. This directive cant be used in <code>&lt;meta&gt;</code> tags.</li>
+  <li><strong><code>report-uri</code></strong> specifies a URL where a browser will send reports when a content security policy is violated. This directive can&#8217;t be used in <code>&lt;meta&gt;</code> tags.</li>
   <li><strong><code>style-src</code></strong> is <code>script-src</code>&#8217;s counterpart for stylesheets.</li>
   <li><strong><code>upgrade-insecure-requests</code></strong> Instructs user agents to rewrite URL schemes, changing HTTP to HTTPS. This directive is for web sites with large numbers of old URLs that need to be rewritten.</li>
 </ul>
@@ -125,7 +125,7 @@ <h3 id="the-meta-tag">The meta Tag</h3>
 
 <p>CSPs preferred delivery mechanism is an HTTP header. It can be useful, however, to set a policy on a page directly in the markup. Do that using a meta tag with an http-equiv attribute:</p>
 
-<pre class="prettyprint"><code>&lt;meta http-equiv="Content-Security-Policy" content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'"&gt; 
+<pre class="prettyprint"><code>&lt;meta http-equiv="Content-Security-Policy" content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'"&gt;
 </code></pre>
 
 <p>This can&#8217;t be used for frame-ancestors, report-uri, or sandbox.</p>
@@ -173,13 +173,13 @@ <h3 id="if-you-absolutely-must-use-it">If You Absolutely Must Use It&#8230;</h3>
 <p>To use a nonce, give your script tag a nonce attribute. Its value must match one in the list of trusted sources. For example:</p>
 
 <pre class="prettyprint"><code>&lt;script nonce=EDNnf03nceIOfn39fn3e9h3sdfa&gt;
-  //Some inline code I cant remove yet, but need to asap.
+  // Some inline code I can't remove yet, but need to asap.
 &lt;/script&gt;
 </code></pre>
 
 <p>Now, add the nonce to your script-src directive appended to the nonce- keyword.</p>
 
-<pre class="prettyprint lang-csp"><code>Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa' 
+<pre class="prettyprint lang-csp"><code>Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'
 </code></pre>
 
 <p>Remember that nonces must be regenerated for every page request and they must be unguessable.</p>
@@ -304,7 +304,7 @@ <h3 id="use-case-3-ssl-only">Use Case #3: SSL Only</h3>
 
 <h2 id="the-future">The Future</h2>
 
-<p>Content Security Policy Level 2 is a <a href="http://www.w3.org/TR/CSP2/">Candidate Recommendation</a>. The W3Cs Web Application Security Working Group isnt lounging around, patting itself on the back; work has already begun on the specifications next iteration. The next version is already under active development.</p>
+<p>Content Security Policy Level 2 is a <a href="http://www.w3.org/TR/CSP2/">Candidate Recommendation</a>. The W3Cs Web Application Security Working Group isn&#8217;t lounging around, patting itself on the back; work has already begun on the specifications next iteration. The next version is already under active development.</p>
 
 <p>If you&#8217;re interested in the discussion around these upcoming features, <a href="http://lists.w3.org/Archives/Public/public-webappsec/">skim the public-webappsec@ mailing list archives</a>, or join in yourself.</p>
 

content/tutorials/security/content-security-policy/en/index.markdown

@@ -1,6 +1,6 @@
-The web's security model is rooted in the [_same origin policy_](http://en.wikipedia.org/wiki/Same_origin_policy). Code from `https://mybank.com` should only have access to `https://mybank.com`'s data, and `https://evil.example.com` should certainly never be allowed access. Each origin is kept isolated from the rest of the web, giving developers a safe sandbox in which to build and play. In theory, this is perfectly brilliant. In practice, attackers have found clever ways to subvert the system. 
+The web's security model is rooted in the [_same origin policy_](http://en.wikipedia.org/wiki/Same_origin_policy). Code from `https://mybank.com` should only have access to `https://mybank.com`'s data, and `https://evil.example.com` should certainly never be allowed access. Each origin is kept isolated from the rest of the web, giving developers a safe sandbox in which to build and play. In theory, this is perfectly brilliant. In practice, attackers have found clever ways to subvert the system.
 
-[Cross-site scripting (XSS)](http://en.wikipedia.org/wiki/Cross-site_scripting) attacks, for example, bypass the same origin policy by tricking a site into delivering malicious code along with the intended content. This is a huge problem, as browsers trust all of the code that shows up on a page as being legitimately part of that page's security origin. The [XSS Cheat Sheet](http://ha.ckers.org/xss.html) is an old but representative cross-section of the methods an attacker might use to violate this trust by injecting malicious code. If an attacker successfully injects _any_ code at all, it's pretty much game over: user session data is compromised and information that should be kept secret is exfiltrated to The Bad Guys. We'd obviously like to prevent that if possible. 
+[Cross-site scripting (XSS)](http://en.wikipedia.org/wiki/Cross-site_scripting) attacks, for example, bypass the same origin policy by tricking a site into delivering malicious code along with the intended content. This is a huge problem, as browsers trust all of the code that shows up on a page as being legitimately part of that page's security origin. The [XSS Cheat Sheet](http://ha.ckers.org/xss.html) is an old but representative cross-section of the methods an attacker might use to violate this trust by injecting malicious code. If an attacker successfully injects _any_ code at all, it's pretty much game over: user session data is compromised and information that should be kept secret is exfiltrated to The Bad Guys. We'd obviously like to prevent that if possible.
 
 This tutorial highlights one promising new defense that can significantly reduce the risk and impact of XSS attacks in modern browsers: Content Security Policy (CSP).
 
@@ -29,13 +29,13 @@ While script resources are the most obvious security risks, CSP provides a rich
 * **`connect-src`** limits the origins to which you can connect (via XHR, WebSockets, and EventSource).
 * **`font-src`** specifies the origins that can serve web fonts. Google's Web Fonts could be enabled via `font-src https://themes.googleusercontent.com`
 * **`form-action`** lists valid endpoints for submission from `<form>` tags.
-* **`frame-ancestors`**  specifies the sources that can embed the current page. This directive applies to `<frame>`, `<iframe>`, `<embed>`, and `<applet>` tags. This directive cant be used in `<meta>` tags and applies only to non-HTML resources.
+* **`frame-ancestors`** specifies the sources that can embed the current page. This directive applies to `<frame>`, `<iframe>`, `<embed>`, and `<applet>` tags. This directive can't be used in `<meta>` tags and applies only to non-HTML resources.
 * **`frame-src`** deprecated. Use **`child-src`** instead.
 * **`img-src`** defines the origins from which images can be loaded.
 * **`media-src`** restricts the origins allowed to deliver video and audio.
 * **`object-src`** allows control over Flash and other plugins.
 * **`plugin-types`** limits the kinds of plugins a page may invoke.
-* **`report-uri`** specifies a URL where a browser will send reports when a content security policy is violated. This directive cant be used in `<meta>` tags.
+* **`report-uri`** specifies a URL where a browser will send reports when a content security policy is violated. This directive can't be used in `<meta>` tags.
 * **`style-src`** is `script-src`'s counterpart for stylesheets.
 * **`upgrade-insecure-requests`** Instructs user agents to rewrite URL schemes, changing HTTP to HTTPS. This directive is for web sites with large numbers of old URL's that need to be rewritten.
 
@@ -85,7 +85,7 @@ There's one more directive worth talking about: **`sandbox`**. It's a bit differ
 
 CSPs preferred delivery mechanism is an HTTP header. It can be useful, however, to set a policy on a page directly in the markup. Do that using a meta tag with an http-equiv attribute:
 
-    <meta http-equiv="Content-Security-Policy" content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'"> 
+    <meta http-equiv="Content-Security-Policy" content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'">
 
 This can't be used for frame-ancestors, report-uri, or sandbox.
 
@@ -117,25 +117,25 @@ to something more like:
               .addEventListener('click', doAmazingThings);
     });
 
-The rewritten code has a number of advantages above and beyond working well with CSP; it's already best practice, regardless of your use of CSP. Inline JavaScript mixes structure and behavior in exactly the way you shouldn't. External resources are easier for browsers to cache, more understandable for developers, and conducive to compilation and minification. You'll write better code if you do the work to move code into external resources. 
+The rewritten code has a number of advantages above and beyond working well with CSP; it's already best practice, regardless of your use of CSP. Inline JavaScript mixes structure and behavior in exactly the way you shouldn't. External resources are easier for browsers to cache, more understandable for developers, and conducive to compilation and minification. You'll write better code if you do the work to move code into external resources.
 
-Inline style is treated in the same way: both the `style` attribute and `style` tags should be consolidated into external stylesheets to protect against a variety of [surprisingly clever](http://scarybeastsecurity.blogspot.com/2009/12/generic-cross-browser-cross-domain.html) data exfiltration methods that CSS enables. 
+Inline style is treated in the same way: both the `style` attribute and `style` tags should be consolidated into external stylesheets to protect against a variety of [surprisingly clever](http://scarybeastsecurity.blogspot.com/2009/12/generic-cross-browser-cross-domain.html) data exfiltration methods that CSS enables.
 
 If you really, absolutely must have inline script and style, you can enable it by adding `'unsafe-inline'` as an allowed source in a `script-src` or `style-src` directive. You can also use a nonce or a has (see below). But please don't. Banning inline script is the biggest security win CSP provides, and banning inline style likewise hardens your application. It's a little bit of effort up front to ensure that things work correctly after moving all the code out-of-line, but that's a tradeoff that's well worth making.
 
 ### If You Absolutely Must Use It...
 
-CSP Level 2 offers backward compatibility for inline scripts by allowing you to whitelist specific inline scripts using either a cryptographic nonce (number used once) or a hash. Although this may be cumbersome in practice, it is useful in a pinch. 
+CSP Level 2 offers backward compatibility for inline scripts by allowing you to whitelist specific inline scripts using either a cryptographic nonce (number used once) or a hash. Although this may be cumbersome in practice, it is useful in a pinch.
 
 To use a nonce, give your script tag a nonce attribute. Its value must match one in the list of trusted sources. For example:
 
     <script nonce=EDNnf03nceIOfn39fn3e9h3sdfa>
-      //Some inline code I cant remove yet, but need to asap.
+      // Some inline code I can't remove yet, but need to asap.
     </script>
 
 Now, add the nonce to your script-src directive appended to the nonce- keyword.
 
-    Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa' 
+    Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'
 
 Remember that nonces must be regenerated for every page request and they must be unguessable.
 
@@ -171,7 +171,7 @@ This has more than a few impacts on the way you build applications:
 *   Avoid inline templating at runtime: Many templating libraries use `new Function()` liberally to speed up template generation at runtime. It's a nifty application of dynamic programming, but comes at the risk of evaluating malicious text. Some frameworks support CSP out of the box, falling back to a robust parser in the absence of `eval`; [AngularJS's ng-csp directive](http://docs.angularjs.org/api/angular.module.ng.$compileProvider.directive.ngCsp) is a good example of this.
 
 You're even better off, however, if your templating language of choice offers precompilation ([Handlebars does](http://handlebarsjs.com/precompilation.html), for instance). Precompiling your templates can make the user experience even faster than the fastest runtime implementation, and it's safer too. Win, win!
-If eval and its text-to-JavaScript brethren are completely essential to your application, you can enable them by adding `'unsafe-eval'` as an allowed source in a `script-src` directive. But, again, please don't. Banning the ability to execute strings makes it much more difficult for an attacker to execute unauthorized code on your site. 
+If eval and its text-to-JavaScript brethren are completely essential to your application, you can enable them by adding `'unsafe-eval'` as an allowed source in a `script-src` directive. But, again, please don't. Banning the ability to execute strings makes it much more difficult for an attacker to execute unauthorized code on your site.
 
 ## Reporting
 
@@ -239,6 +239,6 @@ Even though `https:` was specified in `default-src`, the script and style direct
 
 ## The Future
 
-Content Security Policy Level 2 is a [Candidate Recommendation](http://www.w3.org/TR/CSP2/). The W3Cs Web Application Security Working Group isnt lounging around, patting itself on the back; work has already begun on the specifications next iteration. The next version is already under active development.
+Content Security Policy Level 2 is a [Candidate Recommendation](http://www.w3.org/TR/CSP2/). The W3Cs Web Application Security Working Group isn't lounging around, patting itself on the back; work has already begun on the specifications next iteration. The next version is already under active development.
 
 If you're interested in the discussion around these upcoming features, [skim the public-webappsec@ mailing list archives](http://lists.w3.org/Archives/Public/public-webappsec/), or join in yourself.