Develop Reference

CORS Issue on Chrome Browser [duplicate]

I have an application (React SPA) that calls a bunch of servers on different subdomains of the application domain, i.e.:
the web app sits at foo.bar.com,
and talks to api.foo.bar.com and media.foo.bar.com.
When accessing api.foo.bar.com, I get an error from the browser (be it Edge, Chrome, or Firefox) telling me that the origin (foo.bar.com) is different from the value of the Access-Control-Allow-Origin response header. However, by inspection of the response, they are the same:
(I unfortunately have to obfuscate the address.)
Those apps are hosted on Kubernetes; the ingress is NGINX, and it's is not providing CORS (cors-enabled annotation is false). Both applications (api and media) are Express apps, and both have the same CORS configuration allowing the specific origin.
I'm wondering if this has something to do with the redirect - the call to the media... endpoint returns a redirect (302) whose Location is a api... address.
Other than that, I have no clue what could be wrong. Something is, for sure, because all browsers agree that my request should be blocked (on account of the origin).
In all cases, I've checked the address multiple times for typos, ending forward-slashes, etc. I've called OPTIONS on those endpoints with cURL and Postman, using all headers or just a few. They always answer the correct address.
Additional information, as requested:
Preflight request:
OPTIONS /media/1.0.0/rtsp/hls?feedUrl=https%3A%2F%2Flive.monuv.com.br%2Fa1%2F14298.stream%2Fstr27%2Fchunklist.m3u8%3Fm_hash%3DkhV_hCnKG3nhaNCFaYZxBnoMz-99idQVHiQh80ADW78%253D HTTP/2
Host: media.aiXXXXXXXXXXXXXX.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Access-Control-Request-Method: GET
Access-Control-Request-Headers: feedurl
Referer: https://aiXXXXXXXXXXXXXXXX.com/
Origin: https://aiXXXXXXXXXXXXXXXX.com
DNT: 1
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Pragma: no-cache
Cache-Control: no-cache
TE: trailers
Preflight response:
HTTP/2 204 No Content
date: Fri, 08 Oct 2021 13:33:10 GMT
x-powered-by: Express
access-control-allow-origin: https://aiXXXXXXXXXXXXXXXXXX.com
vary: Origin
access-control-allow-credentials: true
access-control-allow-methods: GET,HEAD,PUT,PATCH,POST,DELETE
access-control-allow-headers: Content-Type, feedUrl
strict-transport-security: max-age=15724800; includeSubDomains
X-Firefox-Spdy: h2
Request
The preflight passes, and the browsers starts a "flight" request:
GET /media/1.0.0/rtsp/hls?feedUrl=https%3A%2F%2Flive.monuv.com.br%2Fa1%2F14298.stream%2Fstr27%2Fchunklist.m3u8%3Fm_hash%3DkhV_hCnKG3nhaNCFaYZxBnoMz-99idQVHiQh80ADW78%253D HTTP/2
Host: media.aiXXXXXXXXXXXXXXXXXXXXX.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
feedUrl: https://live.monuv.com.br/a1/14298.stream/str27/chunklist.m3u8?m_hash=khV_hCnKG3nhaNCFaYZxBnoMz-99idQVHiQh80ADW78%3D
Origin: https://aiXXXXXXXXXXXXXXXX.com
DNT: 1
Connection: keep-alive
Referer: https://aiXXXXXXXXXXXXXXXXX.com/
Cookie: ory_kratos_session=MTYzMzYzODY1OHxEdi1CQkFFQ180SUFBUkFCRUFBQVJfLUNBQUVHYzNSeWFXNW5EQThBRFhObGMzTnBiXXXXXXXXXXXXYVc1bkRDSUFJSHBtUWxsaWFsVlJhWGRTVGxSMmIzZHRkbTFqYm5CUlRWVkdkelpPWkRoWnXXXTyqwgK-0Pe0qtZHjNhfU-YoASjg3istMZi672swQ==
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Pragma: no-cache
Cache-Control: no-cache
TE: trailers
Response
HTTP/2 302 Found
date: Fri, 08 Oct 2021 13:33:10 GMT
content-type: text/plain; charset=utf-8
content-length: 129
location: https://api.aiXXXXXXXXXXXXXXXXXX.com/media/1.0.0/hls/streams/19dd149d-f551-4093-b2aa-e5558388d545/hls.m3u8
x-powered-by: Express
access-control-allow-origin: https://aiXXXXXXXXXXXXXXXX.com
vary: Origin, Accept
access-control-allow-credentials: true
strict-transport-security: max-age=15724800; includeSubDomains
X-Firefox-Spdy: h2
At this response, the browser fails saying that the origin don't match the access-control-allow-origin.
(the first image was from Edge, since the log was more clear; this log is from Firefox)

