I have 3 subdomains
clients.mywebsite.com,
admins.mywebsite.com,
api.mywebsite.com
api.mywebsite.com is the restful service consumed by the other two websites. When calling the API from the websites I got some cross origin issues. I was able to fix this issue on most browsers by setting 'Access-Control-Allow-Origin', '*' at the API. But in Internet Explorer this issue remained the same.
I was able to fix this manually by enabling CORS (this is turned off by default) in IE
Alt -> Tools -> Internet Options -> Security (Tab) -> Custom Level
-> Miscellaneous -> Access data sources across domains -> Set to Enable
And then from the console of the IE debugger I tried a GET request
var xhttp= new XMLHttpRequest();
xhttp.open("GET", "https://api.mywebsite.com/v1/", true);
xhttp.send();
after that, all the GET and POST request started working normally and I was able to log in. I can't make the clients configure IE in such a way. What are some alternate solutions ?
In IE 9 and earlier you could use the way you using to configure IE to deal with CORS issues. In IE 10+, your server must attach the following headers to all responses:
Access-Control-Allow-Origin: http://example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: ACL, CANCELUPLOAD, CHECKIN, CHECKOUT, COPY, DELETE, GET, HEAD, LOCK, MKCALENDAR, MKCOL, MOVE, OPTIONS, POST, PROPFIND, PROPPATCH, PUT, REPORT, SEARCH, UNCHECKOUT, UNLOCK, UPDATE, VERSION-CONTROL
Access-Control-Allow-Headers: Overwrite, Destination, Content-Type, Depth, User-Agent, Translate, Range, Content-Range, Timeout, X-File-Size, X-Requested-With, If-Modified-Since, X-File-Name, Cache-Control, Location, Lock-Token, If
Access-Control-Expose-Headers: DAV, content-length, Allow
Optionally you can also attach the Access-Control-Max-Age header specifying the amount of seconds that the preflight request will be cached, this will reduce the amount of requests:
Access-Control-Max-Age: 3600
You could refer to this link about implementing CORS for a specific server.
If you don't want to use the way you using, you could refer to this article to bypass CORS:
The way we can bypass it is, rather calling the API from your browser to the other domain, call your own domain API (for example /api) and at nginx (or any other web server) level proxy it to the destination server.
Related
I'm trying to automate a process so I want to connect to an external API, first just to log in (can't use the API Key since I'm not an admin user).
I basically copied the request the browser does when it logs in, but when doing this from Postman I get a 400 responde, with the body "Not allowed by CORS".
Is there any way through code, that I can bypass that and work with such API?
Cors means Cross-Origin Resource Sharing. Basically browsers help web servers a way to protect themselves for data change requests.
Remove Origin Header (or) replace Origin value to server hostname (in this case api.kenjo.io)
Add referer header.
With dothttp it would look like below.
POST 'https://api.kenjo.io/auth/token'
origin: 'https://www.kenjo.io'
referer: 'https://www.kenjo.io/'
It seems to be easy, but I don't know what I am missing.
I have a public bucket with a js script that I fetch from my web site. I noticed that I don't send Origin header to S3, it is not required and everything works without any CORS configurations.
What's more, even after I manually added Origin header to that GET call and explicitly disallowed GET and my domain via:
<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
<AllowedOrigin>http://www.nonexistingdomain.com</AllowedOrigin>
<AllowedMethod>POST</AllowedMethod>
<AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>
I can still get the content. What's going on here?
Ok, after a conversation with Quentin, I think I understand where I am misinterpreting how CORS should work.
In Java world, it's a very common practice to actually reject requests when Origin doesn't match. Here is another thread where it's mentioned.
If we take Spring as an example(which is de-facto standard in Java world), here is what happens when CORS filter is added:
String allowOrigin = checkOrigin(config, requestOrigin);
...
if (allowOrigin == null) {
logger.debug("Reject: '" + requestOrigin + "' origin is not allowed");
rejectRequest(response);
return false;
}
where:
/**
* Invoked when one of the CORS checks failed.
*/
protected void rejectRequest(ServerHttpResponse response) {
response.setStatusCode(HttpStatus.FORBIDDEN);
}
You can find the code here.
But to my surprise, it is not such a common practice with other stacks and server-side technologies. Another common approach would be to send whatever CORS configuration they have to the browser and leave the decision to it.
S3 is even more tricky: it only sends CORS response headers when the bucket CORS rules match the CORS-enabled request(a request qith Origin header). Otherwise, there would be no CORS response headers.
The Same Origin Policy is a feature enforced by browsers which prevents JavaScript running on one website from reading data from a different website. (This stops random websites using JavaScript to use your browser to skip past your corporate firewall and access your intranet or read your GMail with your cookies).
CORS lets a website relax the Same Origin Policy to allow other websites to read data from it that way.
CORS is not authentication/authorisation. Your public bucket is public.
You aren't using JavaScript to read data from your bucket, you are loading the JS directly from the bucket.
Let's break down the problem and try to understand the fundamentals of CORS.
What is Cross-Origin Request & CORS?
Cross-Origin Request: A request for a resource (like
an image or a font) outside of the origin is known as a cross-origin
request.
CORS is helpful when you are requesting for a protected resource from another origin.
Cross-Origin Request Sharing: A request for a protected resource (like an image or a font or an XHR request) outside of the origin is known as a cross-origin request.
Why do we need CORS when the resources can be protected by using authentication/authorization tokens?
CORS is the first line of defense. When both the client (e.g., browsers) and servers are CORS-aware, clients will allow only requests from the specific origins to the servers as per instructed by the servers.
By default, browsers are supposed to implement same-origin policy security mechanism as per the guidelines on building the browser. Almost all the modern browser implement same-origin policy that instructs the browsers to allow requests to the servers if the origin is the same.
Same-origin policy is a security mechanism of a browser, you can read more about it here. It is because of this feature of browsers, the browser blocks all the request when the designation origin and the source origin are different. (Servers are not even aware that this is happening, Wow!)
For simpler use cases, when the assets(js, CSS, images, fonts), XHR resources are accessible with the same origin, there is no need to worry about CORS.
If assets are hosted on another origin or XHR resource are hosted on servers with a different domain that the source then browsers will not deny the request to cross-origin by default. Only with appropriate CORS request and response headers, browsers are allowed to make cross-origin requests.
Let's look at the request and response headers.
Request headers
Origin
Access-Control-Request-Method
Access-Control-Request-Headers
Response headers
Access-Control-Allow-Origin
Access-Control-Allow-Credentials
Access-Control-Expose-Headers
Access-Control-Max-Age
Access-Control-Allow-Methods Access-Control-Allow-Headers
For setting up CORS the Origin, and Access-Control-Allow-Origin headers are needed. Browsers will automatically add Origin header to every request, so a developer needs to configure only Access-Control-Allow-Origin response header.
For protecting access to resources only from specific domains, S3 provides an option to configure CORS rules. If the value of Access-Control-Allow-Origin header is * all the cross-origin requests are allowed, or else define a comma-separated list of domains.
There are a couple of things you need to be aware of when using CORS.
It's the first level of defense to a protected resource and not the ultimate defense.
You still need to implement appropriate authentication & authorization for the resource to perform CRUD operations on the server.
Implementing Same Origin Policy is a guideline for building the browser and are not mandatory.
CORS headers are useful only when clients accept the headers. Only modern browsers accept CORS headers. If you are not using browsers to make the resource request, then CROS do not apply.
If you type the link in the address bar of the browser, the CORS rules are not applied to because the browser does not send the Origin header to the server. The Origin header is sent by the browser only on the subsequent resource request (stylesheets, js files, fonts) and XHR requests by the origin.
If you access the resource file by directly typing the link in the address bar, the browser does not send Origin header to that request.
Also, if you want to restrict GET access use S3 pre-signed URL on a private bucket.
Hi I am having an issue with CORS on safari. My request is working fine in every other browser except safari. I keep getting the error message [host] not allowed by Access-Control-Allow-Origin although the api specifically sets the request url in the response for both the OPTIONS request and the POST request.
I have researched this endlessly but nothing I have found has worked.
I have attached a screenshot from chrome which you can see all of the request and response headers and a screenshot from Safari where you can see the error. It is exactly the same request with exactly the same parameters.
Chrome:
Safari:
Thanks in advance!
Cross Origin Resource Sharing calls are generally blocked by browsers and thus API calls made from a website (in your case localhost:3004) to a remote host 52.85.173.227 (I think you have hosted it in Amazon's API Gateway).
What you need to do to enable CORS .
If you are using AMazon's API Gateway .
Click on the resources and in the Action , you have an option where you can enable CORS . Do that and it will add the headers to enable CORS .
Option on AWS API Gateway to enable CORS
Once you do this your response header of OPTIONS call will have "Access-Control-Allow-Origin" as "*" .
Thus your browser / web site will be able to make cross origin calls.
Hope this helps.
I have two web pages hosted on a.example.com and b.example. Each web page is including a script with a <script> tag, hosted on another domain and served with correct CORS headers.
At a certain point, user navigates from a.example.com to b.example.com.
Safari has here a strange behavior: the referrer and origin headers in preflight request are filled with a.example.com, making the server sending a bad value in Access-Control-Allow-Origin (and so the script can't be executed).
Is there a way to force Safari browser to send correct origin header in that kind of scenario ?
Does the cache policy for the script include Vary: Origin?
Respectively is there actually a second request after navigating to b.example.com?
If not, there is a chance that Safari is actually serving the script from cache - despite the Access-Control-Allow-Origin policy forbidding it to access the resource. Which is a conforming behavior, if the cache policy isn't configured correctly.
It seemed to be indeed a Safari bug.
The issue is not reproductible on Safari 10.0. It repro only on Safari 9.1.1 / 9.1.3.
I built an api in my XAMPP Server, with the database and so on (working fine). But now I am currently using WAMPP to make another web application. I reckon it is possible to link them eachother, so I don't need to make the whole API rest again.
The thing is I want to attack that database via that API.
Simply adding the url with the server ON is not working:
XMLHttpRequest cannot load http://localhost/slim/api.php/books. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3002' is therefore not allowed access.
I have a look around and I just found THIS POST but it is not working, or I am not doing it in the right way.
Could it be slim permissions? I have tried but nothing happened yet.
The problem was SOLVED by adding this code at the beggining of the api.php
header("Access-Control-Allow-Origin: *");
header("Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS");
header("Access-Control-Allow-Headers: Origin, Content-Type, Accept, Authorization");