Disallow non-subdomain wildcards in the extension's CSP

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

 <h1>Content Security Policy (CSP)</h1>
 
 
 <p>
   In order to mitigate a large class of potential 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 255 matching lines @@
 
 <p>
   If you have a need for some external JavaScript or object
   resources, you can relax the policy to a limited extent by whitelisting
   secure origins from which scripts should be accepted. We want to ensure that
   executable resources loaded with an extension's elevated permissions are
   exactly the resources you expect, and haven't been replaced by an active
   network attacker. As <a
   href="http://en.wikipedia.org/wiki/Man-in-the-middle_attack">man-in-the-middle
   attacks</a> are both trivial and undetectable over HTTP, those origins will
-  not be accepted. Currently, we allow whitelisting origins with the following
-  schemes: <code>HTTPS</code>, <code>chrome-extension</code>, and
-  <code>chrome-extension-resource</code>.
+  not be accepted.
 </p>
 
 <p>
+  Currently, we allow whitelisting origins with the following schemes:
+  <code>blob</code>, <code>filesystem</code>, <code>https</code>,
+  <code>chrome-extension</code>, and <code>chrome-extension-resource</code>.
+  The host part of the origin must explicitly be specified for the
+  <code>https</code> and <code>chrome-extension</code> schemes.
+  Generic wildcards such as <code>https:</code>, <code>https://*</code> and
+  <code>https://*.com</code> are not allowed; subdomain wildcards such as
+  <code>https://*.example.com</code> are allowed.
+</p>
+
+<p>
   To ease development, we're also allowing the whitelisting of resources loaded
   over HTTP from servers on your local machine. You may whitelist script and
   object sources on any port of either <code>http://127.0.0.1</code> or
   <code>http://localhost</code>.
 </p>
 
 <p class="note">
   The restriction against resources loaded over HTTP applies only to those
   resources which are directly executed. You're still free, for example, to
   make XMLHTTPRequest connections to any origin you like; the default policy
@@ skipping 136 matching lines @@
   within the script will be regulated by the page's CSP.
 </p>
 
 <p>
   Thus, depending on how you write DOM injected scripts in your extension,
   changes to the page's CSP may affect the behavior of your extension. Since
   content scripts are <em>not</em> affected by the page's CSP, this a great
   reason to put as much behavior as possible of your extension into the content
   script rather than DOM injected scripts.
 </p>