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.
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'm trying to load my content into an IFrame, so I implemented the Content-Security-Policy header: Content-Security-Policy: frame-ancestors http://*.example.com/abc.html.
I am able to load the content on iframe when I give the header as
Content-Security-Policy: frame-ancestors http://*.example.com/.
But when I change the header to:
Content-Security-Policy: frame-ancestors self http://*.example.com/abc.html.
then the content on iframe is getting loaded for the first time but gives below error when I refresh the web page
Refused to display 'https://....' in a frame because an ancestor violates the following Content Security Policy directive: frame-ancestors self http://*.example.com/abc.html.
Can anyone tell why its giving error on refreshing the page.
Also does frame-ancestors considerers the full url (http://.example.com/abc.html) or only the hostname like http://.example.com?
Chrome browser has a bug - it's not support paths in the frame-ancestors directive. Safari nas the same bug, and only lasets Firefox supports paths in this directive.
So for frame-ancestors instead of http://.example.com/abc.html you have to use http://.example.com host-source.
For other directives you can use paths and filenames.
Without a working example it is hard to know exactly what the problem is. But based on the specification, https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors, some adjustments to your CSP can be advised:
Remove the path, it is not according to the specification to use more than the scheme, host and port.
Use the expected scheme (http/https) or remove the scheme.
Use wildcard https://*.example.com, not just https://.example.com
Use 'self', not self
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
I need to relax the CSP (Content Security Policy) in Chrome to enable a redirect with some get parameters to the Azure login page. When processing such redirects Chrome applies policy restrictions related to form submissions. The default policy in such cases amounts to
<meta http-equiv="Content-Security-Policy" content="form-action 'self' javascript:"/>
In this case the redirect to https://login.microsoftonline.com/...
wont' work. The MDN says that you can expand the list of allowed destinations, which I tried like so:
<meta http-equiv="Content-Security-Policy" content="form-action 'self' https://*.microsoftonline.com javascript:"/>
It appears to have no effect at all as still get the same error on the console:
Refused to send form data to 'https://login.microsoftonline.com' because it violates the following Content Security Policy directive: "form-action 'self' javascript:"
Note also that playing with the order of the attributes or removing the javascript: part does help. However, removing the self part is evidently paid some attention to by Chrome as in this case I'm not able to send data back to the origin. It is almost like they let you tighten up the policy but not relax it.
Any help will be greatly appreciated.
I think that it is caused because form-action (according to the documentation):
The HTTP Content-Security-Policy (CSP) form-action directive restricts the URLs which can be used as the target of a form submissions from a given context.
Maybe you could try the default-src directive:
default-src
The HTTP Content-Security-Policy (CSP) default-src directive serves as a fallback for the other CSP fetch directives.
Hope it helps!
Do not include the protocol (https) and i think it will work
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.