When checking Google's HTTP headers I noticed there is no CSP header. Considering they led great efforts when dealing with CSP level 3, I wonder why is that so?
HTTP headers
After some more research I realized google.com does use CSP indeed. CSP can be used directly from a meta tag instead of a HTTP header.
Actually now Aug-2022, I see the following reponse header.
content-security-policy: object-src 'none';base-uri 'self';script-src 'nonce-CBtB0pB_6ERNGUP11XPOxw' 'strict-dynamic' 'report-sample' 'unsafe-eval' 'unsafe-inline' https: http:;report-uri https://csp.withgoogle.com/csp/gws/cdt1
Related
I have a certain internal js-file which I want to block with the use of the Content Security Policy.
I know it's possible to disable external files, but I didn't found informations regarding a certain internal script.
At the moment I use the following CSP:
img-src 'self' data:; default-src 'self' 'unsafe-inline'
So I'm searching a solution to make an exception for default-src 'self'.
If you don't want to allow scripts from 'self', you will need to remove 'self' from default-src and implement all the needed source directives that currently use default-src as a fallback. If you set default-src to 'none' or the remaining value of 'unsafe-inline' the browser errors will tell you what you need to add.
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:
I have currently an issue with a SharePoint web application, where all websites return a response header content-security-policy: default-src 'self'; object-src 'none'; form-action 'self', which breaks the website's view using Chrome or Firefox, as styles won't be applied and Javascript won't be executed.
Console-Log
Refused to execute inline script because it violates the following Content Security Policy directive: default-src 'self'.
Either the 'unsafe-inline' keyword, a hash ('sha256-WFRyoBrQbrYtLpGIdyBszDzxQni3b0V/wUirab0OhKM='), or a nonce ('nonce-...') is required to enable inline execution.
Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.
The problems only occurs if the websites are addressed using HTTPS. I already checked the HTTP Response Headers in IIS. content-security-policy is not specified. If I add it myself, it gets overwritten and is not sent in the response header. There are only two solutions installed, which do not mess with the response headers.
Has anyone an idea what else could change the custom response header and overwrite the one defined in the web.config? Or is there an other way to change the Content-Security-Policy?
I tested changing the IIS Response Headers by configuring the "CustomHeaders"-section in the web.config, by writing custom IIS modules, which modified the headers using the request lifecycle, and also by writing additional rules with the URL Rewriting tool. Nothing worked...
In the end we found out someone extended the firewall, which onwards would add new header and overwrite my changes of the HTTPS response. Mystery solved :)
In my case, I was asked by Network and Information Security Team to add the Content-Security-Policy: default-src 'self'; header in my IIS 8.5 SharePoint Server 2016 Publishing website which affects all the system pages and the browser refuses to execute the scripts and in console we got this error
Refused to execute inline script because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-HU8dCwZsqh4m8QG0y6qanyzPx1d6YSGHuAN0QXmxZvw='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.
I then change the header to Content-Security-Policy:frame-ancestors 'self'; and it resolves the issue.
I actually got this from the JohnC's Answer that helps me resolving the issue
What do frame-src and frame-ancestors do exactly? The definition shows the purpose is the same to define valid contents for frames for both directives.
When to use which one? I was able to load an external domain content in iframe using -
frame-ancestors and default-src rules
frame-src
Both are working but couldn't get correct use cases.
default-src, frame-ancestors, and frame-src are all part of the Content-Security-Policy response header.
frame-src
Restricts what domains and page can load in an iframe.
The HTTP Content-Security-Policy (CSP) frame-src directive specifies valid sources for nested browsing contexts loading using elements such as <frame> and <iframe>.
For example: If the website at https://example.com has a response header of Content-Security-Policy: frame-src 'self', it can only load https://example.com inside iframes.
frame-ancestors
Restricts what domains and page can be loaded in from an iframe (similar to the X-Frame-Options header, but takes precedence over it).
The HTTP Content-Security-Policy (CSP) frame-ancestors directive specifies valid parents that may embed a page using <frame>, <iframe>, <object>, <embed>, or <applet>.
For example: If the website at https://example.com has a response header of Content-Security-Policy: frame-ancestors 'self', it can only be loaded inside iframes from https://example.com.
default-src
Acts as the default value for any fetch directive that isn't explicitly set (here is a list of all fetch directives)
The HTTP Content-Security-Policy (CSP) default-src directive serves as a fallback for the other CSP fetch directives. For each of the following directives that are absent, the user agent will look for the default-src directive and will use this value for it.
For example: Content-Security-Policy: default-src 'self' will default to the value 'self' for all fetch directives. Other directives will be unaffected.
Note: since frame-ancestors is not a fetch directive, setting default-src won't restrict it. It needs to be set separately.
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.