# javascript – No ‘Access-Control-Allow-Origin’ header is present on the requested resource—when trying to get data from a REST API

## The Question :

655 people think this question is useful

I’m trying to fetch some data from the REST API of HP Alm. It works pretty well with a small curl script – I get my data.

Now doing that with JavaScript, fetch and ES6 (more or less) seems to be a bigger issue. I keep getting this error message:

Fetch API cannot load . Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘http://127.0.0.1:3000‘ is therefore not allowed access. The response had HTTP status code 501. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resource with CORS disabled.

I understand that this is because I am trying to fetch that data from within my localhost and the solution should be using CORS. Now I thought I actually did that, but somehow it either ignores what I write in the header or the problem is something else?

So, is there an implementation issue? Am I doing it wrong? I can’t check the server logs unfortunately. I’m really a bit stuck here.

function performSignIn() {

fetch(sign_in, {
//mode: 'no-cors',
credentials: 'include',
method: 'POST',
})
.then(response => response.json())
.then(json => console.log(json))
.catch(error => console.log('Authorization failed : ' + error.message));
}



I am using Chrome. I also tried using that Chrome CORS Plugin, but then I am getting another error message:

The value of the ‘Access-Control-Allow-Origin’ header in the response must not be the wildcard ‘*’ when the request’s credentials mode is ‘include’. Origin ‘http://127.0.0.1:3000‘ is therefore not allowed access. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.

1106 people think this answer is useful

This answer covers a lot of ground, so it’s divided into three parts:

• How to use a CORS proxy to get around “No Access-Control-Allow-Origin header” problems
• How to avoid the CORS preflight
• How to fix “Access-Control-Allow-Origin header must not be the wildcard” problems

How to use a CORS proxy to avoid “No Access-Control-Allow-Origin header” problems

If you don’t control the server your frontend JavaScript code is sending a request to, and the problem with the response from that server is just the lack of the necessary Access-Control-Allow-Origin header, you can still get things to work—by making the request through a CORS proxy. To show how that works, first here’s some code that doesn’t use a CORS proxy:

const url = "https://example.com"; // site that doesn’t send Access-Control-*
fetch(url)
.then(response => response.text())
.then(contents => console.log(contents))
.catch(() => console.log("Can’t access " + url + " response. Blocked by browser?"))


The reason the catch block gets hit there is, the browser prevents that code from accessing the response which comes back from https://example.com. And the reason the browser does that is, the response lacks the Access-Control-Allow-Origin response header.

Now, here’s exactly the same example but just with a CORS proxy added in:

const proxyurl = "https://cors-anywhere.herokuapp.com/";
const url = "https://example.com"; // site that doesn’t send Access-Control-*
fetch(proxyurl + url) // https://cors-anywhere.herokuapp.com/https://example.com
.then(response => response.text())
.then(contents => console.log(contents))
.catch(() => console.log("Can’t access " + url + " response. Blocked by browser?"))


Note: If https://cors-anywhere.herokuapp.com is down or unavailable when you try it, see below for how to deploy your own CORS Anywhere server at Heroku in just 2-3 minutes.

The second code snippet above can access the response successfully because it changes the request URL to https://cors-anywhere.herokuapp.com/https://example.com; adding the proxy URL as prefix in that way causes the request to get made through that proxy, which then:

1. Forwards the request to https://example.com.
2. Receives the response from https://example.com.
3. Adds the Access-Control-Allow-Origin header to the response.
4. Passes that response, with that added header, back to the requesting frontend code.

The browser then allows the frontend code to access the response, because that response with the Access-Control-Allow-Origin response header is what the browser sees.

You can easily run your own proxy using code from https://github.com/Rob–W/cors-anywhere/.
You can also easily deploy your own proxy to Heroku in just 2-3 minutes, with 5 commands:

git clone https://github.com/Rob--W/cors-anywhere.git
cd cors-anywhere/
npm install
heroku create
git push heroku master



