Same Origin Policy, CORS, browser to server and server to server communication
Hello, I was reading a bit about
Same Origin Policy (SOP)
and Cross Origin Resource Sharing (CORS)
.
From what I have understood, a particular website can access data from its own origin
(that is, same protocol use, same domain and same port number). For example if abcd.com
tries to communicate with bank.com
, the browser will block that request unless on the server-side of bank.com
, CORS is enabled for abcd.com
.
Now, the reason why initially, we don't want any windows opened in the browser to be able to communicate/interact with another is to prevent malicious files from running and fetch data. For example, if abcd.com
was allows to fetch data from bank.com
, we could have fetch for e.g. user accounts and we don't want that. This is a communication from browser
to server
.
Now, what I wanted to know is communication from server
to server
. Normally, can abcd.com
server sends a request to bank.com
server? Here, is there anything blocking a request? Of course, to be able to send that request, we need a public endpoint but beside that?6 Replies
Cors is primarily a client side thing. Your client is the one that chooses to enforce it or not.
For example postman doesn't care about cors so it just ignores the fact that server response's header
Access-Control-Allowed-Origin
doesn't have the correct origin or the whole header is missing from response.
As for the server to server communication I'm not 100% sure but it's probably done via authentication/Authorization with session or tokens or something else.
Supabase for example only let's me upload files if i supply it with the correct secret key associated with my project and rejects me otherwise.hmm but cors is enabled server-side right?
If by enabled you mean server sets up the relevant headers then yes but it doesn't enforce cors by itself.
It will send the response regardless just with missing/wrong header values if the client origin isn't in whitelist
Then when browser gets the response and checks the headers, it will be the one that will enforce cors and reject the response. Preventing the client from accessing it
yep I see, ty !
question, the browser enforce the cors rule. But if we use api testing tool like postman, if we know an api route, this can cause security leaks, no?
That's what authentication and Authorization is for. Server checks if the requesting client is authenticated to access the api and they reject the request with a 401 response normally if the client is not authenticated
Cors is not a foolproof security measure. It's just one of the many tools to reduce attack opportunities for malicious people
yep I see
Thanks !