I'm at least 90% sure that the following is a result of Chrome's implementation of W3C's CSP standard, but I thought that it'd be best to double down and make sure.
I'm currently in the process of implementing a strict content security policy for a client, and I've run into the following policy directive complications on Chrome 66:
Unrecognized Content-Security-Policy directive 'disown-opener'.
Unrecognized Content-Security-Policy directive 'reflected-xss'.
Unrecognized Content-Security-Policy directive 'referrer'.
Again, I'm sure this is a standards issue (as I'm using MDN’s CSP documentation). If this is the case, can anyone direct me to competing or substituting directives?
Unrecognized Content-Security-Policy directive 'reflected-xss'
The reflected-xss directive was removed from the CSP spec in 2016. But you can use the X-XSS-Protection header to get exactly the same effect reflected-xss was meant for.
Unrecognized Content-Security-Policy directive 'referrer'.
The referrer directive was dropped long ago. Use the Referrer-Policy header instead.
Unrecognized Content-Security-Policy directive 'disown-opener'
Use rel=noopener on any external links. It’s supported in all modern browsers.
Related
I'm using Directus with editorjs extension and trying to embed a YouTube video, but I'm encountering a Content Security Policy error that is blocking the frame-src. The error message I'm getting is:
"Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”)."
I've tried adding the following setting in my .env file:
CONTENT_SECURITY_POLICY_DIRECTIVES__FRAME_SRC="array:'self', 'https://www.youtube.com'"
But I'm still encountering the same error.
There is likely a Content Security Policy present on your page, and adding another one can only make it stricter, not loosen any of the directives. First you'll likely need to locate the existing CSP, likely in a response header, find how it is set and modify it.
To fix the inline script violation you will need to add the hash of the inline script (some browsers will tell you the hash), add a nonce to the script, refactor it into a file or resort to adding 'unsafe-inline'. You should add your chosen source to script-src.
You should also add www.youtube.com to frame-src and/or child-src (frame-src will use a fallback to child-src in CSP level 3 and to default-src in CSP level 2.
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 am working on addition of Content-Security-Policy-Report-Only header to my company's website. While I was researching on it, I found that a few of the pages already have Content-Security-Policy header set.
I investigated further and found that the directives are not required. Also, default directive used for those pages is 'self' whereas what I am planning to set for report-only is 'https:'
I am not an expert in this area and want to make sure that both header values don't interfere. Hence looking for guidance
If I set report-only for the pages that already has CSP header, is it going to interfere with existing headers? Is the behavior browser dependent?
Any help/pointers will be helpful in deciding.
Thanks!
Content-Security-Policy and Content-Security-Policy-Report-Only have no effect on each other and are entirely independent. Setting both is a common practice when tightening policies. I wouldn't doubt that there has been a bug around this behavior at some point, but the spec is clear.
From Section 5 of the CSP2 Spec
A server MAY cause user agents to monitor one policy while enforcing another policy by returning both Content-Security-Policy and Content-Security-Policy-Report-Only header fields. For example, if a server operator may wish to enforce one policy but experiment with a stricter policy, she can monitor the stricter policy while enforcing the original policy. Once the server operator is satisfied that the stricter policy does not break the web application, the server operator can start enforcing the stricter policy.
Based on the link here, server must not send both headers in the same request.
Here is the original text: A server MUST NOT provide Content-Security-Policy header field(s) and Content-Security-Policy-Report-Only header field(s) in the same HTTP response. If a client received both header fields in a response, it MUST discard all Content-Security-Policy-Report-Only header fields and MUST enforce the Content-Security-Policy header field.
Content Security Policy specification says
The frame-ancestors directive obsoletes the X-Frame-Options header. If a resource has both policies, the frame-ancestors policy SHOULD be enforced and the X-Frame-Options policy SHOULD be ignored.
So from my understanding if both Content-Security-Policy and X-Frame-Options headers are present, then X-Frame-Options should be ignored.
I have a web app with both headers, and looks like Firefox 38 is ignores Content-Security-Policy header and uses X-Frame-Options header instead.
My sample headers are:
Content-Security-Policy:frame-ancestors 'self' local.com *.local.com
X-Frame-Options:Allow-From http://local.com
I want that my frame should be accessed from local.com and all subdomains. Local.com is just example. If X-Frame-Options header is present, then it allows just http://local.com, but if i remove it, then Firefox uses Content-Security-Policy header and works fine for domain and subdomains.
Does it mean that Firefox isn't implementing this part? Or it's just too new specification and Firefox doesn't implement it yet? Is there any other way to force Content-Security-Policy header usage?
I know that Chrome works fine with Content-Security-Policy and IE can work just with X-Frame-Options, but looks like i can't combine both headers, as Firefox works not in right way.
One possible way is to sent X-Frame-Options just for IE, and Content-Security-Policy for all other, but is there a better way?
Thanks!
frame-ancestors only appeared in CSP Level 2 (see the changelog) so it's very likely that Firefox 38 just hasn't implemented it yet.
You can verify that quite easily by watching the JavaScript console - the browser will display warnings about each of the CSP directives it doesn't understand.
You can also download Firefox from the beta channel and see if it makes difference, but obviously it won't help much if you just want to build a interoperable solution for production website...