After running those commands, you’ll end up with your own CORS Anywhere server running at, e.g., https://cryptic-headland-94862.herokuapp.com/. So then rather than prefixing your request URL with https://cors-anywhere.herokuapp.com, prefix it instead with the URL for your own instance: https://cryptic-headland-94862.herokuapp.com/https://example.com.

So if when you go to try to use https://cors-anywhere.herokuapp.com, you find it’s down (which it sometimes will be), then consider getting a Heroku account (if you don’t already) and take 2 or 3 minutes to do the steps above to deploy your own CORS Anywhere server on Heroku.

Regardless, whether you run your own or use CORS Anywhere or other open proxy, this solution works even if the request is one that triggers browsers to do a CORS preflight OPTIONS request, because in that case, the proxy also sends back the Access-Control-Allow-Headers and Access-Control-Allow-Methods headers needed to make the preflight successful.

How to avoid the CORS preflight

The code in the question triggers a CORS preflight—since it sends an Authorization header.

https://developer.mozilla.org/docs/Web/HTTP/Access_control_CORS#Preflighted_requests

Even without that, the Content-Type: application/json header would also trigger a preflight.

What “preflight” means: before the browser tries the POST in the code in the question, it’ll first send an OPTIONS request to the server — to determine if the server is opting-in to receiving a cross-origin POST that has Authorization and Content-Type: application/json headers.

It works pretty well with a small curl script – I get my data.

To properly test with curl, you must emulate the preflight OPTIONS request the browser sends:

curl -i -X OPTIONS -H "Origin: http://127.0.0.1:3000" \
-H 'Access-Control-Request-Method: POST' \
"https://the.sign_in.url"



…with https://the.sign_in.url replaced by whatever your actual sign_in URL is.

The response the browser needs to see from that OPTIONS request must have headers like this:

Access-Control-Allow-Origin:  http://127.0.0.1:3000
Access-Control-Allow-Methods: POST



If the OPTIONS response doesn’t include those headers, then the browser will stop right there and never even attempt to send the POST request. Also, the HTTP status code for the response must be a 2xx—typically 200 or 204. If it’s any other status code, the browser will stop right there.

The server in the question is responding to the OPTIONS request with a 501 status code, which apparently means it’s trying to indicate it doesn’t implement support for OPTIONS requests. Other servers typically respond with a 405 “Method not allowed” status code in this case.

So you’re never going to be able to make POST requests directly to that server from your frontend JavaScript code if the server responds to that OPTIONS request with a 405 or 501 or anything other than a 200 or 204 or if doesn’t respond with those necessary response headers.

The way to avoid triggering a preflight for the case in the question would be:

• if the server didn’t require an Authorization request header but instead, e.g., relied on authentication data embedded in the body of the POST request or as a query param
• if the server didn’t require the POST body to have a Content-Type: application/json media type but instead accepted the POST body as application/x-www-form-urlencoded with a parameter named json (or whatever) whose value is the JSON data

How to fix “Access-Control-Allow-Origin header must not be the wildcard” problems

I am getting another error message:

The value of the ‘Access-Control-Allow-Origin’ header in the response must not be the wildcard ‘*’ when the request’s credentials mode is ‘include’. Origin ‘http://127.0.0.1:3000’ is therefore not allowed access. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.

For a request that includes credentials, browsers won’t let your frontend JavaScript code access the response if the value of the Access-Control-Allow-Origin response header is *. Instead the value in that case must exactly match your frontend code’s origin, http://127.0.0.1:3000.

See Credentialed requests and wildcards in the MDN HTTP access control (CORS) article.

If you control the server you’re sending the request to, then a common way to deal with this case is to configure the server to take the value of the Origin request header, and echo/reflect that back into the value of the Access-Control-Allow-Origin response header; e.g., with nginx:

