I've been having ongoing hurdles with my CSP policy and trying to whitelist the urls for my cookie banner (Iubenda). Between Chrome's developer tools and ReportURI, I can get everything to work and nothing gets blocked.
Until Iubenda updates it's vendor list (which happens randomly and often). They change the version # in the url so it no longer passes through my CSP. The most recent example: https://cdn.iubenda.com/cs/tcf/v2/vendorlist.46.json is whitelisted under "connect-src" and works. Except they just updated the vendorlist and the url is now https://cdn.iubenda.com/cs/tcf/v2/vendorlist.47.json
I tried using a wildcard to try an include future variations of the file, or even to include all links that come from the site httsp://cdn.iubenda.com/* as well as including 'self' - but I have a feeling it's not the right solution. Is there a better way to write the exception so I don't have to keep checking every few weeks if they updated the link (which can prevent my cookie banner from displaying).
My coding skills are poor, so it could be something simple that I've missed.
Have you tried following here? https://www.iubenda.com/en/help/12260-how-to-configure-content-security-policy-to-allow-iubenda-scripts-to-execute
They suggest something similar:
Content-Security-Policy:
default-src 'self';
script-src 'self' *.iubenda.com 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa' 'unsafe-eval';
connect-src *.iubenda.com;
style-src 'unsafe-inline' *.iubenda.com;
frame-src *.iubenda.com;
img-src *.iubenda.com data:
Related
I have a fairly standard Node Express user authentication configuaration. Express-session, cookie-parser are used for sessions / cookies and passport to handle authentication.
I recently added a content security policy to all routes, and it's messing with user sessions. Navigating the site internally is fine. If you manually type a url into the browser, also good - it will remember your logged in session.
However, if you access the site via a bookmark, or follow a link from a 3rd party website, the user is thrown out and forced to log in again. If I disable the content security policy, everything is fixed.
Can anyone advise on why this happens, or what to investigate, as I'm a bit in the dark as to how it could be happening.
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-b2bd8bb3d70af06062931f9217eeec75'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;
default-src 'self' set all these below to 'self':
child-src
connect-src
font-src
frame-src
img-src
manifest-src
media-src
object-src
prefetch-src
script-src
script-src-elem
script-src-attr
style-src
style-src-elem
style-src-attr
worker-src
I would add them all manually one by one and see which one of these introduce the issue you are having. After this you can remove them all again and add the whitelisting you need.
A good practice aswell is too add a report-uri to fetch all the times you get blocked. Maybe in the report there is aswell some more usefull information. You can aswell enable a 'report-only' mode until you are confident the issue you are having is resolved. Another resource I can suggest is the CSP evaluator from Google; it suggestions are really useful.
Hope this answer helps you find why your users get logged out!
OK, this was a bad question...
The cause was that in the same commit, that the content-security-policy was originally added, I also set the cookie sameSite property to true. It was a mistake of me to not separate my commits better. Problem solved...
I recently added Google AdSense to my website and the ads works fine, expect sometimes they don't load and I get the following errors in the console
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src https://cdn.ampproject.org/". Either the 'unsafe-inline' keyword, a hash ('sha256-xxx'), or a nonce ('nonce-...') is required to enable inline execution.
From what I've read I need to added the CSP in my HTML headers, but doesn't seem to fix the problem.
Any tips?
TRY1
This discussion could help to get access to the site with the following snippet:
script-src 'self' http://xxxx 'unsafe-inline' 'unsafe-eval';
TRY2
This documentation will show you how to define the policy with:
Content-Security-Policy: script-src 'self' https://apis.google.com
Hope that will help and you question is answered. Give it a shot, cheers! :)
I am trying to add CSP to our web site, using report-only (to report-uri.com).
It seems to work as expected for most cases, but google related sites gets reported even if the URL is added to the header.
Here´s the relevant part of header as it appears in developer tools:
connect-src 'self' https://stats.g.doubleclick.net
I am still getting this violation:
"blocked-uri": "https://stats.g.doubleclick.net/j/collect"
I have experienced similar issues with other Google related sites as well.
The problem is that we're using Google tags and analysis, so I cannot block the sites out.
This particular problem seems to come from Chrome only.
In addition to blocked-uri, note in the reports on the original-policy field - is there your CSP with the connect-src 'self' https://stats.g.doubleclick.net rule or not.
Looks like some ISPs, in violation of RFCs, cache site responses along with HTTP headers. At least after the changes in the CSP, within 2 weeks there is violation reports having the old CSP in the original-policy field.
And it feels like you changed the rules in connect-src directive recently.
List of sources connect-src 'self' https://stats.g.doubleclick.net is not complete for Google Analytics, you can insert own Google Analytics ID and check. Here is comprehensive test of Content Security Policy for GTM.
Here is initial CSP for GA + GTM. The initial because though GTM you can embed a lot of third-party scripts from vary sources.
I started exploring Content Security Policy on a website which uses inline scripts and other crimes. I configured CSP per header field like this:
content-security-policy: default-src *; frame-ancestors 'self'; style-src 'self' 'unsafe-inline' fonts.googleapis.com cdn.jsdelivr.net *.stripe.com; report-uri https://sentry.io/api/x/csp-report/?sentry_key=y
My problem now is that the browser complains with the following message:
Refused to execute inline script because it violates the following Content Security Policy directive: "default-src *"
I read the documentation for default-src <source> which states that <source> can be one of the following sources:
<host-source>
<scheme-source>
'self'
'unsafe-inline'
etc.
It seems to me that the asterisk can only be used for host sources. But what else can I do since only one <source> seems to be allowed? default-src * 'unsafe-inline' would not be compliant, right?
My goal basically is to use a minimal CSP configuration which works (and can be embedded via iframe). I am aware that it's best practice to go on with specific rules.
It seems to me that the asterisk can only be used for host sources.
Yes
But what else can I do since only one <source> seems to be allowed?
Multiple <source>s are allowed.
default-src * 'unsafe-inline' would not be compliant, right?
It’s compliant.
You can use https://cspvalidator.org/ to check. Or https://csp-evaluator.withgoogle.com/.
But you really want to avoid specifying 'unsafe-inline' in any CSP policy. Using 'unsafe-inline' pretty much defeats the entire purpose of CSP.
What you want to do instead for any inline scripts causing CSP errors is: take the scripts out of your document and move them into separate files. That’s sort of the whole point.
But if you really must specify 'unsafe-inline', then as far as the dealing with the specific error cited in the question, you should only specify 'unsafe-inline' for script-src — because the error message says, “Refused to execute inline script.”
If you instead specify 'unsafe-inline' for default-src, then that causes the browser to fail to do CSP checks for any inline resources in your document — stylesheets, etc., too, not just scripts.
So if the only problem is an inline script and for some reason you can’t fix that by moving the script out to a separate file, or specifying a hash or nonce for it, then you should at least only specify 'unsafe-inline' for script-src.
I have added functionality to my Chrome extension such that the icon button changes color when it is clicked. The code is simple:
chrome.browserAction.setIcon({path:"icon_pink_lines.png", tabId:tab.id});
However, this took me a while to figure out because it turns out that it doesn't work when the content_security_policy is set in manifest.json. I originally had
"content_security_policy": "default-src 'none'; script-src 'self'"
The question is, what, if anything, do I lose by removing this? Or should it just be something else to work with the icon change? To be honest, I just copied the original policy from some sample manifest file and haven't thought about it since.
There is a default value for content_security_policy if you don't set it up yourself:
script-src 'self'; object-src 'self'
Yours is tighter though. It does not allow to load any external resources (while default policy does not allow only external scripts). It seems that your icon_pink_linkes.png is treated as an external resource and blocked by CSP. This looks like a bug to me, you can report it here (I've searched for similar bugs, but haven't found any).