IssueTracker

Oh wow, it looks like it was just fixed, right after I filed this bug!

Closing this bug. Glad it is working for you now.

I'm sorry it looks like this bug still happens. Is there a way to reopen it?

For example 2 - your code:

...
    lf.main = function(a) {
        eval(a);   // <-- Uncaught Error: Code generation from strings disallowed for this context
    };
...

Just to poke this bug, using the asynchronous loading method has no effect on this.  The only workaround is to roll back to manifest version 1 which is actively being phased out.

Switched to Yandex Maps, it works well.
Thank you!

As manifest version 1 won't be accepted by the Chrome Webstore starting in mid August, we really do need a workaround/fix.

As I discovered a few minutes ago, manifest version 1 is no longer accepted by the Chrome store *now*.  So setting the manifest version to 1 and using 'unsafe-eval' in the CSP no longer works for new extensions.

Updating existing extensions may still be supported.

New packaged apps having manifest version 1 are no longer supported.
Please fix this issue as soon as possible.

Thanks

According to deprecation schedule only new items should be affected (for now). For existing items there will be issues starting approximately in November.

Source: http://code.google.com/chrome/extensions/manifestVersion.html

Oh new fun fact, relating to this:  With Chrome 21 you can only install apps/extensions from the Chrome Store.  So not I have an extension I can't deploy to the Chrome Store nor can I push it to my clients directly :(.

Please fix

This is killing now. Can you provide an alternate way to connect to http://maps.google.com/maps/api/js?sensor=false . Thanks

Any updates on this issue or how can we resolve it. If google app cannot support there on google map, that really bad..

Please provide an alternate or a solution ASAP.

Hi all,

A workaround has been released by the Chrome team:
http://code.google.com/chrome/extensions/trunk/sandboxingEval.html

I've attached a sample extension that makes use of this sandboxing technique. To use any of the Chrome extension APIs (e.g. tabs), you'll need to use postMessage to communicate to the popup or background page.

Thank you for the yet another ugly and useless butthurt for developers.
I load my own content and to draw a map I need to sandbox the dangerous google maps api from my page to iframe. Great.

I don't wish to be rude, but this remains a significant problem.

A similar issue also breaks Packaged Apps! The gmaps api uses document.write(), which is not available in packaged apps. So importing https://maps.googleapis.com/maps/api/js?v=3.exp&sensor=false still throws an error. Everyone knows document.write() is bad practice; that the Google Maps API forces you to use it is appalling.

Any hints about that?

I have uploaded a small testcase to help debugging this: https://gist.github.com/icoloma/7934269

Disabling 'unsafe-eval' makes the test fail.

[Comment deleted]

Here is a permanent fix for document.write

try {
    document.write('<' + 'script src="' + src + '"' + ' type="text/javascript"><' + '/script>');
} catch (e) {
    var mapRequest = document.createElement("script"),
        type = (isNaN(document.xmlVersion) === true || document.contentType.indexOf("application") === 0) ? "application" : "text";
    mapRequest.setAttribute("type", type + "/javascript");
    mapRequest.setAttribute("src", src);
    document.getElementsByTagName("body")[0].appendChild(mapRequest);
}

document.write is purely legacy.  Google Chrome does not even recognize the existence of document.write in certain strict rendering modes.  Try this against a file with extention ".xhtml".

The code I provided will continue to support document.write as the default method, but when it fails the error will be suppressed and the valid approach that works in all browsers will be applied instead.

There is absolutely no reason to continue using document.write instead of this code here.  I recommend just removing document.write though.

Bug 4081 can be merged into this issue.

It has been almost 2 years since this has been opened. Can someone tell me why this is still an issue? What is the status report google?

If you want to load that JS file without document.write, set the callback parameter like so:

http://maps.google.com/maps/api/js?sensor=false&callback=googleCallback

You'll see that it loads the js with a different getScript function:

  function getScript(src) {
    var s = document.createElement('script');
   
    s.src = src;
    document.body.appendChild(s);
  }

Can someone give a clear example on how to load google maps correctly? This issue has to be solved by now.

[Comment deleted]

To help us evaluate fixing this issue, are these issues with CSP purely in the context of Chrome extensions, or use of CSP generally on the web (through use of the Content-Security-Policy header)?

I included a gist at #23 with a failing test for a normal website (i.e. no Chrome plugin)

Has there been any update here?  