add_header Access-Control-Allow-Origin $http_origin  But that’s just an example; other (web) server systems provide similar ways to echo origin values. I am using Chrome. I also tried using that Chrome CORS Plugin That Chrome CORS plugin apparently just simplemindedly injects an Access-Control-Allow-Origin: * header into the response the browser sees. If the plugin were smarter, what it would be doing is setting the value of that fake Access-Control-Allow-Origin response header to the actual origin of your frontend JavaScript code, http://127.0.0.1:3000. So avoid using that plugin, even for testing. It’s just a distraction. To test what responses you get from the server with no browser filtering them, you’re better off using curl -H as above. As far as the frontend JavaScript code for the fetch(…) request in the question: headers.append('Access-Control-Allow-Origin', 'http://localhost:3000'); headers.append('Access-Control-Allow-Credentials', 'true');  Remove those lines. The Access-Control-Allow-* headers are response headers. You never want to send them in a request. The only effect that’ll have is to trigger a browser to do a preflight. ## The Answer 2 119 people think this answer is useful This error occurs when the client URL and server URL don’t match, including the port number. In this case you need to enable your service for CORS which is cross origin resource sharing. If you are hosting a Spring REST service then you can find it in the blog post CORS support in Spring Framework. If you are hosting a service using a Node.js server then 1. Stop the Node.js server. 2. npm install cors --save 3. Add following lines to your server.js var cors = require('cors') app.use(cors()) // Use this after the variable declaration  ## The Answer 3 66 people think this answer is useful The problem arose because you added the following code as request header in your front-end : headers.append('Access-Control-Allow-Origin', 'http://localhost:3000'); headers.append('Access-Control-Allow-Credentials', 'true');  Those headers belong to response, not request. So remove them, including the line : headers.append('GET', 'POST', 'OPTIONS');  Your request had 'Content-Type: application/json', hence triggered what is called CORS preflight. This caused the browser sent the request with OPTIONS method. See CORS preflight for detailed information. Therefore in your back-end, you have to handle this preflighted request by returning the response headers which include : Access-Control-Allow-Origin : http://localhost:3000 Access-Control-Allow-Credentials : true Access-Control-Allow-Methods : GET, POST, OPTIONS Access-Control-Allow-Headers : Origin, Content-Type, Accept  Of course, the actual syntax depends on the programming language you use for your back-end. In your front-end, it should be like so : function performSignIn() { let headers = new Headers(); headers.append('Content-Type', 'application/json'); headers.append('Accept', 'application/json'); headers.append('Authorization', 'Basic ' + base64.encode(username + ":" + password)); headers.append('Origin','http://localhost:3000'); fetch(sign_in, { mode: 'cors', credentials: 'include', method: 'POST', headers: headers }) .then(response => response.json()) .then(json => console.log(json)) .catch(error => console.log('Authorization failed : ' + error.message)); }  ## The Answer 4 11 people think this answer is useful In my case,I use the below solution Front-end or Angular post( this.serverUrl, dataObjToPost, { headers: new HttpHeaders({ 'Content-Type': 'application/json', }) } )  back-end (I use php) header("Access-Control-Allow-Origin: http://localhost:4200"); header('Access-Control-Allow-Methods: GET, POST, OPTIONS'); header("Access-Control-Allow-Headers: Content-Type, Authorization");$postdata = file_get_contents("php://input");
$request = json_decode($postdata);
print_r($request);  ## The Answer 5 2 people think this answer is useful Using dataType: 'jsonp' worked for me.  async function get_ajax_data(){ var _reprojected_lat_lng = await$.ajax({
type: 'GET',
dataType: 'jsonp',
data: {},
url: _reprojection_url,
error: function (jqXHR, textStatus, errorThrown) {
console.log(jqXHR)
},
success: function (data) {
console.log(data);

// note: data is already json type, you
//       just specify dataType: jsonp
return data;
}
});

} // function



2 people think this answer is useful

Just my two cents… regarding How to use a CORS proxy to get around “No Access-Control-Allow-Origin header” problems

For those of you working with php at the backend, deploying a “CORS proxy” is as simple as:

1. create a file named ‘no-cors.php’ with the following content:

