I want to understand how the CSP will be applied when different REST responses in the page have different header value for CSP. We dont have any meta tag for CSP. CSP is applied only through response headers.
Lets take the scenarios of 3 APIs
GET /api/v1/users - Content-Security-Policy: default-src 'self' google.com; script-src 'self' 'unsafe-inline' 'unsafe-eval' google.com
GET /api/v1/roles - Content-Security-Policy: default-src 'self'; script-src 'self'; img-src 'self'
GET /api/v1/permission - Content-Security-Policy: default-src 'self' google.com; script-src 'self' 'unsafe-inline' 'unsafe-eval' google.com
In this case, what will be the CSP considered by the browser for subsequent requests?
Also, in my understanding, server sets the CSP in the response header to inform browser about what content will be allowed going forward. is that correct?
A CSP determines what resources can be loaded on a page and is only applied on pages that are rendered in the browser, typically with content type "text/html". So there is no benefit in setting it on images, scripts, styles etc.
The CSP that makes sense for an API is frame-ancestors 'none', see https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html#security-headers for an explanation.
Related
I didn't used google tag manager url in my code but it still shows the ERROR and HERE is the Error.
ERROR
Refused to load the script 'https://consent.trustarc.com/v2/notice/jznryc' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-inline' https://www.googletagmanager.com". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.
this is the code i am using.
<meta http-equiv="Content-Security-Policy" content=
"default-src *;
style-src 'self' 'unsafe-inline' ;
script-src 'self' 'unsafe-inline' https://consent.trustarc.com ;
script-src-elem 'self' 'unsafe-inline' ">
The most likely explanation is that two (or more) policies are set. Something is setting another CSP, likely in a response header. You will need to find the policy and modify/remove it.
I'm trying to load SVG images and get a CSP error as follows:
I keep getting the error event when I added the meta tag:
<meta http-equiv="Content-Security-Policy" content="default-src *;img-src * 'self' data: https:; script-src 'self' 'unsafe-inline' 'unsafe-eval' *; style-src 'self' 'unsafe-inline' *" >
The error that you can see tells you that the img-src was not set and it fallbacks to default-src even though that you have added meta tag with your CSP values.
This behaviour can be observed when the CSP header is already set via HTTP. You have to choose whether to set it via HTTP or as meta tag.
I'm trying to setup CSP headers for my application. I have intentionally left out our CDN from font-src
and style-src directives so that violation is triggered. I can see the violations on the Chrome Dev Tools console but the request to the csp-endpoint specified in the header is not triggered. I have tried by setting the report-uri attribute but that didn't help either. I'm testing this on Chrome 84 which is supposed to support report-to directive. Is there anything I'm missing here?
Content-Security-Policy-Report-Only: default-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval' www.googletagmanager.com www.google-analytics.com; style-src 'self' data: 'unsafe-inline' www.tagmanager.google.com www.fonts.googleapis.com fast.fonts.net; img-src 'self' data: www.googletagmanager.com www.google-analytics.com; form-action 'self'; font-src 'self'; connect-src 'self'; report-to csp-endpoint
Report-To: {"endpoints":[{"url":"http://localhost:8080/myapp/csp-violation-report"}],"group":"csp-endpoint","max_age":10886400}
report-to endpoints should have a secure context (actually - https:). Non-secure endpoints will be ignored.
There is some problems with resolving of localhost name, not all user agents treat it as trustworthy. The localhost should conforms to the specific (para 5) name resolution rules (pls see Let 'localhost' be localhost RFC update).
Briefly - try to use https://127.0.0.1:8080/myapp/csp-violation-report. May be a secure https: https://localhost:8080/myapp/csp-violation-report will be enough for Chrome (Chrome 84 supports the report-to directive, but Firefox - does not).
My application is being reverse proxied by Nginx.
I've setup Nginx to add a Content-Security-Policy header to the response. This is working perfectly and I can see the header returned from Chrome as well as CURL from a number of machines.
From a particular machine I'm seeing something very strange. Chrome is showing only a small portion of the Content-Security-Policy header was returned in the response, leaving out a number of key policies. When using a different browser on the same machine the headers are all returned.
Apologies if this is a silly question but could it be that a binary or something else in Chrome has been modified and is modifying the Content-Security-Policy header? I understand how ridiculous that sounds and there could be something I don't understand about CSP.
Could someone help me understand what is happening here?
What most machines are getting:
Content-Security-Policy:default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://ssl.google-analytics.com https://assets.zendesk.com https://connect.facebook.net; img-src 'self' https://ssl.google-analytics.com https://s-static.ak.facebook.com https://assets.zendesk.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com https://assets.zendesk.com; font-src 'self' https://themes.googleusercontent.com; frame-src https://assets.zendesk.com https://www.facebook.com https://s-static.ak.facebook.com https://tautt.zendesk.com; object-src 'self'
What this one particular machine is getting:
Content-Security-Policy:default-src 'self';
Eureka! I have the answer.
It looks like ESET was inspecting and modifying the headers in the request. You can switch this off quite easily.
I have the CSP (Content-security-policy) plugin-types policy set to white-list pdf type as below. When trying to open a PDF file in iframe with src attribute, It is working well with browsers IE 11, and Firefox 47+ but failing in Chrome 50+. What else is required to make it working in chrome?
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; object-src 'self'; style-src 'self'; frame-src 'self' plugin-types application/pdf;
Error in chrome console
Resource interpreted as Document but transferred with MIME type application/pdf
Refused to load 'http://127.0.0.1/module123/open.do?id=10000' (MIME type '') because it violates the following Content Security Policy Directive: 'plugin-types application/pdf'. When enforcing the 'plugin-types' directive, the plugin's media type must be explicitly declared with a 'type' attribute on the containing element (e.g. '<object type="[TYPE GOES HERE]" ...>').
I had a similar problem.
To resolve the problem, I needed to add blob: to the object-src directive.
Also, I did not need to specify plugin-type.
So it would be:
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; object-src 'self' blob:; style-src 'self'; frame-src 'self';