Allowing 'unsafe-eval' is a deal-breaker, and far from ideal.

As the last comment was in May 2015: this is *STILL* an issue.

It basically requires every public website (not even an 'extension' which needs to use the hackish sandboxing stuff) that utilizes a proper CSP header to include 'unsafe-eval' and a very long list of image sources too.

The eval() usage is still in the API. As others noted, after more than two years, maybe time to drop usage of Google Maps API, as it makes sites insecure.

This issue is on our roadmap. It's clear that CSP is important, and is indeed a deal-breaker.

This won't be simple for us to fix. We'll keep everyone posted with our progress.

This is insane - Google Maps is incompatible with Google Apps. The sandboxing technique is not viable for me. I'm going to have to use a different map tool in my Chrome app.

hmm this totally sucks... people with template solutions like smarty will totaly bomb if they want to integrate a remote apis... i presume some how templaters like smarty inline the javascript codes and links from the template files... utterly diabolical google chrome cant use google maps api? and templaters cant load there apis :(

[Comment deleted]

The problem is bigger then you realize :(

This should be the solution for web developers but of course as per usual chrome fails to come correct at the critical hurdle.. img-src .. and please feel free to put me straight if you know why this is or what I might of done wrong.

The snippet bellow is to get leaflet map working for instance *not even google maps* every thing works and seems to make sense untill img-src fowls up.

<meta http-equiv="Content-Security-Policy" content="
default-src http://mydomain.com/jobtracker;
connect-src http://mydomain.com http://*.mapbox.com/;
font-src http://mydomain.com http://*.mapbox.com/ data:;
frame-src http://mydomain.com http://*;
img-src http://* data: filesystem: blob:;
media-src http://mydomain.com http://*;  
object-src  http://mydomain.com http://mapbox.com;
script-src 'unsafe-inline' 'unsafe-eval'  http://mydomain.com http://*;
style-src 'unsafe-inline' http://mydomain.com http://*;
" />

Can you fix it please google!! ;(
I should invoice google for the loss of productivity...

forgive me for being kind of sick of these security features that google keeps asserting on to us each time forgetting or overlooking something trivial but important and thus setting our projects weeks and causing regressions

Just so you all know even with the `CSP disable extension` activated you still need to provide a full CSP header with every single remote resource white listed to have a hope in hell of dealing with this I even changed my whole setup to SSL and it still persists so please do explain to me how a SSL connection can be man in the middle'd????

How can I close this ticket? It will not be fixed.
All this talk is just useless noise in my mail.

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

Just to let everyone know, we've been working on a solution. We'll have something to announce soon.

The experimental version of the Maps API now no longer uses eval() or document.write. You can therefore load the API without the unsafe-eval and unsafe-inline CSP directives.

sadly i have to report still does not work for me :(

<meta http-equiv="Content-Security-Policy"
      content="default-src *;
               script-src 'self' 'unsafe-inline' 'unsafe-eval'
                           https://mysite.com:*
                           https://*.gstatic.com
                           https://*.googleapis.com
                           https://*.gstatic.com
                           https://*.googleapis.com
                           https://*.google.com
                           ;
               style-src  'self' 'unsafe-inline'
                           https://mysite.com 
                           https://*.gstatic.com
                           https://*.googleapis.com
                           https://*.gstatic.com
                           https://*.google.com
                           https://*.googleapis.com;
">
<script type='text/javascript' src='https://maps.google.com/maps/api/js?v=3.exp&sensor=false&callback=googleCallback'></script>

function googleCallback() {
alert('that will be the day');
}

Can you post the error you're getting? It seems to be working fine for me.

Refused to load the script 'https://maps.google.com/maps/api/js?v=3.exp&sensor=false&callback=googleCallback' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-inline' 'unsafe-eval'".

[Comment deleted]

Is there any update on a resolution to this issue?

Change your Content-Security-Policy:
- delete 'unsafe-inline' and 'unsafe-eval'
- keep https://*.google.com, etc., on your whitelist

Regarding #49
When I load your HTML in Chrome, there are no errors in the console.

Regarding #51
The error message is different from the HTML you posted.
The error message doesn't list https://*.google.com as an allowed script-src, and this is why the browser rejects the script. If you use the meta tag from your previous post, it works correctly.

Regarding #53
There are a number of different issues being discussed here, which one are you referring to? If you can be specific, we can probably help you :-)