Is "*" or the server's URI the default value for Access-Control-Allow-Origin header?
If the header is not set, does it mean that every origin has access to the resource?
There is no default value.
If it isn't set, then it isn't set. If it is set, then it must have an explicit value.
If the header is not set, does it mean that every origin has access to the resource?
No. It means that the Same Origin Policy is enforced as normal. No origins are granted permission.
the server's URI
There is no reason to ever set the Access-Control-Allow-Origin to be the server's own URL. Same Origin requests don't need permission from CORS.
Came across this looking for the headers that work without CORS and found this nice safe list from Mozilla: https://developer.mozilla.org/en-US/docs/Glossary/CORS-safelisted_request_header
A CORS-safelisted request header is one of the following HTTP headers:
Accept,
Accept-Language,
Content-Language,
Content-Type.
Related
I'd like to allow all origins to fetch resources from my apache server.
Instead of adding:
Access-Control-Allow-Origin: *
I would like my server to craft a special response with :
Access-Control-Allow-Origin: <the value of the Origin received in the request>
Is there something I can add to httpd.conf to achieve this ?
Seems it can be achieved by adding those two lines:
SetEnvIf Origin ".*\S.*" ORIGIN=$0
Header always set Access-Control-Allow-Origin %{ORIGIN}e env=ORIGIN
The regex pretty much means anything except newline, tab, and space, so as long as the Origin is not empty add it to the response header.
I have an API endpoint that I call from my React app. That API is on the same domain. Something like:
https://www.example.com
https://www.example.com/api/update-something
I use cross-fetch to do that request.
I was expecting to see an Origin header on my server logs. Infact, I was expecting to see Origin: https://www.example.com .
But here is what I get:
Origin: undefined
// AND I ALSO GET THESE HEADERS
"sec-fetch-dest":"empty",
"sec-fetch-mode":"cors",
"sec-fetch-site":"same-origin"
What do they mean? It's like the Origin check was already made?
For example: if I get sec-fetch-site: cross-site it means that the call was generate in another website/domain? Is that correct?
Reference:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Site
Sec-Fetch-Site: cross-site
Sec-Fetch-Site: same-origin
Sec-Fetch-Site: same-site
Sec-Fetch-Site: none
I have an API endpoint that I call from my React app. That API is on the same domain. … I was expecting to see an Origin header on my server logs.
Browsers send no Origin in same-origin GET requests, per Fetch spec requirements. ✳️
it's like the Origin check was already made
Yes — browsers know:
the origin of the code making the request
the origin of the resource for which the request is being made
the request method
…and browsers check all those before deciding whether to add the Origin header; and they don’t add the Origin header if the origins match and the method is GET.
// AND I ALSO GET THESE HEADERS
"sec-fetch-dest":"empty",
"sec-fetch-mode":"cors",
"sec-fetch-site":"same-origin"
What do they mean? … For example: if I get sec-fetch-site: cross-site it means that the call was generate in another website/domain? Is that correct?
https://w3c.github.io/webappsec-fetch-metadata/#sec-fetch-site-header has details:
Sec-Fetch-Site value
What the value indicates
same-origin
The origin to which the request is being made matches the origin of the code making the request.
same-site
The origin to which the request is being made and the origin of the code making the request have the same “registrable domain” (sometimes also referred to as the “same eTLD+1” or “same effective top-level domain plus one”); so, for example, https://subdomain.example.com and https://example.com are same-site (even though not same-origin).
cross-site
The origin to which the request is being made and the origin of the code making the request are neither same-origin nor even same-site but instead have different registrable domains.
none
The request wasn’t initiated programatically by frontend code (for example, not by an XHR/fetch/ajax call) but instead initiated by normal user navigation — that is, by a user doing something like directly putting an address into the browser URL bar, or clicking on a hyperlink.
✳️ Spec requirements causing the Origin header to be omitted in same-origin GET requests:
Whether or not the Origin header gets added ultimately depends on the request’s “response tainting”, the value of which starts out as "basic", and which, for same-origin requests, the Fetch algorithm keeps sets to "basic", per step 12 of the “Main fetch” algorithm:
↪ request’s current url’s origin is same origin with request’s
origin, and request’s response tainting is "basic"
…
Set request’s response tainting to "basic".
Return the result of running scheme fetch given fetchParams.
Running scheme fetch causes the append a request `Origin` header algorithm to get invoked, and that causes the Origin header to be added only if at least one of the following is true:
the request’s response tainting is "cors"
the request’s mode is "websocket"
the request’s method is neither GET nor HEAD
But for same-origin GET, the response tainting isn’t cors (rather, per the requirements above, it’s basic), the request mode isn’t websocket, and of course the method isn’t neither GET nor HEAD (it’s GET); thus, the algorithm requires browsers to not add an Origin header.
The Origin header is sent with CORS requests, as well as with POST requests.
The Origin header is not set on Fetch requests with a method of HEAD or GET
From:
Origin header
I've tried to fetch data from Wordpress API in Vue App.
I am using DigitalOcean with Apache.
I've set Header set Access-Control-Allow-Origin "*" in vhost.
But now I've got an error like this:
Access to XMLHttpRequest at xxx from origin 'http://localhost:3000' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header contains multiple values 'http://localhost:3000, *', but only one is allowed.
I am using axios for requests.
Do you have any ideas what's going on?
Is it server side issue or should I set something in axios config?
Thanks.
This is a server-side issue. You need to enable CORS in your apache config, by either:
Setting Header set Access-Control-Allow-Origin "*" - meaning that all origins are allowed to make requests to this server
Setting Header set Access-Control-Allow-Origin "http://localhost:3000"
This tells the server to accept requests from this origin(s), to further explain.
https://enable-cors.org/server_apache.html
Change your header set statement to:
Header always set Access-Control-Allow-Origin "*"
Otherwise Apache will prepend origin in request to the header, which causes the issue.
What happens when the Access-Control-Allow-Origin: is set to nothing at all? As it expects a domain.com or *.
If you set Access-Control-Allow-Origin to the empty string, browsers will log some kind of error to the console—either an error just saying the request origin doesn’t match the Access-Control-Allow-Origin header value, or else an error that the empty string is an invalid value for the Access-Control-Allow-Origin header (in browsers which do that validation check).
Either way, browsers won’t ever allow CORS requests from anywhere to access that resource.
Suddenly, seemingly without changing anything in my web app, I started getting CORS errors when opening it in Chrome. I tried adding an Access-Control-Allow-Origin: * header. Then I get this error:
XMLHttpRequest cannot load http://localhost:9091/sockjs-node/info?t= 1449187563637. A wildcard '*' cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true. Origin 'http://localhost:3010' is therefore not allowed access.
But as you can see in the following image, there is no Access-Control-Allow-Credentials header.
WTF? Chrome bug?
My page is loaded at http://localhost:3010 and that server also uses Access-Control-Allow-Origin: * without problems. Is there a problem if the two endpoints both use it?
"credentials flag" refers to XMLHttpRequest.withCredentials of the request being made, not to an Access-Control-Allow-Credentials header. That was the source of my confusion.
If the request's withCredentials is true, Access-Control-Allow-Origin: * can't be used, even if there is no Access-Control-Allow-Credentials header.
Requests withCredentials:true, on a server configured with Access-Control-Allow-Origin: * CAN be used, but you will need some more extra config on your server:
Using Access-Control-Allow-Origin=* on the server, it will not allow access to any resource (that requires credentials) on any xhr CORS request.
Workarounds:
Make that remote resource on the server accesible without credentials
( and use xhr.withCredentials = false )
Create a rewrite rule on
the server, to modify the response header
Access-Control-Allow-Origin=* to the request's origin. You can
also apply this rewrite under certain criteria, for example, if
request is using certain port or it comes from a list of whitelisted
domains.
Here is some article that explains how to do this on a IIS server, but you can do this in many other servers:
PS: in case of using credentials, you will also need the following header on your server's response: Access-Control-Allow-Credentials=true
PS2: only 1 value is allowed to "access-control-allow-origin" paramenter. If you try to use for instance two domains: domain1.com domain2.com, it won't work.
I solved same problem by using these steps..
1) disable your chrome extension "Allow-Control-Allow-Origin"
2) add these into your service
var xhr = new ();
xhr.withCredentials = true;