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.
Related
#console browser issue for Content security Policy
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-9X08/o2ns8hEbTzT0V1Xyn6yYc8qftFOKmH3KNb8dWo='), or a nonce ('nonce-...') is required to enable inline execution.[enter image description here][1]
#Image of the error
[1]: https://i.stack.imgur.com/7R9sp.png
Code written for CSP
frame-ancestors 'self' https:
script-src 'self';
object-src 'none';
base-uri 'none';
style-src 'self' fonts.googleapis.com 'unsafe-inline';
media-src *;
img-src 'self';
It seems the error indicated there's issue with using inline-script.
which looks like
<script>
your codes
</script>
If you're going to use inline script, add 'unsafe-line' to script-src directive.
Current setting only allows scripts that's source of your domain.
ex)
<script src="/yourDomain/public/yourScript.js">
Your script-src directive of 'self' only allows scripts to be loaded as script files from the same domain. Your page also has inline scripts that need to have permission in the CSP to run. You have a few choices:
Move the script code to a separate .js file hosted on the same domain. If you use a different host you'll need to allow that host in your script-src directive.
Add 'unsafe-inline'. This will allow ALL inline scripts, which will pretty much remove the XSS protection that CSP is able to give.
Add the suggested hash value 'sha256-9X08/o2ns8hEbTzT0V1Xyn6yYc8qftFOKmH3KNb8dWo=' to script-src allowing this one script. This is a good solution if there are only one or a few inline scripts to allow.
Add a nonce. Nonces should change on every pageload and are a good solution for dynamic scripts if you are able to inject nonces correctly.
We have a hard dependency on an javascript API that requires 'unsafe-inline' 'unsafe-eval' if used in a CSP. If we add a CSP header with the values below can we improve our security posture by limiting whitelisting the origins of where the scripts may be executed from or are we opening ourselves up more by explicitly allowing 'unsafe-inline' 'unsafe-eval'? Our current thinking that without a CSP we are implicitly allowing in inline scripting and eval otherwise our API would not work, so what is the downside of adding 'unsafe-inline' 'unsafe-eval' explicitly to our CSP?
script-src 'self' 'unsafe-inline' 'unsafe-eval' https://<localserver> https://<remoteserver>
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.
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.
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