$URL =$_GET['url'];
echo json_encode(file_get_contents($URL)); die();  2. on your front end, do something like: fetch('https://example.com/no-cors.php' + '?url=' + url) .then(response=>{*/Handle Response/*})  ## The Answer 7 1 people think this answer is useful Remove this: credentials: 'include',  ## The Answer 8 1 people think this answer is useful I was working with Spring REST, and I solved it adding the AllowedMethods into the WebMvcConfigurer. @Value( "${app.allow.origins}" )
private String allowOrigins;
@Bean
public WebMvcConfigurer corsConfigurer() {
System.out.println("allow origin: "+allowOrigins);
@Override
//.allowedOrigins("http://localhost")
.allowedOrigins(allowOrigins)
.allowedMethods("PUT", "DELETE","GET", "POST");
}
};
}



1 people think this answer is useful

In my case, web server prevented “OPTIONS” method

Check your web server for the options method

I’m using “webtier”

/www/webtier/domains/[domainname]/config/fmwconfig/components/OHS/VCWeb1/httpd.conf

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^OPTIONS
RewriteRule .* . [F]
</IfModule>



change to

<IfModule mod_rewrite.c>
RewriteEngine off
RewriteCond %{REQUEST_METHOD} ^OPTIONS
RewriteRule .* . [F]
</IfModule>



0 people think this answer is useful

In case you are using NodeJS/Express as back-end and ReactJS/axios as front-end within a development environment in MacOS, you need to run both sides under https. Below is what it finally worked for me (after many hours of deep dive & testing):

Step 1: Create an SSL certificate

Just follow the steps from How to get HTTPS working on your local development environment in 5 minutes

You will end up with a couple of files to be used as credentials to run the https server and ReactJS web:

server.key &amp; server.crt



You need to copy them in the root folders of both the front and back ends (in a Production environment, you might consider copying them in ./ssh for the back-end).

Step 2: Back-end setup

I read a lot of answers proposing the use of ‘cors’ package or even setting (‘Access-Control-Allow-Origin’, ‘*’), which is like saying: “Hackers are welcome to my website”. Just do like this:

import express from 'express';
const emailRouter = require('./routes/email');  // in my case, I was sending an email through a form in ReactJS
const fs = require('fs');
const https = require('https');

const app = express();
const port = 8000;

// CORS (Cross-Origin Resource Sharing) headers to support Cross-site HTTP requests
app.all('*', (req, res, next) => {
next();
});

// Routes definition
app.use('/email', emailRouter);

// HTTPS server
const credentials = {
};

const httpsServer = https.createServer(credentials, app);
httpsServer.listen(port, () => {
console.log(Back-end running on port ${port}); });  In case you want to test if the https is OK, you can replace the httpsServer constant by the one below: https.createServer(credentials, (req: any, res: any) => { res.writeHead(200); res.end("hello world from SSL\n"); }).listen(port, () => { console.log(HTTPS server listening on port${port}...);
});



And then access it from a web browser: https://localhost:8000/

Step 3: Front-end setup

This is the axios request from the ReactJS front-end:

    await axios.get(https://localhost:8000/email/send, {
params: {/* whatever data you want to send */ },
'Content-Type': 'application/json',
}
})



And now, you need to launch your ReactJS web in https mode using the credentials for SSL we already created. Type this in your MacOS terminal:

HTTPS=true SSL_CRT_FILE=server.crt SSL_KEY_FILE=server.key npm start



At this point, you are sending a request from an https connection at port 3000 from your front-end, to be received by an https connection at port 8000 by your back-end. CORS should be happy with this 😉

0 people think this answer is useful

With Nodejs, if you are using routers, make sure to add cors before the routers. Otherwise, you’ll still get the cors error. Like below:

const cors = require('cors');

const userRouter = require('./routers/user');

expressApp = express();
expressApp.use(cors());
expressApp.use(express.json());
expressApp.use(userRouter);



0 people think this answer is useful

adding mode:no-cors can avoid cors issue in the api.

fetch(sign_in, {
mode: 'no-cors',
credentials: 'include',
method: 'POST',
})
.then(response => response.json())
.then(json => console.log(json))
.catch(error => console.log('Authorization failed : ' + error.message));
}



app.use((req, res, next) =>{
`