I have defined my security policy as:
default-src 'self'; script-src 'self'; frame-src 'self'; style-src 'self' 'unsafe-inline';
(I still have CSS at the head of several pages).
I have no trouble with Firefox or Chrome (IE doesn't support CSP yet) but, when I try testing in Safari, I get a string of errors like:
Refused to load style from 'http://localhost/styles/alliance.css' because of Content-Security-Policy.
.
.
.
Refused to load image from 'http://localhost/images/Landing1.jpg' because of Content-Security-Policy.
.
.
.
Refused to load script from 'http://localhost/JQuery/jquery-1.7.2.min.js' because of Content-Security-Policy.
The images should be covered by default-src and the other two are listed as "Self" so I don't know why Safari is not accepting my images and scripts. I do not have a Mac so I am using Safari on Windows (5.1.7).
Any ideas? Thank you!
Safari 5 is a bit behind in its implementation of CSP. Safari 6 is much better, but I don't think its been released for Windows. I think you're simply seeing implementation bugs. If WebKit nightlies are available for Windows, that might be a good alternative for testing.
Honestly, though, I wouldn't recommend serving the X-WebKit-CSP header to Safari 5. Safari 6, yes, but 5 is a bit too broken to really use.
Note also that you can simplify your policy. Both script-src and frame-src will fall back to default-src. default-src 'self'; style-src 'self' 'unsafe-inline' should have the same effect.
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'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:
For some reason both Mozilla Observatory and CSP validator are not detecting the CSP header in my .htaccess file yet the header is visible when viewed through Chrome.
Here's my current CSP header in my .htaccess file;
Content-Security-Policy: script-src 'nonce-$RANDOM' 'strict-dynamic' 'unsafe-inline' object-src 'none'; base-uri 'none'; report-uri https://altfit.report-uri.com/r/d/csp/enforce;
Also I noticed that the nonce is not working, inline scripts still load without nonce in place but if I make modifications to the CSP it can restrict script execution and the display of inline elements.
Info:
Server is Light Speed.
PHP version is 7.1
Fixed the issue by modifying the line in .htaccess to the following;
Header set Content-Security-Policy: "default-src https: 'unsafe-inline'; report-uri https://altfitcom.report-uri.com/r/d/csp/enforce;"
Only issue now is the addition of unsafe-inline but from what I have read strict-dynamic and nonce do not work as a cross platform solution and I have to have inline js for some onclick events.
I'm setting up Content-Security-Policy headers in Nginx and I am stuck at getting the locally hosted Typekit fonts to work.
I'm using the following script for hosting Typekit fonts locally and the result has been very good with good load times and no FOUT: https://github.com/morris/typekit-cache
But now the problem is setting up CSP to pass these fonts. I tried localStorage but it didn't work.
These are the errors I'm getting:
[Report Only] Refused to load the font
'data:font/opentype;base64,d09GMgABAAAAAFb0ABQAAAAAskgAAFaDAAIAAAAAAAAAAAAAA…bJbjfY7U6T320POPp5HLprLxRlPwIJqShhBB1pRCUKkQmIKRpGoiON1kre7lGR0Z4h5ENMAQAA'
because it violates the following Content Security Policy directive:
"font-src 'self'
[Report Only] Refused to load the font
'data:application/font-woff;base64,d09GRgABAAAAABwUAA4AAAAAKHQAAQAAAAAAAAAAA…NfJJTVolXlnco7lXdLiWW32CnmmMrFlnJ5aXLN8srxynGxmBgfv9d+AQ8KdggAAAABVwJMPAAA'
because it violates the following Content Security Policy directive:
"font-src 'self'
(I removed the domains listed for the font-src policies).
Thank you
You can see its creating the font-src as data when it loads them in. That is base64 encoded versions of the font rather than links to the fonts themselves.
So just change font-src 'self'; to font-src 'self' data: ; and it should work fine.
We're currently introducing the Content Security Policy to a website. Started by inserting the Content-Security-Policy-Report-Only header to get some feedback about the impact. Soon we found out that the Evernote Web Clipper plugin in the Safari browser violates the CSP directives as it seems to inject some code into the page.
We get this in the CSP report:
{"csp-report":
{
"document-uri":"http://example.com/index.html",
"violated-directive":"default-src 'self'",
"original-policy":"default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; report-uri http://example.com/report.html",
"blocked-uri":"safari-extension://com.evernote.safari.clipper-uahs7eh2ja",
"source-file":"http://example.com/js/jquery.js",
"line-number":2
}
}
How do we need to modify the CSP header so that the Evernote Web Clipper plugin is not blocked? The blocked-uri seems to contain a user-specific id at the end which makes it pretty difficult.
You're right, the last bit of the blocked uri does vary across computers, and you can't use a wildcard to whitelist it. The only way to unblock the Web Clipper is to unblock all Safari extensions by putting safari-extension://* in default-src, so your policy would look like
default-src 'self' safari-extension://*; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; report-uri http://example.com/report.html