Correct S3 + Cloudfront CORS Configuration? - amazon-s3
My application stores images on S3 and then proxies them through Cloudfront. I'm excited to use the new S3 CORS support so that I can use HTML5 canvas methods (which have a cross-origin policy) but can't seem to configure my S3 and Cloudfront correctly. Still running into "Uncaught Error: SECURITY_ERR: DOM Exception 18" when I try to convert an image to a canvas element.
Here's what I have so far:
S3
<CORSConfiguration>
<CORSRule>
<AllowedOrigin>MY_WEBSITE_URL</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
<MaxAgeSeconds>3000</MaxAgeSeconds>
<AllowedHeader>*</AllowedHeader>
</CORSRule>
<CORSRule>
<AllowedOrigin>MY_CLOUDFRONT_URL</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
<AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>
Cloudfront
Origins
Origin Protocol Policy: Match Viewer
HTTP Port: 80
HTTPS Port: 443
Behaviors
Origin: MY_WEBSITE_URL
Object Caching: Use Origin Cache Headers
Forward Cookies: None
Forward Query Strings: Yes
Is there something I'm missing here?
UPDATE :
Just tried changing the headers to
<AllowedHeader>Content-*</AllowedHeader>
<AllowedHeader>Host</AllowedHeader>
based on this question Amazon S3 CORS (Cross-Origin Resource Sharing) and Firefox cross-domain font loading
Still no go.
UPDATE: MORE INFO ON REQUEST
Request
URL:https://d1r5nr1emc2xy5.cloudfront.net/uploaded/BAhbBlsHOgZmSSImMjAxMi8wOS8xMC8xOC81NC80Mi85NC9ncmFzczMuanBnBjoGRVQ/32c0cee8
Request Method:GET
Status Code:200 OK (from cache)
UPDATE
I think maybe my request wasn't correct, so I tried enabling CORS with
img.crossOrigin = '';
but then the image doesn't load and I get the error: Cross-origin image load denied by Cross-Origin Resource Sharing policy.
On June 26, 2014 AWS released proper Vary: Origin behavior on CloudFront so now you just
Set a CORS Configuration for your S3 bucket including
<AllowedOrigin>*</AllowedOrigin>
In CloudFront -> Distribution -> Behaviors for this origin
Allowed HTTP Methods: +OPTIONS
Cached HTTP Methods +OPTIONS
Cache Based on Selected Request Headers: Whitelist the Origin header.
Wait for ~20 minutes while CloudFront propagates the new rule
Now your CloudFront distribution should cache different responses (with proper CORS headers) for different client Origin headers.
To complement #Brett's answer. There are AWS documentation pages detailing CORS on CloudFront and CORS on S3.
The steps detailed there are as follows:
In your S3 bucket go to Permissions -> CORS configuration
Add rules for CORS in the editor, the <AllowedOrigin> rule is the important one. Save the configuration.
In your CloudFront distribution go to Behavior -> choose a behavior -> Edit
Depending on whether you want OPTIONS responses cached or not, there are two ways according to AWS:
If you want OPTIONS responses to be cached, do the following:
Choose the options for default cache behavior settings that enable caching for OPTIONS responses.
Configure CloudFront to forward the following headers: Origin, Access-Control-Request-Headers, and Access-Control-Request-Method.
If you don't want OPTIONS responses to be cached, configure CloudFront
to forward the Origin header, together with any other headers required
by your origin
And with that CORS from CloudFront with S3 should work.
2022 answer:
Go to your S3 bucket -> Permissions
Scroll down to Cross-origin resource sharing (CORS)
Apply policy:
[
{
"AllowedHeaders": [],
"AllowedMethods": [
"GET"
],
"AllowedOrigins": [
"*"
],
"ExposeHeaders": []
}
]
This will allow GET request from all origins. Modify according to your project's needs.
Go to your CloudFront distribution -> Behaviors -> Edit (in my case I had only one Behavior)
Scroll down to Cache key and origin requests
Select Cache policy and origin request policy (recommended)
Under Origin request policy - optional select CORS-CustomOrigin
Save Changes
Done!
UPDATE: this is no longer true with recent changes on CloudFront. Yippee! See the other responses for the details. I'm leaving this here for context/history.
Problem
CloudFront does not support CORS 100%. The problem is how CloudFront caches the response to the request. Any other request for the same URL after that will result in the cached request no matter the origin. The key part about that is that it includes the response headers from the origin.
First request before CloudFront has anything cached from Origin: http://example.com has a response header of:
Access-Control-Allow-Origin: http://example.com
Second request from Origin: https://example.com (note that it is HTTPS not HTTP) also has the response header of:
Access-Control-Allow-Origin: http://example.com
Because that is what CloudFront cached for the URL. This is invalid -- the browser console (in Chrome at least) will show a CORS violation message and things will break.
Workaround
The suggested work around is to use different URLs for different origins. The trick is to append a unique query string that is different so that there is one cached record per origin.
So our URLs would be something like:
http://.../some.png?http_mysite.com
https://.../some.png?https_mysite.com
This kind of works but anyone can make your site work poorly by swapping the querystrings. Is that likely? Probably not but debugging this issue is a huge hassle.
The right workaround is to not use CloudFront with CORS until they fully support CORS.
In Practice
If you use CloudFront for CORS, have a fallback to another method that will work when CORS does not. This isn't always an option but right now I'm dynamically loading fonts with JavaScript. If the CORS-based request to CloudFront fails, I fall back to a server-side proxy to the fonts (not cross origin). This way, things keep working even though CloudFront somehow got a bad cached record for the font.
As a completion on the previous answer, I would like to share AWS steps on how to enable CORS. I found it very useful, providing additional links: https://aws.amazon.com/premiumsupport/knowledge-center/no-access-control-allow-origin-error/
Also, something that you should consider when testing your changes, other than CloudFront deploy delay, is the browser cache. I suggest using different sessions for incognito when testing your changes.
Posting some of the non-trivial configurations that I did to make it work:
Assign custom domain to cloudfront such that the custom domain is a subdomain from where your app's frontend will run. In OP's case, he is using localhost:3000; most probably he is testing on his dev setup, but he must deploy this app at some domain: let's call this 'myapp.com'. So, he can assign a custom domain, say cdn.myapp.com to point to blah.cloudfront.net. You will need to create/import custom SSL certificate for the new custom domain; default cloudfront certificate won't work.
Refer to this: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html
In the Cloudfront Distribution snap, the first row is having no custom domain, hence an empty CNAMEs column. The second one is having a custom domain, hence we have that one printed over there. You can verify that your custom domain got pointed to the cloudfront distribution this way.
Cloudfront behaviour: I am assuming you have already set up trusted key group as at this point, you already have the signed cookie with you. HOWEVER, You will need to create custom Cache Policy and Origin Request Policy. See the following screenshots of the custom Cache Policy:and Origin Request Policy: The thing to notice is that you will need to whitelist these Headers: Origin, Access-Control-Request-Method, Access-Control-Allow-Origin, Access-Control-Request-Headers. (You might notice that Access-Control-Allow-Origin is not in the dropdown; just go ahead and type it!). Also, allow all cookies.
S3 CORS configuration: Go to the S3 bucket and click on the permissions tab. Scroll down to the CORS configuration. Disclaimer: I just pasted what worked for me. The rationale behind this was that this S3 was going to be accessed by either CDN or app in my scenario. I tried putting '*' being lenient, but CORS policy on Chrome complained that I cannot use a wildcard entry in AllowedOrigins!
[
{
"AllowedHeaders": [
"*"
],
"AllowedMethods": [
"PUT",
"POST",
"GET",
"HEAD",
"DELETE"
],
"AllowedOrigins": [
"cdn.myapp.com",
"myapp.com",
"https://cdn.myapp.com",
"https://myapp.com"
],
"ExposeHeaders": [
"ETag"
]
}
]
react-player: I am using react-player like this (note forceHLS option being set, but it is again specific to my use case. I think this is not mandatory in general)
<ReactPlayer
className="react-player"
url={url}
controls={controls}
light={light}
config={
{
file: {
forceHLS: true,
hlsOptions: {
xhrSetup: function (xhr, url) {
xhr.withCredentials = true; // send cookies
},
},
},
}
}
playIcon={<PlayIcon />}
width="100%"
height="100%"
/>
I followed AWS documentation:
CloudFront- CORS
S3- CORS
Then I used aws cdk to do it for me. Full source here: https://github.com/quincycs/quincymitchell.com
const myBucket = new Bucket(this, 'bucket', {
bucketName: `prod-${domainName}`,
cors: [{
allowedMethods: [HttpMethods.GET],
allowedOrigins: ['*'],
allowedHeaders: ['*']
}],
enforceSSL: true,
blockPublicAccess: BlockPublicAccess.BLOCK_ALL,
removalPolicy: RemovalPolicy.RETAIN
});
const mycert = Certificate.fromCertificateArn(this, 'certificate', ssmCertArn);
new Distribution(this, 'myDist', {
defaultBehavior: {
origin: new S3Origin(myBucket),
viewerProtocolPolicy: ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
originRequestPolicy: OriginRequestPolicy.CORS_S3_ORIGIN,
responseHeadersPolicy: ResponseHeadersPolicy.CORS_ALLOW_ALL_ORIGINS,
allowedMethods: AllowedMethods.ALLOW_GET_HEAD_OPTIONS, // needed for cors
cachedMethods: CachedMethods.CACHE_GET_HEAD_OPTIONS, // needed for cors
},
defaultRootObject: 'index.html',
domainNames: [domainName, `www.${domainName}`],
certificate: mycert
});
An additional reason for CORS errors could be the HTTP to HTTPS redirect configured in CloudFront.
According to documentation redirects to different origin are not allowed in CORS requests.
As an example, if you will try to access some URL http://example.com what has cloudfront rule to redirect HTTP to HTTPS, you will get a CORS error, since https://cloudfront.url is considered by the browser as a different origin.
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSExternalRedirectNotAllowed
Related
Can't use swagger ui in chrome and intellij idea due to CORS [duplicate]
Apparently, I have completely misunderstood its semantics. I thought of something like this: A client downloads JavaScript code MyCode.js from http://siteA - the origin. The response header of MyCode.js contains Access-Control-Allow-Origin: http://siteB, which I thought meant that MyCode.js was allowed to make cross-origin references to the site B. The client triggers some functionality of MyCode.js, which in turn make requests to http://siteB, which should be fine, despite being cross-origin requests. Well, I am wrong. It does not work like this at all. So, I have read Cross-origin resource sharing and attempted to read Cross-Origin Resource Sharing in w3c recommendation. One thing is sure - I still do not understand how I am supposed to use this header. I have full control of both site A and site B. How do I enable the JavaScript code downloaded from the site A to access resources on the site B using this header? P.S.: I do not want to utilize JSONP.
Access-Control-Allow-Origin is a CORS (cross-origin resource sharing) header. When Site A tries to fetch content from Site B, Site B can send an Access-Control-Allow-Origin response header to tell the browser that the content of this page is accessible to certain origins. (An origin is a domain, plus a scheme and port number.) By default, Site B's pages are not accessible to any other origin; using the Access-Control-Allow-Origin header opens a door for cross-origin access by specific requesting origins. For each resource/page that Site B wants to make accessible to Site A, Site B should serve its pages with the response header: Access-Control-Allow-Origin: http://siteA.com Modern browsers will not block cross-domain requests outright. If Site A requests a page from Site B, the browser will actually fetch the requested page on the network level and check if the response headers list Site A as a permitted requester domain. If Site B has not indicated that Site A is allowed to access this page, the browser will trigger the XMLHttpRequest's error event and deny the response data to the requesting JavaScript code. Non-simple requests What happens on the network level can be slightly more complex than explained above. If the request is a "non-simple" request, the browser first sends a data-less "preflight" OPTIONS request, to verify that the server will accept the request. A request is non-simple when either (or both): using an HTTP verb other than GET or POST (e.g. PUT, DELETE) using non-simple request headers; the only simple requests headers are: Accept Accept-Language Content-Language Content-Type (this is only simple when its value is application/x-www-form-urlencoded, multipart/form-data, or text/plain) If the server responds to the OPTIONS preflight with appropriate response headers (Access-Control-Allow-Headers for non-simple headers, Access-Control-Allow-Methods for non-simple verbs) that match the non-simple verb and/or non-simple headers, then the browser sends the actual request. Supposing that Site A wants to send a PUT request for /somePage, with a non-simple Content-Type value of application/json, the browser would first send a preflight request: OPTIONS /somePage HTTP/1.1 Origin: http://siteA.com Access-Control-Request-Method: PUT Access-Control-Request-Headers: Content-Type Note that Access-Control-Request-Method and Access-Control-Request-Headers are added by the browser automatically; you do not need to add them. This OPTIONS preflight gets the successful response headers: Access-Control-Allow-Origin: http://siteA.com Access-Control-Allow-Methods: GET, POST, PUT Access-Control-Allow-Headers: Content-Type When sending the actual request (after preflight is done), the behavior is identical to how a simple request is handled. In other words, a non-simple request whose preflight is successful is treated the same as a simple request (i.e., the server must still send Access-Control-Allow-Origin again for the actual response). The browsers sends the actual request: PUT /somePage HTTP/1.1 Origin: http://siteA.com Content-Type: application/json { "myRequestContent": "JSON is so great" } And the server sends back an Access-Control-Allow-Origin, just as it would for a simple request: Access-Control-Allow-Origin: http://siteA.com See Understanding XMLHttpRequest over CORS for a little more information about non-simple requests.
Cross-Origin Resource Sharing - CORS (A.K.A. Cross-Domain AJAX request) is an issue that most web developers might encounter, according to Same-Origin-Policy, browsers restrict client JavaScript in a security sandbox, usually JS cannot directly communicate with a remote server from a different domain. In the past developers created many tricky ways to achieve Cross-Domain resource request, most commonly using ways are: Use Flash/Silverlight or server side as a "proxy" to communicate with remote. JSON With Padding (JSONP). Embeds remote server in an iframe and communicate through fragment or window.name, refer here. Those tricky ways have more or less some issues, for example JSONP might result in security hole if developers simply "eval" it, and #3 above, although it works, both domains should build strict contract between each other, it neither flexible nor elegant IMHO:) W3C had introduced Cross-Origin Resource Sharing (CORS) as a standard solution to provide a safe, flexible and a recommended standard way to solve this issue. The Mechanism From a high level we can simply deem CORS as a contract between client AJAX call from domain A and a page hosted on domain B, a typical Cross-Origin request/response would be: DomainA AJAX request headers Host DomainB.com User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0 Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,application/json Accept-Language en-us; Accept-Encoding gzip, deflate Keep-Alive 115 Origin http://DomainA.com DomainB response headers Cache-Control private Content-Type application/json; charset=utf-8 Access-Control-Allow-Origin DomainA.com Content-Length 87 Proxy-Connection Keep-Alive Connection Keep-Alive The blue parts I marked above were the kernal facts, "Origin" request header "indicates where the cross-origin request or preflight request originates from", the "Access-Control-Allow-Origin" response header indicates this page allows remote request from DomainA (if the value is * indicate allows remote requests from any domain). As I mentioned above, W3 recommended browser to implement a "preflight request" before submiting the actually Cross-Origin HTTP request, in a nutshell it is an HTTP OPTIONS request: OPTIONS DomainB.com/foo.aspx HTTP/1.1 If foo.aspx supports OPTIONS HTTP verb, it might return response like below: HTTP/1.1 200 OK Date: Wed, 01 Mar 2011 15:38:19 GMT Access-Control-Allow-Origin: http://DomainA.com Access-Control-Allow-Methods: POST, GET, OPTIONS, HEAD Access-Control-Allow-Headers: X-Requested-With Access-Control-Max-Age: 1728000 Connection: Keep-Alive Content-Type: application/json Only if the response contains "Access-Control-Allow-Origin" AND its value is "*" or contain the domain who submitted the CORS request, by satisfying this mandtory condition browser will submit the actual Cross-Domain request, and cache the result in "Preflight-Result-Cache". I blogged about CORS three years ago: AJAX Cross-Origin HTTP request
According to this Mozilla Developer Network article, A resource makes a cross-origin HTTP request when it requests a resource from a different domain, or port than the one which the first resource itself serves. An HTML page served from http://domain-a.com makes an <img> src request for http://domain-b.com/image.jpg. Many pages on the web today load resources like CSS style sheets, images and scripts from separate domains (thus it should be cool). Same-Origin Policy For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest and Fetch follow the same-origin policy. So, a web application using XMLHttpRequest or Fetch could only make HTTP requests to its own domain. Cross-Origin Resource Sharing (CORS) To improve web applications, developers asked browser vendors to allow cross-domain requests. The Cross-origin resource sharing (CORS) mechanism gives web servers cross-domain access controls, which enable secure cross-domain data transfers. Modern browsers use CORS in an API container - such as XMLHttpRequest or fetch - to mitigate risks of cross-origin HTTP requests. How CORS works (Access-Control-Allow-Origin header) Wikipedia: The CORS standard describes new HTTP headers which provide browsers and servers a way to request remote URLs only when they have permission. Although some validation and authorization can be performed by the server, it is generally the browser's responsibility to support these headers and honor the restrictions they impose. Example The browser sends the OPTIONS request with an Origin HTTP header. The value of this header is the domain that served the parent page. When a page from http://www.example.com attempts to access a user's data in service.example.com, the following request header would be sent to service.example.com: Origin: http://www.example.com The server at service.example.com may respond with: An Access-Control-Allow-Origin (ACAO) header in its response indicating which origin sites are allowed. For example: Access-Control-Allow-Origin: http://www.example.com An error page if the server does not allow the cross-origin request An Access-Control-Allow-Origin (ACAO) header with a wildcard that allows all domains: Access-Control-Allow-Origin: *
Whenever I start thinking about CORS, my intuition about which site hosts the headers is incorrect, just as you described in your question. For me, it helps to think about the purpose of the same-origin policy. The purpose of the same-origin policy is to protect you from malicious JavaScript on siteA.com accessing private information you've chosen to share only with siteB.com. Without the same-origin policy, JavaScript written by the authors of siteA.com could have your browser make requests to siteB.com, using your authentication cookies for siteB.com. In this way, siteA.com could steal the secret information you share with siteB.com. Sometimes you need to work cross domain, which is where CORS comes in. CORS relaxes the same-origin policy for siteB.com, using the Access-Control-Allow-Origin header to list other domains (siteA.com) that are trusted to run JavaScript that can interact with siteB.com. To understand which domain should serve the CORS headers, consider this. You visit malicious.com, which contains some JavaScript that tries to make a cross domain request to mybank.com. It should be up to mybank.com, not malicious.com, to decide whether or not it sets CORS headers that relax the same-origin policy, allowing the JavaScript from malicious.com to interact with it. If malicous.com could set its own CORS headers allowing its own JavaScript access to mybank.com, this would completely nullify the same-origin policy. I think the reason for my bad intuition is the point of view I have when developing a site. It's my site, with all my JavaScript. Therefore, it isn't doing anything malicious, and it should be up to me to specify which other sites my JavaScript can interact with. When in fact I should be thinking: Which other sites' JavaScript are trying to interact with my site and should I use CORS to allow them?
From my own experience, it's hard to find a simple explanation why CORS is even a concern. Once you understand why it's there, the headers and discussion becomes a lot clearer. I'll give it a shot in a few lines. It's all about cookies. Cookies are stored on a client by their domain. An example story: On your computer, there's a cookie for yourbank.com. Maybe your session is in there. Key point: When a client makes a request to the server, it will send the cookies stored under the domain for that request. You're logged in on your browser to yourbank.com. You request to see all your accounts, and cookies are sent for yourbank.com. yourbank.com receives the pile of cookies and sends back its response (your accounts). If another client makes a cross origin request to a server, those cookies are sent along, just as before. Ruh roh. You browse to malicious.com. Malicious makes a bunch of requests to different banks, including yourbank.com. Since the cookies are validated as expected, the server will authorize the response. Those cookies get gathered up and sent along - and now, malicious.com has a response from yourbank. Yikes. So now, a few questions and answers become apparent: "Why don't we just block the browser from doing that?" Yep. That's CORS. "How do we get around it?" Have the server tell the request that CORS is OK.
1. A client downloads javascript code MyCode.js from http://siteA - the origin. The code that does the downloading - your html script tag or xhr from javascript or whatever - came from, let's say, http://siteZ. And, when the browser requests MyCode.js, it sends an Origin: header saying "Origin: http://siteZ", because it can see that you're requesting to siteA and siteZ != siteA. (You cannot stop or interfere with this.) 2. The response header of MyCode.js contains Access-Control-Allow-Origin: http://siteB, which I thought meant that MyCode.js was allowed to make cross-origin references to the site B. no. It means, Only siteB is allowed to do this request. So your request for MyCode.js from siteZ gets an error instead, and the browser typically gives you nothing. But if you make your server return A-C-A-O: siteZ instead, you'll get MyCode.js . Or if it sends '*', that'll work, that'll let everybody in. Or if the server always sends the string from the Origin: header... but... for security, if you're afraid of hackers, your server should only allow origins on a shortlist, that are allowed to make those requests. Then, MyCode.js comes from siteA. When it makes requests to siteB, they are all cross-origin, the browser sends Origin: siteA, and siteB has to take the siteA, recognize it's on the short list of allowed requesters, and send back A-C-A-O: siteA. Only then will the browser let your script get the result of those requests.
Using React and Axios, join a proxy link to the URL and add a header as shown below: https://cors-anywhere.herokuapp.com/ + Your API URL Just adding the proxy link will work, but it can also throw an error for No Access again. Hence it is better to add a header as shown below. axios.get(`https://cors-anywhere.herokuapp.com/[YOUR_API_URL]`,{headers: {'Access-Control-Allow-Origin': '*'}}) .then(response => console.log(response:data); } Warning: Not to be used in production This is just a quick fix. If you're struggling with why you're not able to get a response, you can use this. But again it's not the best answer for production.
If you are using PHP, try adding the following code at the beginning of the php file: If you are using localhost, try this: header("Access-Control-Allow-Origin: *"); If you are using external domains such as server, try this: header("Access-Control-Allow-Origin: http://www.website.com");
I worked with Express.js 4, Node.js 7.4 and Angular, and I had the same problem. This helped me: a) server side: in file app.js I add headers to all responses, like: app.use(function(req, res, next) { res.header('Access-Control-Allow-Origin', req.headers.origin); res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept"); next(); }); This must be before all routes. I saw a lot of added this headers: res.header("Access-Control-Allow-Headers","*"); res.header('Access-Control-Allow-Credentials', true); res.header('Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE'); But I don’t need that, b) client side: in sending by Ajax, you need to add "withCredentials: true," like: $http({ method: 'POST', url: 'url', withCredentials: true, data : {} }).then(function(response){ // Code }, function (response) { // Code });
If you want just to test a cross-domain application in which the browser blocks your request, then you can just open your browser in unsafe mode and test your application without changing your code and without making your code unsafe. From macOS, you can do this from the terminal line: open -a Google\ Chrome --args --disable-web-security --user-data-dir
In Python, I have been using the Flask-CORS library with great success. It makes dealing with CORS super easy and painless. I added some code from the library's documentation below. Installing: pip install -U flask-cors Simple example that allows CORS for all domains on all routes: from flask import Flask from flask_cors import CORS app = Flask(__name__) CORS(app) #app.route("/") def helloWorld(): return "Hello, cross-origin-world!" For more specific examples, see the documentation. I have used the simple example above to get around the CORS issue in an Ionic application I am building that has to access a separate flask server.
Simply paste the following code in your web.config file. Noted that, you have to paste the following code under <system.webServer> tag <httpProtocol> <customHeaders> <add name="Access-Control-Allow-Origin" value="*" /> <add name="Access-Control-Allow-Headers" value="Content-Type" /> <add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" /> </customHeaders> </httpProtocol>
I can't configure it on the back-end server, but with these extensions in the browsers, it works for me: For Firefox: CORS Everywhere For Google Chrome: Allow CORS: Access-Control-Allow-Origin Note: CORS works for me with this configuration:
For cross origin sharing, set header: 'Access-Control-Allow-Origin':'*'; Php: header('Access-Control-Allow-Origin':'*'); Node: app.use('Access-Control-Allow-Origin':'*'); This will allow to share content for different domain.
Nginx and Apache As an addition to apsiller's answer, I would like to add a wiki graph which shows when a request is simple or not (and OPTIONS pre-flight request is send or not) For a simple request (e.g., hotlinking images), you don't need to change your server configuration files, but you can add headers in the application (hosted on the server, e.g., in PHP) like Melvin Guerrero mentions in his answer - but remember: if you add full CORS headers in your server (configuration) and at same time you allow simple CORS in the application (e.g., PHP), this will not work at all. And here are configurations for two popular servers: turn on CORS on Nginx (nginx.conf file) location ~ ^/index\.php(/|$) { ... add_header 'Access-Control-Allow-Origin' "$http_origin" always; # if you change "$http_origin" to "*" you shoud get same result - allow all domain to CORS (but better change it to your particular domain) add_header 'Access-Control-Allow-Credentials' 'true' always; if ($request_method = OPTIONS) { add_header 'Access-Control-Allow-Origin' "$http_origin"; # DO NOT remove THIS LINES (doubled with outside 'if' above) add_header 'Access-Control-Allow-Credentials' 'true'; add_header 'Access-Control-Max-Age' 1728000; # cache preflight value for 20 days add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; # arbitrary methods add_header 'Access-Control-Allow-Headers' 'My-First-Header,My-Second-Header,Authorization,Content-Type,Accept,Origin'; # arbitrary headers add_header 'Content-Length' 0; add_header 'Content-Type' 'text/plain charset=UTF-8'; return 204; } } turn on CORS on Apache (.htaccess file) # ------------------------------------------------------------------------------ # | Cross-domain Ajax requests | # ------------------------------------------------------------------------------ # Enable cross-origin Ajax requests. # http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity # http://enable-cors.org/ # change * (allow any domain) below to your domain Header set Access-Control-Allow-Origin "*" Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT" Header always set Access-Control-Allow-Headers "My-First-Header,My-Second-Header,Authorization, content-type, csrf-token" Header always set Access-Control-Allow-Credentials "true"
The Access-Control-Allow-Origin response header indicates whether the response can be shared with requesting code from the given origin. Header type Response header ------------------------------------------- Forbidden header name no A response that tells the browser to allow code from any origin to access a resource will include the following: Access-Control-Allow-Origin: * For more information, visit Access-Control-Allow-Origin...
For .NET Core 3.1 API With Angular Startup.cs : Add CORS //SERVICES public void ConfigureServices(IServiceCollection services){ //CORS (Cross Origin Resource Sharing) //===================================== services.AddCors(); } //MIDDLEWARES public void Configure(IApplicationBuilder app, IWebHostEnvironment env) { app.UseRouting(); //ORDER: CORS -> Authentication -> Authorization) //CORS (Cross Origin Resource Sharing) //===================================== app.UseCors(x=>x.AllowAnyHeader().AllowAnyMethod().WithOrigins("http://localhost:4200")); app.UseHttpsRedirection(); } } Controller : Enable CORS For Authorized Controller //Authorize all methods inside this controller [Authorize] [EnableCors()] public class UsersController : ControllerBase { //ActionMethods }
Note: Only a temporary solution for testing For those who can't control the backend for Options 405 Method Not Allowed, here is a workaround for theChrome browser. Execute in the command line: "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir="path_to_profile" Example: "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir="C:\Users\vital\AppData\Local\Google\Chrome\User Data\Profile 2"
Most CORS issues are because you are trying to request via client side ajax from a react, angular, jquery apps that are frontend basic libs. You must request from a backend application. You are trying to request from a frontend API, but the API you are trying to consume is expecting this request to be made from a backend application and it will never accept client side requests.
How to redirect with CORS with lambda
I am getting following error Access to fetch at 'https://mywebsite.com/private-post.html' (redirected from 'https://api.mywebsite.com/login') from origin 'https://mywebsite.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled. I have following cors preflight set to https://api.mywebsite.com. https://mywebsite.com is static website. I am not sure if it has cors. Access-Control-Allow-Origin: ['https://mywebsite.com', 'https://api.mywebsite.com'] Access-Control-Allow-Headers: [*] Access-Control-Allow-Methods: [DELETE, GET, OPTION, PUT, HEAD, PATCH, POST] Access-Control-Allow-Credentials: true So first I make post request from https://mywebsite.com/login.html to https://api.mywebsite.com/login endpoint. And after successuful login I am doing following redirect with lambda. While having above cors. And I cannot redirect to any page because of error above. const response = { statusCode: 303, headers: { 'Location': 'https://mywebsite.com/private-post.html' } } return response Edit I tried setting Access-Control-Allow-Origin: [*] but then I cannot set Access-Control-Allow-Credentials: true. So to fix that I set Access-Control-Allow-Origin: ['https://*'] now I can allow credentials however on redirect the cors error still remains the same.
https://mywebsite.com is static website. I am not sure if it has cors. The error message days it doesn’t but, since you are trying to read the content with JS, it needs to. You can’t use a redirect to grant CORS permission for a resource you don’t control. If you could, then an attacker could (for example) create a site that redirects to your online banking, and then have JS on their attacking site access your accounts through it. It would make the Same Origin Policy worthless.
s3 presinged url nginx reverse proxy error - SignatureDoesNotMatch
I want to display pdf from s3 in the browser by using pdfjs - https://mozilla.github.io/pdf.js/ In place using of s3 URL, I have reverse proxy it like this URL www.my-site-url.com/public/s3-presinged-url-bucket-part-with-sign-info NGINX Block location /public { proxy_pass https://XXXX.s3.us-west-2.amazonaws.com/; } But S3 throws error <Code>SignatureDoesNotMatch</Code> <Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message> How to reverse proxy it correctly?
I ran into a similar situation when proxying to presigned S3 urls. Everything worked on development machines, but failed in production because CloudFront added additional headers which changed the signature. In my case because I already had valid presigned URLs provided headers were unmolested, I added proxy_pass_request_headers off; to make the proxy request roughly equivalent to a direct GET request.
Request header field X-Requested
I am trying to access a file in a bucket on google cloud storage. I have set the CORS configuration for the bucket. But I am getting this error when I make a request across https://. It works fine for requests made across http://. "XMLHttpRequest cannot load "FILENAME". Request header field X-Requested-With is not allowed by Access-Control-Allow-Headers in preflight response."
You must include X-Requested-With in the value of the responseHeader member in your config: [ { "origin": ["http://example.appspot.com"], "responseHeader": ["X-Requested-With"], "method": ["GET", "POST"], "maxAgeSeconds": 3600 } ] See the relevant docs, which say: If this is a preflight request, check if the preflight request includes one or more Access-Control-Request-Header. If so, then ensure that the matching CORS configuration entry includes a <ResponseHeader> entry for each requested header. All headers named in the Access-Control-Request-Header must be in the CORS configuration for the preflight request to succeed and include CORS headers in the response.
Getting S3 CORS Access-Control-Allow-Origin to dynamically echo requesting domain
How can I set the S3 CORS AllowedOrigin configuration such that it dynamically echos the requesting domain in the Access-Control-Allow-Origin header? In the post, "CORS with CloudFront, S3, and Multiple Domains", it is suggested that setting AllowedOrigin to <AllowedOrigin>*</AllowedOrigin> does this. However, S3 returns Access-Control-Allow-Origin: * instead. Access-Control-Allow-Origin: * does not work in my case as I am using image.crossOrigin = "use-credentials" in a JavaScript app. With this option, S3 returns Access-Control-Allow-Credentials: true. Cross origin access to the image then fails because using wildcard as the allowed origin in conjunction with credentials is not permitted. Background for why this is needed: In my setup, access to images on S3 has to go through our domain, where authentication is required to restrict access and check if an account is authorized to access the images. If it is, the server returns a 302 redirect to an S3 URL. For the authentication to work, image.crossOrigin = "use-credentials" has to be set so that the request hits my server with the required credentials. (Incidentally, when I tested on Firefox 30.0 and Chrome 35.0.1916.153, if crossOrigin is set to anonymous, credentials are still sent. But not on Safari 7.0.4. Consistent cross-browser behavior could only be obtained using use-credentials.). Because browsers transparently redirects to the S3 URL, credentials are also sent.
AWS's CORS documentation does not document this, but I managed to get the answer in a thread on AWS Developer Forums, where I found that AWS changed the original behavior of echoing the requesting domain if * is being used for AllowedOrigin. To get S3 to dynamically echo the requesting domain, AllowedOrigin has to be set as such: <AllowedOrigin>http://*</AllowedOrigin> <AllowedOrigin>https://*</AllowedOrigin>
For me it seemed to be some kind of caching issue (even though I was not using cloudfront, only S3). Appending a random parameter to the URL fixed the issue for me, e.g. https://s3-amazon.com/bucket/file.jpg?d=3243253456346 I also had the following CORS settings in S3: <?xml version="1.0" encoding="UTF-8"?> <CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <CORSRule> <AllowedOrigin>http://*</AllowedOrigin> <AllowedOrigin>https://*</AllowedOrigin> <AllowedMethod>GET</AllowedMethod> <MaxAgeSeconds>3000</MaxAgeSeconds> <AllowedHeader>*</AllowedHeader> </CORSRule> </CORSConfiguration>