I set up CORS on s3 using https://docs.aws.amazon.com/AmazonS3/latest/userguide/ManageCorsUsing.html. On my site I am using ckeditor to upload an image which sends it to s3. problem is, the POST works but GET does not. fails with
cross-origin-resource-policy
To use this resource from a different
origin, the server needs to specify a cross-origin resource policy in
the response headers:
Cross-Origin-Resource-Policy: same-site
Choose this option if the resource and the document are served from the same
site.
Cross-Origin-Resource-Policy: cross-origin
Only choose this option if an arbitrary website including this resource does not impose
a security risk.
Response from GET
Accept-Ranges: bytes
Content-Length: 90105
Content-Type: image/png
Date: Wed, 12 May 2021 16:44:33 GMT
ETag: "3524cdaa5d0975c249bb464033808244"
Last-Modified: Wed, 12 May 2021 16:44:33 GMT
Server: AmazonS3
...
x-amz-id-2: pNoskXKWXhpCbwArHgIN4kVD+oO8Pyq/3PIJAEcSJCo3hWMmHVspn2mIjfItCFAM+jUXtcN3pqY=
x-amz-request-id: 3BEE5J8RQPCXTQ93
I have the following set on apache server
Header set Content-Security-Policy "default-src 'self' *.s3.amazonaws.com *.uatdomainplus.com *.qadomainplus.com *.hci.com hci.com ; font-src *.typekit.net cdnjs.cloudflare.com fonts.gstatic.com *.hcidomain.plus *.uatdomainplus.com *.qadomainplus.com ; img-src 'self' data: *.s3.amazonaws.com; style-src 'self' 'unsafe-inline' p.typekit.net use.typekit.net cdnjs.cloudflare.com cdn.jsdelivr.net fonts.googleapis.com cdn.datatables.net; script-src 'self' 'unsafe-inline' ajax.googleapis.com cdnjs.cloudflare.com maxcdn.bootstrapcdn.com cdn.jsdelivr.net cdn.datatables.net;"
Header always set X-Content-Type-Options nosniff
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header always append X-Frame-Options SAMEORIGIN
Header set Cache-Control "no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires 0
### set only for webapps
Header add Access-Control-Allow-Origin "s3.amazonaws.com uatdomainplus.com qadomainplus.com hci.com typekit.net cdnjs.cloudflare.com fonts.gstatic.com hcidomain.plus uatdomainplus.com qadomainplus.com cdn.datatables.net"
Header always set Access-Control-Allow-Methods "POST,GET,OPTIONS,PUT,PATCH,DELETE"
Header always set Access-Control-Max-Age "3600"
Header always set Access-Control-Allow-Headers "Content-Type,Authorization"
Header always set Cross-Origin-Embedder-Policy: require-corp
Header always set Cross-Origin-Opener-Policy: same-origin
Header always set Cross-Origin-Resource-Policy: cross-origin
Related
I have the following setup in my apache conf for security:
Header always append X-Frame-Options SAMEORIGIN
Header always set X-XSS-Protection "1; mode=block"
Header always set X-Content-Type-Options: nosniff
Header set Content-Security-Policy "default-src 'self' 'unsafe-inline' gatewayt.moneries.com 'unsafe-eval';"
Header always set Referrer-Policy: strict-origin-when-cross-origin
I have 2 different errors for 2 different applications. I just want to allow moneries and gooleapis to be able to run scripts and style sheets from my apache server.
1.
Refused to load the script 'https://gatewayt.moneris.com/chkt/js/chkt_v1.00.js' because it violates the following Content Security Policy directive: "default-src 'self' 'unsafe-inline' gatewayt.moneries.com 'unsafe-eval'". Note that 'script-src-elem' was not explicitly set, so 'default-src' is used as a fallback.
Refused to load the stylesheet 'https://fonts.googleapis.com/css?family=Droid+Sans:400,700' because it violates the following Content Security Policy directive: "default-src 'self' 'unsafe-inline' ottawa.ca 'unsafe-eval'". Note that 'style-src-elem' was not explicitly set, so 'default-src' is used as a fallback.
<SERVER DOMAIN NAME>/:1 Refused to load the stylesheet 'https://fonts.googleapis.com/css?family=Droid+Sans:400,700' because it violates the following Content Security Policy directive: "default-src 'self' 'unsafe-inline' ottawa.ca 'unsafe-eval'". Note that 'style-src-elem' was not explicitly set, so 'default-src' is used as a fallback.
I'm actually encounter a problem with Nextcloud 14 (clean install)
There are some warnings regarding your setup.
Use of the the built in php mailer is no longer supported. Please update >your email server settings ↗.
The "X-XSS-Protection" HTTP header is not set to "1; mode=block". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.
The "X-Content-Type-Options" HTTP header is not set to "nosniff". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.
The "Referrer-Policy" HTTP header is not set to "no-referrer", "no-referrer-when-downgrade", "strict-origin" or "strict-origin-when-cross-origin". This can leak referer information. See the W3C Recommendation ↗.
Example
Like you could see above nextcloud explicitly say than i don't have this header correctly configured :
But in my httpd.conf (I Use Arch BTW <3 ) :
Header always set Content-Security-Policy "upgrade-insecure-requests"
Header always set Referrer-Policy "same-origin"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-XSS-Protection "1; mode=block"
Header always set X-content-Type-Options "nosniff"
Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
I don't understand why it's not working, I even tried see which header are used and this header is used :
Request URL: https://cloud.schmitt-etienne.fr/index.php/settings/admin/overview
Request Method: GET
Status Code: 200
Remote Address: [2a01:e34:eeab:eb60:ffff:ffff:ffff:ffff]:443
Referrer Policy: no-referrer
cache-control: no-cache, no-store, must-revalidate
content-length: 27725
content-security-policy: upgrade-insecure-requests
content-type: text/html; charset=UTF-8
date: Wed, 12 Sep 2018 18:22:45 GMT
expires: Thu, 19 Nov 1981 08:52:00 GMT
pragma: no-cache
referrer-policy: same-origin
server: Apache
status: 200
strict-transport-security: max-age=15768000; includeSubDomains; preload
x-content-type-options: nosniff
x-content-type-options: nosniff
x-download-options: noopen
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-powered-by: PHP/7.2.10
x-robots-tag: none
x-xss-protection: 1; mode=block
x-xss-protection: 1; mode=block
:authority: cloud.schmitt-etienne.fr
:method: GET
:path: /index.php/settings/admin/overview
:scheme: https
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
accept-encoding: gzip, deflate, br
accept-language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7
cache-control: max-age=0
cookie:
upgrade-insecure-requests: 1
You could go see my website yourself if you want to see yourself :
If i miss anything I missed I'm happy to hear any comment !
Have a nice day :)
I just found than nextcloud come included with a .htaccess who set his own header, so the headers was send two times and that was the cause :)
Never stop trying and learning !
General:
Request URL:x/site.php
Request Method:OPTIONS
Status Code:302 Found
Remote Address:x.x.x.x:80
Response Headers:
view source
Access-Control-Allow-Headers:Content-Type
Access-Control-Allow-Origin:*
Access-Control-Max-Age:300
Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Length:0
Content-Type:text/html; charset=UTF-8
Date:Thu, 02 Mar 2017 14:27:21 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Location:y
Pragma:no-cache
Server:Apache/2.4.25 (Ubuntu)
Request Headers:
view source
Accept:*/*
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Access-Control-Request-Headers:authorization
Access-Control-Request-Method:POST
Cache-Control:no-cache
Connection:keep-alive
DNT:1
Host:x
Origin:http://127.0.0.1:3000
Pragma:no-cache
Referer:http://127.0.0.1:3000/
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.90 Safari/537.36
Apache virtualhost config looks as so:
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "http://127.0.0.1:3000"
Header set Access-Control-Allow-Origin "http://127.0.0.1"
Header set Access-Control-Max-Age "300"
Header set Access-Control-Allow-Credentials "true"
Header set Access-Control-Allow-Headers "Origin, X-Requested-With, Content-Type, Accept"
Header set Access-Control-Allow-Methods "POST, GET, PUT, DELETE, PATCH, OPTIONS"
</IfModule>
The preflight request is skipping the apache config and hitting my webapp directly, which does a redirect (hence the 302 and the location: y).
I don't know why the preflight request is not being handled by apache?
To fully CORS-enable an Apache web server, you need to have it configured to look like this:
Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Headers "Authorization"
Header always set Access-Control-Allow-Methods "GET"
Header always set Access-Control-Expose-Headers "Content-Security-Policy, Location"
Header always set Access-Control-Max-Age "600"
RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]
Longer explanation at https://benjaminhorn.io/code/setting-cors-cross-origin-resource-sharing-on-apache-with-correct-response-headers-allowing-everything-through/
Some general notes on what values to set for the various Access-Control- response headers:
Access-Control-Allow-Headers: you must set it to include any header names your request sends except CORS-safelisted header names or so-called “forbidden” header names (names of headers set by the browser that you can’t set in your JavaScript); the spec alternatively allows the * wildcard as its value—so you can try it, though some browsers may not support it yet: Chrome bug, Firefox bug, Safari bug.
Access-Control-Allow-Methods: the spec alternatively allows the * wildcard—but again, as with Access-Control-Allow-Headers: *, some browsers may not support it yet.
Access-Control-Expose-Headers: set to include any response headers beyond Expires, Cache-Control, Content-Type, Pragma, Last-Modified, and Content-Language that your frontend code needs to read. A lot of people forget to set this and end up baffled about why they can’t read the value of a particular response header). Again the spec alternatively allows the * wildcard here, but some browsers may not support it yet.
Access-Control-Max-Age: Chrome has an upper limit of 600 (10 minutes) hardcoded, so there’s no point in setting a higher value for it than that (Chrome will just throttle it down to 10 minutes if you set it higher, and Safari limits it to only 5 minutes).
So then, about the particular request shown in the question, the specific changes and additions that would need to made are these:
Use Header always set instead of just Header set.
Use mod_rewrite to handle the OPTIONS by just sending back 200 OK with those headers.
The request has Access-Control-Request-Headers:authorization so in the Apache config, add Authorization in the Access-Control-Allow-Headers response header too.
Origin is a “forbidden” header name set by the browser, and Accept is a CORS-safelisted header name, so no need to include them in Access-Control-Allow-Headers.
The request sends no Content-Type, so no need for it in Access-Control-Allow-Headers in the response (and never needed for GET requests and otherwise only needed if the type is not application/x-www-form-urlencoded, text/plain, or multipart/form-data).
For Access-Control-Allow-Methods, the request seems to just be a GET, so unless the plan’s to also make POST/PUT/DELETE/PATCH requests, no point in including them.
I have a CloudFront distribution that blocks the font download in Chrome (desktop version) with the fallowing error:
Font from origin 'https://....cloudfront.net' has been blocked from
loading by Cross-Origin Resource Sharing policy: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'https://example.com' is therefore not allowed
access.
Where should I set this Access-Control-Allow-Origin header?
I tried adding the header in the "Origin" section of the could distribution but it does not produce any effect.
EDIT #1:
Nginx configuration on origin has the fallowing directive:
location ~ \.(eot|ttf|woff|woff2)$ {
add_header Access-Control-Allow-Origin *;
}
which on this test curl -I https://example.com/skin/frontend/smartwave/default/megamenu/css/fonts/fontawesome-webfont.woff
Retuns the fallowing response:
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 02 Feb 2016 17:53:39 GMT
Content-Type: application/font-woff
Content-Length: 44432
Last-Modified: Wed, 13 May 2015 15:58:11 GMT
Connection: keep-alive
ETag: "55537493-ad90"
Pragma: public
Cache-Control: max-age=31536000, public, must-revalidate, proxy-revalidate
Accept-Ranges: bytes
From what I see here this header Access-Control-Allow-Origin is missing.
Also I whitelisted the header on CloudFront so that it will not block it:
That was hard to trace as the rules for headers were set in 2 different locations and not in one.
Fixing the correct header for the correct type of file did the job, but you have to consider the fact that in some locations trying to overwrite the NGINX rules does not work. It will only consider the first rule.
A comprehensive description of headers can be found here https://stackoverflow.com/a/10636765/1168944
Given these request headers:
Host: api.example.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:41.0) Gecko/20100101 Firefox/41.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Origin: https://web.example.org
Access-Control-Request-Method: GET
Access-Control-Request-Headers: authorization
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
And these response headers:
Connection: keep-alive
Content-Length: 0
Content-Type: text/plain; charset=utf-8
Date: Tue, 13 Oct 2015 10:57:34 GMT
Server: nginx/1.8.0
access-control-allow-headers: Authorization, Content-Type
access-control-allow-methods: PUT, DELETE, PATCH
access-control-allow-origin: *
This works even though only the Authorization and Content-Type headers are explicitly allowed. Why didn't I have to allow other headers that my browser sends? (like DNT for example)
Update: this MDN page contains an overview of simple headers (default CORS-safelisted request headers):
A simple header (or CORS-safelisted request header) is one of the
following HTTP headers:
Accept
Accept-Language
Content-Language
Content-Type with a MIME type of its parsed value (ignoring parameters) of either application/x-www-form-urlencoded, multipart/form-data, or text/plain.
Or one of these client hint headers:
DPR
Downlink
Save-Data
Viewport-Width
Width
Without seeing your code to generate the headers, or on which system you are serving from, i.e. nginx or apache, the best I can do is refer you to http://client.cors-api.appspot.com/client which will allow you to test your CORS requests. Also, you should look at http://enable-cors.org/server.html for your specific setup. For instance on nginx, you could have something like this
add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
There is a set of normal headers, and then the set of headers that you have to explicitly call out. see http://www.html5rocks.com/en/tutorials/cors/#toc-adding-cors-support-to-the-server about setting it up on a server.
The Access-Control-Allow-Headers is attached by backend, you cannot control that header on client side.Access-Control-Allow-Headers should be returned in response object.
So to include other headers into Access-Control-Allow-Headers header in response object - you have to configure your web server or update backend application which serves requests to attach desired value of Access-Control-Allow-Headers to each request.
To allow any headers in your client requests server should add Access-Control-Allow-Origin: * header to each response.
There are a lot of articles and info of how you can setup CORS to work in the way you want. For example that one - Enabling CORS