Content security policy blocking requests to *://www.google.com/recaptcha/api

Question

In light of this link , it would seem inline scripts such as are used for inserting a recaptcha object in the page, via

<script type="text/javascript"
     src="http://www.google.com/recaptcha/api/challenge?k=your_public_key">
</script>
<noscript>
<iframe src="http://www.google.com/recaptcha/api/noscript?k=your_public_key"
     height="300" width="500" frameborder="0"></iframe><br>
<textarea name="recaptcha_challenge_field" rows="3" cols="40">
</textarea>
<input type="hidden" name="recaptcha_response_field"
     value="manual_challenge">
</noscript>

or via

 <script type="text/javascript" src="http://www.google.com/recaptcha/api/js/recaptcha_ajax.js"></script>

with

Recaptcha.create("your_public_key",
"element_id",
{
  theme: "red",
  callback: Recaptcha.focus_response_field
}

);

I always get some complaint about the content security policy, despite my manifest.json apparently allowing urls' like http://www.google.com/recaptcha/api/js/recaptcha_ajax.js

Am I missing something really obvious that makes this whole question crazy?

Answer 1

I just spent two hours fighting with this. For me, and I think for this example as well, the problem lies in the src attribute; that is, in the http:. Changing the references as follows:

<script type="text/javascript" 
     src="https://www.google.com/recaptcha/api/challenge?k=your_public_key">
              ^  v
<iframe src="https://www.google.com/recaptcha/api/noscript?k=
     height="300" width="500" frameborder="0"></iframe>

fixed the problem. Basically, you're attempting to access the google api with an unsecure connection, and certain browsers (e.g., Chrome) don't render insecure content by default.

Answer 2

In a Chrome extension, the non-secure http cannot be whitelisted via the CSP.
The documentation states:

Relaxing the default policy

(...) If, on the other hand, you have a need for some external JavaScript or object resources, you can relax the policy to a limited extent by whitelisting specific HTTPS origins from which scripts should be accepted. Whitelisting insecure HTTP resources will have no effect. This is intentional, because we want to ensure that executable resources loaded with an extension's elevated permissions is exactly the resource you expect, and hasn't been replaced by an active network attacker. As man-in-the-middle attacks are both trivial and undetectable over HTTP, only HTTPS origins will be accepted.

Answer 3

You should make all your resource calls protocol relative urls. Basically remove any http: or https: and just use //

More info here http://www.paulirish.com/2010/the-protocol-relative-url/

and here Is it valid to replace http:// with // in a <script src="http://...">?