I'm trying to build a CSP policy that looks like following:
Content-Security-Policy: "default-src 'self'; script-src 'self' https://*.example.com; object-src 'none'; style-src 'self'; img-src 'self' 'unsafe-inline'; media-src 'self'; frame-src 'self' https://*.example.com; font-src 'self'; connect-src *"
If you noticed everything is normal except for connect-src *.
We need to implement this as we are seeing scaling issues as we onboard new services which requires different endpoints to connect to. I want to understand what the security threats are if we allow connections to everything but restrict other derivates.
The connect-src directive covers interfaces:
<a> ping
fetch
XMLHttpRequest()
sendBeacon()
WebSocket
EventSource
The "what security threats are if we allow connections to everything" depends on how do you use on the page the things which you are get via connect.
even if I'm allowing connections to everything, but I've set script-src to self, does that mean it'll allow connections to everything but script will be restricted to self?
No. The script-src directive covers only sources for script loading/execution. script-src 'self' means that is allowed to load external scripts from the same scheme:/domain:port_number from where the page itself was loaded.
Fithermore, nothing prevents you from loading the script using XMLHTTPRequest from any source (because of connect-src *) and execute it.
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 have an admin panel, I would like to permit only browsers without any extension/addon.
I tried setting stringent csp policy
content-security-policy:
script-src 'nonce-xxx' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'self';
block-all-mixed-content;
but it seems that Chrome addons can bypass it.
#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>
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