Problem
The error message—I'm using dummy URLs and origins below—from the browser can be a bit confusing:
Access to XMLHttpRequest at 'https://api.example.com/' (redirected from 'https://media.example.com/') from origin 'https://example.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The 'Access-Control-Allow-Origin' header has a value 'https://example.com' that is not equal to the supplied origin.
The key here is that, as sideshowbarker hinted at in his comment, because your first preflighted request to https://media.example.com/ responds with a cross-origin redirect to https://api.example.com/, the browser performs another whole CORS access-control check for that resource. However, because the redirect resulting from the first preflighted request happens to be cross-origin, the browser sets the origin of the second preflight request (which the error message refers to as the "supplied origin"), not as https://example.com, but as the null origin!
Here's a rundown of what is likely happening:
Because https://api.example.com likely doesn't (and shouldn't!) allow the null, the second access-control check fails and you get that annoying CORS error.
Solution
Resist the temptation to allow the null origin on https://api.example.com/, as doing so has serious security ramifications: it amount to voiding the protection that the Same-Origin Policy provides.
Instead, you should get rid of that redirect from https://media.example.com/ to https://api.example.com/ and make your frontend request the https://api.example.com/ resource directly.
Alternatively, if you cannot completely get rid of the redirect but you can change its destination, make it a same-origin redirect (from somewhere https://media.example.org to elsewhere on https://media.example.org).

301 response with 'Cross-Origin Request Blocked' despite having correct CORS headers configured

I'm accessing nasa pictures with their public api, but i get this error:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at
[nasa api website] (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
But when i inspect their response header, the ‘Access-Control-Allow-Origin’ is present and set to '*', here you can see it:
RESPONSE HEADERS:
Access-Control-Allow-Origin *
Age 0
Cache-Control max-age=0, private, must-revalidate
Content-Encoding gzip
Content-Type application/json; charset=utf-8
Date Sat, 28 Mar 2020 14:37:13 GMT
Etag W/"e26hidden..."
Referrer-Policy strict-origin-when-cross-origin
Server openresty
Strict-Transport-Security max-age=31536000; includeSubDomains
Vary Origin
Via https/1.1 api-umbrella (ApacheTrafficServer [cMsSf ]), 1.1 vegur
X-Cache MISS
X-Content-Type-Options nosniff
X-Download-Options noopen
X-Frame-Options SAMEORIGIN
X-Permitted-Cross-Domain-Policies none
X-RateLimit-Limit 1000
X-RateLimit-Remaining 999
X-Request-Id 00c8c415-37ad-474b-bfbd-8e968d60f37f
X-Runtime 0.125778
X-Xss-Protection 1; mode=block
REQUEST HEADERS:
Accept text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding gzip, deflate, br
Accept-Language en-US,en;q=0.5
Connection keep-alive
Host api.nasa.gov
If-None-Match W/"e26chidden.."
Upgrade-Insecure-Requests 1
User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:74.0) Gecko/999991 Firefox/74.0

There’s a common mistake that can happen when specifying a URL for a cross-origin request in code, and the mistake can cause browsers to end up reporting a CORS error when in fact the problem is simply an easy-to-overlook mistake in the request URL itself.
The mistake is just a missing "s": using "http" as the URL protocol part instead of "https".
That missing "s" causes the server you sent the request to respond with a 3xx redirect to the equivalent https location of that URL. But the problem is: by default, many/most servers won’t include the Access-Control-Allow-Origin header in 3xx responses. So the browser gets that 3xx, but because it lacks the Access-Control-Allow-Origin header, the browser refuses to let your code follow the redirect; instead the browser stops right there and emits a CORS error.
So when you encounter a case like this, the way to troubleshoot it is: Open the Network pane in devtools and inspect the response. Check the response status code shown there and check the response headers. If the cause is the mistake described in this answer, you’ll see a Location response header. That value is the URL to which the server is trying to redirect the request.
And when you look at the Location value, you might initially think it’s exactly the same as the request URL you have in your code, because it’s easy to overlook that the difference is just that single missing "s". But of course if you take the URL in that Location value and replace the request URL in your frontend code with it, and it works, then the difference becomes apparent.
So in the case of the URL in this question, the problem was just, the frontend code specified a http://mars.jpl.nasa.gov URL that should instead be a https://mars.jpl.nasa.gov URL.

Creating a get request using fetch - only options is send

I'm trying to create a get request using Fetch. The request looks like this:
fetch('https://requestb.in/14ikb6j1', {
method: 'get',
headers: {
'Authorization': 'Token token=xxxxx'
}});
If I make this request to my own server, it fails on the options request every time. I cannot figure out why.
If I make this request to requestbin, there is an options request first. However, after receiving the options response, the actual get request is never made.
This is what requestbin received:
OPTIONS /14ikb6j1
HEADERS
Referer: http://localhost:9000/
Host: requestb.in
Total-Route-Time: 0
Via: 1.1 vegur
Accept-Encoding: gzip
Cf-Visitor: {"scheme":"https"}
Cf-Ipcountry: NL
Cf-Ray: 36edd35d1cad2b28-AMS
Cf-Connecting-Ip: 37.153.231.90
Connection: close
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Accept: */*
Connect-Time: 1
Access-Control-Request-Method: GET
Content-Length: 0
Accept-Language: nl-NL,nl;q=0.8,en-US;q=0.6,en;q=0.4
X-Request-Id: 69b120c1-0f18-454b-a7fd-91f082252a06
Access-Control-Request-Headers: authorization
Origin: http://localhost:9000
This is what chrome logs:
The strangest thing is, I get a 200 - OK status as result. The console however, still logs this:
Fetch API cannot load https://requestb.in/14ikb6j1. Response to
preflight request doesn't pass access control check: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://localhost:9000' is therefore not allowed
access. If an opaque response serves your needs, set the request's
mode to 'no-cors' to fetch the resource with CORS disabled.
:9000/#/branching:1 Uncaught (in promise) TypeError: Failed to fetch
But if I make this request using Postman it does work:
GET /14ikb6j1
HEADERS
Cf-Ipcountry: NL
Cf-Ray: 36eddb797ebf7223-AMS
Authorization: Token token=xxxx
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Total-Route-Time: 0
Via: 1.1 vegur
Connection: close
Cf-Connecting-Ip: 37.153.231.90
Connect-Time: 0
Accept-Language: nl-NL,nl;q=0.8,en-US;q=0.6,en;q=0.4
Postman-Token: 57486701-6f9a-4aab-be1b-776f0d376920
Accept: */*
Host: requestb.in
X-Request-Id: 73a7a35e-0d89-41fd-b760-2aa952349871
Accept-Encoding: gzip
Cf-Visitor: {"scheme":"https"}
Cache-Control: no-cache
How can I make this get request with authentication headers work?

This is probably a CORS problem. The server you are seinding the request to doesn't allow requests from a different domain.
Check your browser console and look for errors. You might find somehting like this:
Fetch API cannot load https://requestb.in/14ikb6j1. Response to
preflight request doesn't pass access control check: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'https://localhost:9000' is therefore not allowed
access. If an opaque response serves your needs, set the request's
mode to 'no-cors' to fetch the resource with CORS disabled.

CORS access to MongoDB via Apache Server on Windows7

I am building a prototype application that does an Ajax GET call via javascript in an html page. The configuration I am using is:
Windows/Apache Web Server (XAMPP)
MongoDB
Chrome Browser
All running on the same Windows7(32) machine. The mongodb server and data are installed in the C:\ path; the Apache server is in the C:\XAMPP path. I can access the MongoDB server directly through the browser; for example a call to:
localhost:28017/ database/ collection
will return the collection's data in json format.
However, if I try running the same Ajax call in javascript via an html page, I get the error:
XMLHttpRequest cannot load http:// localhost:28017/ database/ collection. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http:// localhost' is therefore not allowed access.
I modified/inspected my httpd.conf file and have the following set for :
<Directory />
Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Max-Age "1000"
Header always set Access-Control-Allow-Headers "X-Requested-With, Content-Type,
Origin, Authorization, Accept, Client-Security-Token, Accept-Encoding"
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
AllowOverride none
Require all denied
</Directory>
I also confirmed that the headers_module is being loaded:
LoadModule headers_module modules/mod_headers.so
However, this does not work. The port number is changing between the html and the ajax call (80 vs. 28017), therefore a new domain.
Here is the script code:
var xhr = new XMLHttpRequest();
console.log("xhr open")
xhr.open("GET", "http://localhost:28017/ database/ collection/", false);
xhr.send();
Here are the response headers from the html call:
Accept-Ranges:bytes
Access-Control-Allow-Headers:X-Requested-With, Content-Type, Origin, Authorization, Accept, Client-Security-Token, Accept-Encoding
Access-Control-Allow-Methods:POST, GET, OPTIONS, DELETE, PUT
Access-Control-Allow-Origin:*
Access-Control-Max-Age:1000
Connection:Keep-Alive
Content-Length:564
Content-Type:text/html
Date:Mon, 09 Jan 2017 23:47:06 GMT
ETag:"234-545b12ed82b40"
Keep-Alive:timeout=5, max=100
Last-Modified:Mon, 09 Jan 2017 22:49:41 GMT
Server:Apache/2.4.23 (Win32) OpenSSL/1.0.2h PHP/5.5.38
And all the headers from the xhr call:
General
Request URL:http://localhost:28017/ database/ collection/
Request Method:GET
Status Code:200 OK
Response Headers
Connection:close
Content-Length:369
Content-Type:text/plain;charset=utf-8
x-action:
x-ns:database.collection
Request Headers
Accept:*/*
Accept-Encoding:gzip, deflate, sdch, br
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Host:localhost:28017
Origin:http:// localhost
Referer:http://localhost/ load_mongodb_data.html
User-Agent:Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Any assistance appreciated.

CORS is a mechanism where restricted Resources can be requested from (Shared to) another domain - i.e. "Cross Origin" ... the domain owning the resource controls who can have it - this is the important part of CORS, the owner of the resource permits or denies access to the resource
In your case, the page making the request is served on port 80, the resource is requested on port 28017
Think of port 80 as being your domain with your resources
Think of port 28017 being someone elses domain, and they have some resources you want to use
You can't "enable CORS" on your domain and expect the other domain to then grant you access to it's resources - if that's how CORS worked, there'd be no need for CORS to begin with
What you'll need to do is set those Access-Control-* headers on the server running on port 28017

CORS request immediately canceled chrome

I'm trying to send a file to rackspace via AJAX. This is my first time looking at CORS. I see in the documentation the option to send a preflight request, however since I personally set the header and know that my origin is valid I'm trying to forgo, these are the headers from my upload endpoint:
HTTP/1.1 204 No Content
Content-Length: 0
X-Container-Object-Count: 2
Accept-Ranges: bytes
X-Container-Meta-Access-Log-Delivery: false
X-Container-Meta-Access-Control-Expose-Headers: etag location x-timestamp x-trans-id
X-Timestamp: 1401852621.29287
X-Container-Meta-Access-Control-Allow-Origin: h ttp://localhost:8080**<-- (manually added the space after "h" so stackoverflow would let me submit)
X-Container-Bytes-Used: 5572910
Content-Type: text/plain; charset=utf-8
X-Trans-Id: txfc64055cb1114b6fb0ef6-0053a77a46ord1
Date: Mon, 23 Jun 2014 00:52:22 GMT
However, whenever I try to send the request it immediate fails in chrome with the following message:
XMLHttpRequest cannot load [**I'm redacting my actual endpoint**]. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'h ttp://localhost:8080' is therefore not allowed access.
Here are my request headers:
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryZSg4nEq8EDaXQQBu
Origin:h ttp://localhost:8080
Referer:h ttp://localhost:8080/tools/artwork
<-- (manually added the space after "h" so stackoverflow would let me submit)
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.152 Safari/537.36
What am I missing? Is preflight request required even if you know origin is permitted? I never see a packet come back to seems like Chrome isn't sending?

Yes, preflight is required any time your CORS request is not of the "simple" variety--meaning, you have a method other than GET, HEAD, or POST, a content type other than application/x-www-form-urlencoded, multipart/form-data, or text/plain, or your request sets a custom header.
Regardless of this, however, the response you've pasted does not contain Access-Control-Allow-Origin (it has X-Container-Meta-Access-Control-Allow-Origin) in the first place, which is why your request was rejected.

In your server,add Access-Control-Allow-Origin: http://foo.example header.
For example in Spring Controller, response.setHeader("Access-Control-Allow-Origin", "http:localhost:8080");
Additional things,
Access-Control-Allow-Origin: http://foo.example // you can add as many urls separated by commas or '*' to allow all urs
Access-Control-Allow-Methods: POST, GET, OPTIONS // Request method options separated by commas
Access-Control-Allow-Headers: X-PINGOTHER
Access-Control-Max-Age: 1728000 // expiration in milliseconds
Refer this MDN site.