Tweaking the "insecure CSP" error message to clarify that both 'script-src' and 'object-src' must b…

chrome/common/extensions/docs/server2/templates/articles/contentSecurityPolicy.html

 <h1>Content Security Policy (CSP)</h1>
 
 
 <p>
   In order to mitigate a large class of potental cross-site scripting issues,
   Chrome's extension system has incorporated the general concept of
   <a href="http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html">
     <strong>Content Security Policy (CSP)</strong>
   </a>. This introduces some fairly strict policies that will make extensions
   more secure by default, and provides you with the ability to create and
@@ skipping 302 matching lines @@
 
 <h3 id="relaxing-eval">Evaluated JavaScript</h3>
 
 <p>
   The policy against <code>eval()</code> and its relatives like
   <code>setTimeout(String)</code>, <code>setInterval(String)</code>, and
   <code>new Function(String)</code> can be relaxed by adding
   <code>'unsafe-eval'</code> to your policy:
 </p>
 
-<pre>"content_security_policy": "script-src 'self' 'unsafe-eval'"</pre>
+<pre>"content_security_policy": "script-src 'self' 'unsafe-eval'; object-src 'self'"</pre>
 
 <p>
   However, we strongly recommend against doing this. These functions are
   notorious XSS attack vectors.
 </p>
 
 <h2 id="tightening">Tightening the default policy</h2>
 
 <p>
   You may, of course, tighten this policy to whatever extent your extension
   allows in order to increase security at the expense of convenience. To specify
   that your extension can only load resources of <em>any</em> type (images, etc)
   from its own package, for example, a policy of <code>default-src 'self'</code>
   would be appropriate. The <a href="samples.html#mappy">Mappy</a> sample
   extension is a good example of an extension that's been locked down above and
   beyond the defaults.
 </p>