I am developing a site, which is still local. I installed this package to add the correct CSP to my site (which I built with Laravel & VueJs).
I have solved them one by one. But now in my chrome console, I don't see any CSP errors anymore. It only shows a blank page. I opened the site in Firefox. There, in the console, I came across the following error:
Content Security Policy: The page’s settings blocked the loading of a
resource at self (“script-src”). Source: call to eval() or related
function blocked by CSP.
I searched the generated bundles for the eval() function, but it doesn't appear in any of the files. Does anyone here have some suggestions for me on how to solve this?
Related
I have added an image of the WordPress site where I am facing these two issues which are becoming a hurdle in my site to optimize for best practices. I tried to find its solution but got no understanding of how to do that in my website of WordPress.
Uses deprecated APIs 1 warning found
Browser errors were logged to the console
Screenshot from Chrome inbuilt dev tool
I have found the solution by removing this policy from htaccess file. It's an HTTP header. You can check your website HTTP headers.
Header set Expect-CT enforce,max-age=2592000,report-uri="https://example.com/"
here is some help on this issue I believe.
https://developer.chrome.com/blog/immutable-document-domain/
I'm having trouble figuring out why CSP is being applied to a page, when inspection of the request/response shows no Content-Security-Policy header being sent (see screenshot).
The application is a Jenkins instance, serving some static HTML content generated by a job, and it's previously had the restrictions relaxed as described here: https://wiki.jenkins.io/display/JENKINS/Configuring+Content+Security+Policy. This fixed the original instances of the static content not showing because of the CSP restrictions. Now, however, it came back in a different place, and the original solution is ineffective (for obvious reasons, as there's no header to modify). Just in case, I've verified that the custom CSP value is still set inside Jenkins. The problem happens in all of Firefox 64, Chromium 71, and Chrome 55.
How can I figure out where the CSP originates? Have browsers started to apply it by default now? I thought the whole point of CSP was that it was opt-in and degraded to same-origin policy if absent.
EDIT: There's no <meta http-equiv="content-security-policy"> in the source either.
Figured it out eventually: it turned out to be a caching thing, despite me disabling doing non-cached reloads, apparently I wasn't doing it hard enough. That was hiding the original request, which did indeed have a CSP header. After clicking enough things in DevTools and settings, I was able to get it to re-issue the original request and could see it in the request view to see what was being applied.
I'm developing a chrome extension that renders and sidebar iframe in Gmail.
A while back, we ran into a Content Security Policy issue that broke our extension and ran into a well-known error that shows up in your console as
Refused to frame '[OUR DOMAIN]' because it violates the following Content Security Policy directive: ...
To fix it, we had to rewrite the CSP header as explained in this blog post.
However, recently, we've been getting the same error, even after having implemented the fix suggested in the blog post.
As you can see, even though we added the chrome.webRequest.onHeadersReceived listener to overwrite the CSP header, our domain doesn't seem to be working. As a result, our sidebar does not load.
Notes and attempts:
Note that upon refreshing the entire page, the sidebar will sometimes load successfully %50 of the times, which leads me to believe that we're not adding the above event listener fast enough. To solve this, I pulled the event listener out of our background class and placed it at the top of the background js script. However, this issue seems to still persist.
We've tried to remove and re-add the extension but that didn't yield any permanent results.
Throughout testing, I also noticed that adding another extension that implements a similar override on the CSP header will cause our extension to break. Removing and re-adding our extension brings us back to the 50-50 issue in the first note.
[Update]
It seems that being able to reproduce it %50 of the times has to do with the version of chrome. After upgrading it to 72, I'm now able to reproduce the issue. However, doing a hard refresh on the page will sometimes allow the page to load.
More details on our setup: What we do is basically have a background.html which contains html templates and we have one template that contains an iframe tag. To get the template with the iframe, we do a sendMessage, grab the response, which is the template in string, convert it to DOM element via jquery, append it to body, and change the iframe's src attribute. What happens is the iframe loads fine initially, but when you click on any link in the iframe that would redirect to another page, the same error above shows up.
I can provide snippets and more info if needed.
When using JS/CSS from unsecured CDN in https page,
A. Some pages block loading js/css, and cause runtime error by short of js code.
B. Some pages do not block loading js/css, pages are shown as entirely insecure contents.
What is the difference of these behaviors?
Even if using same browser (I'm using Chrome 51.0.2704.103 (64-bit) in Mac OS X) and seeing same page, behavior changes sometimes...
May some response headers of index.html or so control this behavior?
Anyone know about this?
Example:
My friend create page https://cfn-iot-heatmap.herokuapp.com/, in before, this page's behavior was like A, contents are totally white out.
In this case, insecure CDN contents are:
https://cdn.leafletjs.com/leaflet-0.6.4/leaflet.js
https://cdn.leafletjs.com/leaflet-0.6.4/leaflet.css
I got source codes of this page and deployed to my heroku repository https://kinkyujitai.herokuapp.com/, it is shown like B.
But curious, after I deployed my repository, friend's repository also works like B, showing security warning but shown.
It is very curious, so I want to know the reason of this phenomena...
From a secure (https) origin, you should always include secure elements.
If you don't, browser can block insecure request and/or remove the visual indication of the security.
We've partnered with a company whose website will display our content in an IFRAME. I understand what the header is and what it does and why, what I need help with is tracking down where it's coming from!
Windows Server 2003/IIS6
Container page: https://testDomain.com/test.asp
IFRAME Content: https://ourDomain.com/index.asp?lots_of_parameters,_wheeeee
Testing in Firefox 24 with Firebug installed. (IE and Chrome do the same thing.) Also running Fiddler so I can watch network traffic while I'm at it.
For simplicity's sake, I created a page with nothing on it but the IFRAME in question - same physical server, different domain/site - and it failed with
Load denied by X-Frame-Options: https://www.google.com/ does not permit cross-origin framing.
(That's in the Firebug console.) I'm confused because:
Google is not referenced anywhere in the containing app, or in the IFRAMEd app. All javascript libraries are kept locally; there is no analytics in the app. No Google, nowhere.
The containing page has NOTHING on it, except the IFRAME. No html tags, no head tag, no body tag. IFRAME. That's it.
The X-FRAME-OPTIONS header does not exist in IIS on the server: not at the "Websites" node, not in the individual sites.
So where the h-e-double-sticks is that coming from? What am I missing?
Interesting point: if I remove http"S" from the IFRAME url, it works. Given the nature of the data, SSL is required.
You might check global.asax.cs, the app could be adding the header to every response automatically. If you just search the app for "x-frame-options" you might find something also.