This question already has answers here:
same-origin policy and CORS - what's the point?
(1 answer)
Same origin Policy and CORS (Cross-origin resource sharing)
(2 answers)
What is the issue CORS is trying to solve?
(3 answers)
Closed 12 months ago.
I know exactly how CORS is working, i know it's implemented on browsers, and i know it forbids XMLHTTPRequests to other origins unless the remote origin allows it using the response header Access-Control-Allow-Origin.
And of-course I heard it's because the "security reasons" that it's there.
The thing i don't get is how it's improving security.
So imagine we're in a browser and we have a malicious js file loaded in our page and it wants to send our local storage data or cookies to another origin (hacker origin). so the hacker simply set the "Access-Control-Allow-Origin" to * and he's good to go! so what CORS did exactly here?
Somewhere i read that CORS is there because of "intellectual property" and that makes sense somehow, so some remote servers don't want to answer to requests from other clients. that's ok.. . but for security reasons!? I don't get that part.
I would appreciate if anyone could help me with this.
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 19 hours ago.
Improve this question
I am getting a CORS issue saying a header is missing, but the header is present in both server's code.
Here is what I am trying to do:
POST request from frontend to nodeServer1, then inside the endpoint I make a POST request to nodeServer2
And then a response is sent back to the front end.
My Access-Control-Allow-Origin policy is "*" for nodeServer1, and is "[nodeServer1URL]", "[frontendURL]" for nodeServer2.
When I make another request from the frontend to nodeServer1, I am not getting any issues. But for the request I'm trying to get here is the error:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at "[nodeServer1EndPointURL]". (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 502.
nodeServer1 executes whatever is in the endpoint as expected. When I test locally the nodeServer2 endpoint it works as well, so it has to be CORS.
So the issue is most definitely with nodeServer2's policy, which is apparently missing. Even if I set the policy of nodeServer2 to "*" it fails with the same error. I don't know why.
Not sure why is the remote resource my full endpoint URL.
So my question is, how can I fix this CORS issue?
This question already has answers here:
How does the 'Access-Control-Allow-Origin' header work?
(19 answers)
Why doesn't adding CORS headers to an OPTIONS route allow browsers to access my API?
(36 answers)
firebase hosting blocking script due to CORS issue
(8 answers)
Closed 4 years ago.
First of all, I'm sure that this is a duplicate question, but I'm a bit far from web techs, and couldn't understand what the hell is CORS, why it is blocking a simple HTTP request and how can I bypass it.
I'm trying to create an Angular 5 + Node.js web app, hosted on Firebase Hosting, and have an Elasticsearch instance on Google Cloud Platform. All I need to do is send 2 very basic HTTP requests to the ES instance from this web app. I'm already sending these requests from mobile apps and Postman app, and there is no problem. But web app logs Preflight response is not successful error. I googled the error and see that it is thrown by CORS. As I said, I have no idea what the hell is CORS and how to bypass it. Any help please (simple help to a non-web-developer). Thank you.
Shortly, CORS (Cross-Origin Resource Sharing) is a security mechanism enforced by default by the browser which specifies what resources (on which servers) your application can use (make requests for). This is a good explanation of CORS - https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS.
So you have to set on your server the domain of your application as being one of the domains allowed to make calls. If you do so, the preflight request will return with an Access-Control-Allow-Origin header set and the browser allows the actual request to be sent.
You can have a look here to see how to do it in Firebase - https://groups.google.com/forum/#!msg/firebase-talk/oSPWMS7MSNA/RnvU6aqtFwAJ
I'm a bit confused about the security aspects of CORS POST requests. I know there is a lot of information about this topic online, but I couldn't find a definite answer to my questions.
If I understood it correctly, the goal of the same-origin policy is to prevent CSRF attacks and the goal of CORS is to enable resource sharing if (and only if) the server agrees to share its data with applications hosted on other sites (origins).
HTTP specifies that POST requests are not 'safe', i.e. they might change the state of the server, e.g. by adding a new comment. When initiating a CORS request with the HTTP method POST, the browser only performs a 'safe' preflight request if the content-type of the request is non-standard (or if there are non-standard http headers). So POST requests with standard content-type and standard headers are executed and might have negative side effects on the server (although the response might not be accessible to the requesting script.)
There is this technique of adding a random token to every form, which the server then requires to be part of every non-'safe' request. If a script tries to forge a request, it either
does not have the random token and the server declines the request, or
it tries to access the form where the random token is defined. This response with the random token should have the appropriate head fields, such that the browser does not grant the evil script access to this response. Also in this case the attempt fails.
My conclusion is that the only protection against forged POST requests with standard content-type and headers is the technique described above (or a similar one). For any other non-'safe' request such as PUT or DELETE, or a POST with json-content, it is not necesssay to use the technique because CORS performs a 'safe' OPTIONS request.
Why did the authors of CORS exclude these POST exempt from preflight requests and therefore made it necessary to employ the technique described above?
See What is the motivation behind the introduction of preflight CORS requests?.
The reason CORS doesn’t require browsers to do a preflight for application/x-www-form-urlencoded, multipart/form-data, or text/plain content types is that if it did, that’d make CORS more restrictive than what browsers have already always allowed (and it’s not the intent of CORS to put new restrictions on what was already possible without CORS).
That is, with CORS, POST requests that you could do previously cross-origin are not preflighted—because browsers already allowed them before CORS existed, and servers knew about them. So CORS changes nothing about those “old” types of requests.
But prior to CORS, browsers wouldn’t allow you to do a cross-origin application/json POST at all, and so servers could assume they wouldn’t receive them. That’s why a CORS preflight is required for those types of “new” requests and not for the “old” ones—to give a heads-up to the server: this is a different “new” type of request that they must explicitly opt-in to supporting.
This question already has answers here:
Setting cookies for subdomain
(2 answers)
Closed 7 years ago.
I'm building a web app that uses http only cookie sent by the backend for session data. Now my backend is hosted at xyz.domain.com
My client side is domain.com (note - m not using www.domain.com )
Now when the client receives cookie , the browser doesn't save it. In crome i saw the cookie isn't first party.
After doing a bit of research i figured out to send cookie with domain - .domain.com
Tried that. Didn't work.
How should this be done.
Thank you
You should set domain attribute as your domain:
domain= .domain.com
If you can say which language are you working on and what have you tried so far, people may provide some good examples.
I have installed a (non wildcard) SSL certificate so my website can use HTTPS. When I try to request resources from HTTP urls I get error-message like:
Mixed Content: The page at 'https://example.com/' was loaded over
HTTPS, but requested an insecure stylesheet
'http://resources.example.com/style.css'. This request has been
blocked; the content must be served over HTTPS.
I get that it probably is a bad practice according to all kinds of opinions people might have when it comes to mix http and https, but I only ask for static resources that I don't regard as critical over http.
Tried to google "allow http requests from https with iis" and similar, but can't find a clear answer. Is there a way around this, is it solvable the same way CORS is?
Sorry if the question isn't very smart and if the answer is obvious, but I lack quite some knowledge some when it comes to networking stuff.
stylesheet ... static resources that I don't regard as critical over http.
CSS can include script and script can alter the page, so it is considered critical.
..."allow http requests from https with iis" ...
The decision to deny mixed content is done within the browser. There is no setting which will allow the browser to include mixed content. The behavior on what is considered mixed content differs between browsers and versions, look here for more information from a year ago.
... is it solvable the same way CORS is?
The security model of CORS cares about same origin policy and a server may decide that a specific other side might do a CORS request. But in this case it is the question if the content might be modified in transit by anybody (i.e. man-in-the-middle attack).