ariya / phantomjs

Scriptable Headless Browser
http://phantomjs.org
BSD 3-Clause "New" or "Revised" License
29.46k stars 5.76k forks source link

Content-Security-Policy prevents resource loading? #11337

Closed arielschwartz closed 4 years ago

arielschwartz commented 11 years ago

When trying to load http://github.com , I get the following warning for several resources:

[info] [remote] Refused to load style from 'https://a248.e.akamai.net/assets.github.com/assets/github-fdebe8d3f60746fb87c763a59741ff520ae3d8e8.css' because of Content-Security-Policy. It seems to be related to the CSP header in the server's response:

Content-Security-Policy:default-src *; script-src https://github.com https://a248.e.akamai.net https://jobs.github.com https://ssl.google-analytics.com https://secure.gaug.es https://collector.githubapp.com https://gist.github.com; style-src https://github.com https://a248.e.akamai.net 'unsafe-inline'; object-src https://github.com https://a248.e.akamai.net Interestedly, the CSP header should allow loading resources from the domains specified in the CSP header, but for some reason, they can't be loaded. https://github.com/blog/1477-content-security-policy

I'm using phantomjs 1.9. Also, setting --web-security=no does not help as well.

Should this be the normal behavior? Is there any way to remove/filter a response header (i.e. remove the CSP header) and then reload (without making an actual http request) the page, or any other advice to mitigate this?

gabetax commented 11 years ago

I'm having similar issues when driving phantoms 1.9.2 from capybara with poltergeist. When I make a request, my server is sending these response headers:

[4] pry(#<RSpec::Core::ExampleGroup::Nested_1>)> response_headers
=> {"X-Frame-Options"=>"DENY",
 "X-Xss-Protection"=>"1; mode=block",
 "X-Content-Type-Options"=>"nosniff",
 "X-Ua-Compatible"=>"chrome=1",
 "X-Webkit-Csp"=>
  "default-src 'self' chrome-extension:; connect-src 'self' chrome-extension:; font-src 'self' http://fast.fonts.net https://fast.fonts.net chrome-extension:; frame-src 'self' chrome-extension:; img-src 'self' https://www.google-analytics.com http://www.google-analytics.com chrome-extension: data:; media-src 'self' chrome-extension:; object-src 'self' chrome-extension:; script-src 'self' https://www.google-analytics.com https://fast.fonts.com https://get.gridsetapp.com chrome-extension:; style-src 'self' 'unsafe-inline' https://get.gridsetapp.com http://fast.fonts.net/ https://fast.fonts.net/ chrome-extension:;",
etc..

but I'm getting this sent to my console:

Refused to load style from 'https://get.gridsetapp.com/12345/' because of Content-Security-Policy.

Refused to load script from 'https://fast.fonts.com/jsapi/1933919b-7696-4c22-b59b-e1033ac21334.js' because of Content-Security-Policy.

Refused to load script from 'https://www.google-analytics.com/analytics.js' because of Content-Security-Policy.

Refused to load script from 'https://fast.fonts.com/jsapi/1933919b-7696-4c22-b59b-e1033ac21334.js' because of Content-Security-Policy.

The CSP works fine in desktop Chrome and Safari without any warnings. This feels like phantomjs is raising false positives. Luckily none of my tests actually require these external assets for functionality.

ghost commented 10 years ago

I was able to solve this problem by hiding CSP headers on nginx proxy. The nginx config is quite simple:

server {
    listen  81;
    location / {
        resolver            8.8.8.8;
        proxy_pass          http://$http_host$request_uri;
        proxy_hide_header   "x-webkit-csp";
        proxy_hide_header   "content-security-policy";
    }
}

(I believe you can do the same with any webserver)

Then you have to run your phantom script with --proxy parameter:

phantomjs --proxy 127.0.0.1:81 script.js

This approach works well unless you have HTTPS requests on a page I hope this information will help someone.

brimsey commented 9 years ago

I'm experiencing the same problem. The tests work fine in Chrome and Firefox but fail in PhantomJS. Curiously, the PhantomJS tests run fine on OSX but fail on Windows. The Content-Security-Policy is preventing PhantomJS from retrieving css and javascript resources so my automated tests are failing. Any chance we can get this fixed? Please let me know if you need further details.

SorX14 commented 9 years ago

I was having the same issue with phantomjs version 1.9.0; updated to version 2.0.0 and it works perfectly

PiotrMachner commented 9 years ago

If I remember correctly I did experiment with 2.0.0 and it did not help in my case.

Upvoting this issue: :+1:

eugenesia commented 9 years ago

Still having this problem with PhantomJS 2.0.0 , run with a CasperJS 1.1.0-beta3 script. Upvoting as well.

ronwsmith commented 8 years ago

FYI, I came across this issue as I had different behavior between phantomjs and selenium after adding a connect-src header. Turned out that it was an ajax call on the page that was being blocked as defining the connect-src overrode the default-src. Not sure why it worked in selenium/firefox but after adding the protocols from default-src into my new connect-src, it's working fine in phantomjs now. Definitely some difference in processing CSP headers between drivers.

andrewmunro commented 8 years ago

Having this issue too. Any workarounds?

chadwhitacre commented 7 years ago

I believe this should be closed as a duplicate of #13114.

fipso commented 7 years ago

Anything new here ?

mesaleh commented 6 years ago

PhantomJS latest stable version 2.1.1 has a bug when it tries to get a webpage that has the following response header: content-security-policy: default-src 'none'

The Fix: Branch 2.1.1, File: \phantomjs\src\qt\qtwebkit\Source\WebCore\page\ContentSecurityPolicy.cpp, Change line 354:

, m_allowEval(false)

To:

, m_allowEval(true)

Then build.py -r ... Enjoy!

stale[bot] commented 4 years ago

Due to our very limited maintenance capacity (see #14541 for more details), we need to prioritize our development focus on other tasks. Therefore, this issue will be automatically closed. In the future, if we see the need to attend to this issue again, then it will be reopened. Thank you for your contribution!