New issue
Advanced search Search tips
Starred by 65 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Mar 2014
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Sign in to add a comment

Access-Control-Allow-Origin: * doesn't match localhost

Reported by, Dec 21 2010 Back to list

Issue description

Chrome Version       : 9.0.597.19 (Official Build 68937) beta
URLs (if applicable) :
Other browsers tested:
  Firefox 4.0b9: OK

What steps will reproduce the problem?
1. Set up a server that uses the header "Access-Control-Allow-Origin: *"
2. From http://localhost/something do an XMLHttpRequest to this server

What is the expected result?

The request should succeed

What happens instead?

XMLHttpRequest cannot load (remote resource). Origin http://localhost is not allowed by Access-Control-Allow-Origin.

Please provide any additional information below. Attach a screenshot if

When using "Access-Control-Allow-Origin: http://localhost" the request does go through.  When using "Access-Control-Allow-Origin: http://localhost , *" it does not succeed (though from the spec it appears this header doesn't allow multiple values, so maybe it should not work, and it also does not in Firefox).

I have not tried other origins besides localhost.
Labels: -Area-Undefined Area-Internals Internals-Network
Adam, do you know who is the relevant person to evaluate this request?  I triaged it to network, but on second reading it sounds higher level.

Comment 3 by, Dec 23 2010

This definitely sounds like a bug.  I think we've gotten other reports of it as well.  It's likely a WebKit issue because the CORS implementation is in WebKit.

Comment 4 Deleted

Comment 5 by, Jul 11 2012

FYI: seems to work. I can ajax cross origin from/to localhost. No flags set.
Project Member

Comment 6 by, Aug 10 2012

Labels: -Pri-2 Pri-3 Action-NeedsReview
Status: IceBox (was: NULL)
Due to the age of the issue, changing the priority to P3, however because it has at least 10 stars, marking it for review.

Comment 7 by, Aug 10 2012

Status: Unconfirmed (was: NULL)
I have the problem as well.
My XHR request works in Safari 6, doesn't seems to be webkit related.
Actually not localhost related. No idea what's going on :/
Project Member

Comment 11 by, Mar 10 2013

Labels: -Area-Internals -Internals-Network Cr-Internals Cr-Internals-Network

Comment 12 by Deleted ...@, Jun 7 2013

07/06/2013 still not fixed ?

This is still not fixed for a very long time. This is really annoyed for developer who uses CORS on local with test server.

Comment 14 by, Jun 17 2013

Labels: -Cr-Internals-Network Cr-Blink
I don't understand why this hasn't been fixed yet... 
Chrome worked fine with localhost once I set my Access-Control-Allow-Headers and Access-Control-Allow-Methods headers correctly:

Comment 17 by, Mar 22 2014

Status: WontFix (was: NULL)
Marking this bug as WontFix, because it cannot be reproduced. not even on Chrome 9.0.597.107 (from the original bug report), Chrome (ancient) and 33.0.1750.152 (latest stable). There are loads of unit tests in Chrome that perform cross-origin requests from/to localhost, all of them work as intended.

Keep in mind that to perform a cross-origin request, the REQUESTED resource must respond with an "Access-control-allow-origin: *". Adding these headers to your page on localhost will NOT magically give localhost access to all other sites.

If you've just set up your server to reply with "Access-Control-Allow-Origin: *", it is still possible to get the reported error when the response is cached (because the new CORS headers from the server are unknown to the browser when it retrieves the response from the cache). This is an open issue in the specification ( To work-around this problem as a user, just clear the browser's cache.
I don't think this issue was marked wontfix due to reproducibility, but because the spec for the access control header says you have to have an exact match and you can't use *. Here's the spec reference:

That being said the first comment on this answer at Stack Overflow looks like a good idea:

You know the domain of who's requesting so why not just dynamically change the access-control-header to match on pre-flight requests, that should be a great workaround to what is otherwise an annoying issue. I haven't tried it myself, but it makes sense to me.

Good luck!

Comment 19 by, Apr 28 2014

Labels: -Action-NeedsReview
@Shaun (#18)
I did mark the issue as WontFix because I cannot reproduce the issue (#17).

You have mistakenly linked to the "access-control-allow-HEADERS" spec. "*" is a perfectly valid value for "Access-Control-Allow-ORIGIN" (see
You're right, my bad, thanks for the correction!
I can reproduce the issue in Chrome 35 on Mac. I'm using Polymer ( and some files request other files. Checking console shows that CORS requests on localhost do indeed fail. I'm not sure why this isn't reproducible, I just managed to now, and I easily remember times where this was an issue.

Attached file is the same as URL, just for reference.
Screenshot 2014-07-05 00.21.50.png
210 KB View Download

Comment 22 by, Jul 5 2014

@ilanbiala (#21)
That is not https(s)://localhost/, but a file:// URL.
Either put the files on a (local) server and access the page over http(s), or close all Chrome windows, edit the command line of the Chrome, append the following flag and start Chrome again:

The previous flag allows pages on file:// URLs to request other resources on the file:-scheme.
It seems CORS is broken *again* as from Chrome v37. Please see

I've just updated to Chrome 38 (38.0.2125.101 m) and the problem persists. Mine is an AngularJS application talking to a Java (Jetty) server that has HTTP BASIC auth activated. GETs work fine, but POSTs fail with a 401:

XMLHttpRequest cannot load http://localhost:8081/cellnostics/rest/patient.
Invalid HTTP status code 401

This is on my dev PC: my AngularJS app is served from NetBeans on localhost:8383, while the server runs on localhost:8081. With all the initial problems with Chrome, localhost and CORS (as described above) I wrote a custom (Java) CORS filter quite some time ago, which worked up until Chrome v37, and *still works* on IE 11 (11.0.9600) and Opera 12.17 build 1863.

Here's the request/response:

Remote Address:[::1]:8081
Request URL:http://localhost:8081/cellnostics/rest/patient
Request Method:OPTIONS
Status Code:401 Full authentication is required to access this resource

Request Headers:

Access-Control-Request-Headers:accept, content-type
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.101 Safari/537.36

Response Headers
Access-Control-Allow-Headers:Cache-Control, Pragma, Origin, Authorization, Content-Type, X-Requested-With, Accept
Access-Control-Allow-Methods:POST, GET, OPTIONS, PUT, DELETE
WWW-Authenticate:Basic realm="Cellnostics"

So, it fails on the pre-flight OPTIONS request with a 401, even though my CORS filter explicitly enables the OPTIONS method:

Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, DELETE

and the Javascript app's origin:

Access-Control-Allow-Origin: http://localhost:8383

This is very frustrating for developers who rely on Chrome for local testing. Why does Chrome have persistent problems with CORS that appear, disappear and re-appear in later versions? Why do none of the other browsers have these problems?
Re my previous comment: I do NOT have HTTPS/certificates enabled, only HTTP BASIC auth.

Comment 26 by Deleted ...@, May 21 2015

I'm seeing this issue on Chrome 42.0.2311.152.  Running through Fiddler (a proxy) I can see that chrome doesn't even bother to hit the network before giving an error like:

XMLHttpRequest cannot load Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https, chrome-extension-resource.

I've tried (which resolves to, localhost, and my actual hostname.  The same problem happens each time - Chrome never even tries to hit the network.

If I remove the port number ( rather than chrome hits the network.  It seems chrome hits this issue if the port number is specified.  Note:  my page is being served from http://localhost:9000/

Comment 27 by Deleted ...@, Jun 12 2015

Add the --disable-web-security flag to "resolve" this issue if you are struggling with local development.

Comment 28 by Deleted ...@, Dec 22 2015

Venga coño arreglad esto!!
This is so annoying! It seems indeed to happen only when using a port on localhost.
And no, this is not a solution. 
I had similar kind of issue while submitting custom form data from my localhost website to google form/sheet using ajax.

The error i was getting is 

XMLHttpRequest cannot load No 'Access-Controll-Allow-Origin' header i spresent on the requested resource. Origin http://localhost is therefore not allowed access

I solved this issue by exposing my localhost as public. I used tool to do this. Hope this might help

Comment 31 by, Sep 7 2016

I resolved it with iis 10 so suspect this will work with 7 and up.
in IIS manager select the site, select HTTP Response headers under the IIS section, under Actions (top right) click Add.
Values: *
Click OK

I'm not 100% sure on the implications of this so will try to post back if I find it opens another issue.
This is still broken and a big nuisance for development: I cannot access http://localhost:8008 for testing while developing with Cordova.  I wonder why the issue was closed; clearly inappropriate. 

Fortunately this extension is a workaround:

Comment 33 by, May 11 2017

Super annoying issue. 

I got CORS working fine server-side, verified by many other sites and CURL. Chrome itself would do a GET fine on some sites, just not on my localhost. 

As someone above mentioned, I believe it may be due to using a PORT in your URL. 

FIX: I redirected port 3000 to 443 on my local machine, allowing Chrome to use localhost without the port, and boom, it worked. 

Surely this would be fairly easy to fix... 
For who need a workaround (tested with Chrome 58 on Mac)

1) Install a Chrome extension (

Please remember to disable it when test JS code on remote server.

2) Use command to open Chrome: open -a Google\ Chrome --args --disable-web-security --user-data-dir="~/Users/XX/Desktop/temp"

This will start Chrome as a fresh new installed application, so I preferred #1.

Sign in to add a comment