Commit 6b0937a7 authored by mkwst@chromium.org's avatar mkwst@chromium.org

Clarifying the CSP restrictions with regard to `connect-src` and `unsafe-eval`.

BUG=115482


Review URL: https://chromiumcodereview.appspot.com/10837255

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@151961 0039d316-1c4b-4281-b951-d872f2087c98
parent 97aab3b0
......@@ -253,7 +253,9 @@
For full details regarding CSP's syntax, please take a look at
<a href="http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#syntax">
the Content Security Policy specification
</a>.
</a>, and the <a href="http://www.html5rocks.com/en/tutorials/security/content-security-policy/">
"An Introduction to Content Security Policy"
</a> article on HTML5Rocks.
</p>
<a name="H2-0"></a><h2>Default Policy Restrictions</h2>
<p>
......@@ -402,7 +404,10 @@ popup.html:
<p>
There is no mechanism for relaxing the restriction against executing inline
JavaScript. In particular, setting a script policy that includes
<code>unsafe-inline</code> will have no effect. This is intentional.
<code>unsafe-inline</code> will have no effect. Likewise, there is no
mechanism for enabling <code>eval</code>-like constructs. Setting a script
policy that includes <code>unsafe-eval</code> will have no effect. This is
intentional.
</p>
<p>
If, on the other hand, you have a need for some external JavaScript or object
......@@ -422,6 +427,13 @@ popup.html:
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
doesn't restrict <code>connect-src</code> or any of the other CSP directives
in any way.
</p>
<p>
A relaxed policy definition which allows script resources to be loaded from
<code>example.com</code> over HTTPS might look like:
......
......@@ -39,7 +39,9 @@
For full details regarding CSP's syntax, please take a look at
<a href="http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#syntax">
the Content Security Policy specification
</a>.
</a>, and the <a href="http://www.html5rocks.com/en/tutorials/security/content-security-policy/">
"An Introduction to Content Security Policy"
</a> article on HTML5Rocks.
</p>
<h2>Default Policy Restrictions</h2>
......@@ -219,7 +221,10 @@ popup.html:
<p>
There is no mechanism for relaxing the restriction against executing inline
JavaScript. In particular, setting a script policy that includes
<code>unsafe-inline</code> will have no effect. This is intentional.
<code>unsafe-inline</code> will have no effect. Likewise, there is no
mechanism for enabling <code>eval</code>-like constructs. Setting a script
policy that includes <code>unsafe-eval</code> will have no effect. This is
intentional.
</p>
<p>
......@@ -243,6 +248,14 @@ popup.html:
<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
doesn't restrict <code>connect-src</code> or any of the other CSP directives
in any way.
</p>
<p>
A relaxed policy definition which allows script resources to be loaded from
<code>example.com</code> over HTTPS might look like:
......
......@@ -39,7 +39,9 @@
For full details regarding CSP's syntax, please take a look at
<a href="http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#syntax">
the Content Security Policy specification
</a>.
</a>, and the <a href="http://www.html5rocks.com/en/tutorials/security/content-security-policy/">
"An Introduction to Content Security Policy"
</a> article on HTML5Rocks.
</p>
<h2>Default Policy Restrictions</h2>
......@@ -219,7 +221,10 @@ popup.html:
<p>
There is no mechanism for relaxing the restriction against executing inline
JavaScript. In particular, setting a script policy that includes
<code>unsafe-inline</code> will have no effect. This is intentional.
<code>unsafe-inline</code> will have no effect. Likewise, there is no
mechanism for enabling <code>eval</code>-like constructs. Setting a script
policy that includes <code>unsafe-eval</code> will have no effect. This is
intentional.
</p>
<p>
......@@ -243,6 +248,14 @@ popup.html:
<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
doesn't restrict <code>connect-src</code> or any of the other CSP directives
in any way.
</p>
<p>
A relaxed policy definition which allows script resources to be loaded from
<code>example.com</code> over HTTPS might look like:
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment