A Detailed Guide on CORS in 2023
If you are short of time, here is the quick version:
- CORS stands for Cross-Origin Resource Sharing. It is a security measure enforced by modern browsers such as Chrome
- CORS applies when a browser is trying to communicate with an external server
- The browser needs to know if the website that it is currently showing — has the permission to make requests to the server.
- It is a security measure to ensure that only the allowed websites with the pre-approved urls can access the appropriate servers and this measure is adopted by all major browsers
If you can stay longer, read on.
If you are thinking of switching to a career in tech or changing to a new tech job, here are some job sites you can get started with:
- https://underdog.io
- https://dailytechjobs.com
- https://www.hiretechladies.com
- https://weworkremotely.com
Do something today!
Looking at CORS from a browser’s perspective
A user navigates to a website at www.somewebsite.com.
What does the user see at www.somewebsite.com?
They will see your frontend application in their browser. This frontend application was served from a CDN or servers hosting the frontend application to the user’s browser.
Pro Tip:
Do not confuse a browser with the frontend application.
A browser is used to surf the internet such as Chrome which was made by Google.
A frontend application is a piece of software a Software Developer develops to let the user interact with your website.
For example, the User Interface (UI) you see on a website is part of the frontend application.
Say for example:
A user wants to login to your website.
If you are building a serious application, the user should ideally be authenticated.
The user clicks on the login button after entering their username and password, and this triggers some Javascript code running in your frontend application, which in turn sends a HTTPS request to another server, let’s call it the user authentication server.
An authentication server’s sole purpose is to check whether the user has entered the correct username and password.
The server usually does this by checking the information the user has entered with the record in the database.
But before the request can be sent off to the server the browser stops the request in its track, “hold up matey!”.
The browser tells the request to wait while it does the checking. This checking refers to the browser asking the authentication server for permission to do something on it.
In our case, that something is to authenticate the user.
Pro Tip: CORS will only be triggered if the website url is different to that of the server.
If the website's url is: www.boringexample.com
and the server's url is: www.interestingexample.com
Then the CORS rules will be applied by the browser. Servers also have URLs?
Yes, think of it as a unique address for the servers on the backend.
We need to use this unique address in the frontend so that we know where to send our HTTPs requests.
Pro Tip:
The URL for a backend server is just a mapping for the server's real address
which is actually called an IP address and it is represented by numbers
so if we make an API call to the backend at "medium.com/myblog",
the request first goes through the DNS system
to find the IP address for medium.com, once we found the address, we forward
the request to the server and look for resources located at this path: /myblogSo it isn’t just websites that have urls — backend servers can have urls too.
So if you were on the Medium website at “medium.com/someblog” but you wanted to make an asynchronous HTTPS request to a server with a domain of “example.com”, then your browser will enforce CORS on that HTTPS request.
In short, it blocks your HTTPS request from reaching the server until the browser knows that this web application at this URL has permission to make such a request.
"medium.com/someblog" !== "example.com"Let’s take a step-by-step look at the CORS flow:
This section will go over things like preflight request and CORS configurations.
- The client/frontend application (e.g. a React application) makes a HTTPS GET request to a server to retrieve some data.
- The browser intercepts this HTTPS request and blocks it from going to the server temporarily.
- The browser then sends a preflight request to the server first, asking the server if it is okay to make a HTTPS request to it from the current webpage url in the browser e.g. medium.com/my_profile (see below for more details about preflight requests).
- The server then checks it’s own CORS configuration (some records on the server) to make sure that the origin (i.e. the url from the webpage that is making the HTTPS request) matches with the url origin the server has on record i.e. in the CORS configuration.
- If the browser’s url does have permission, then the server will send back a preflight response to the browser (see below)
- The browser receives the preflight response and knows that everything is ok, so it allows the original HTTPS GET request to be sent to the server
- The server receives the original HTTPS GET request and processes it for example getting some data from a database
- The server sends the requested data back to the browser and the data is now available in your frontend application
- Finally, your frontend application executes some logic and displays the data on the screen for the user
What the heck is a preflight request anyways?
A preflight request is made with a HTTPS OPTIONS method so don’t assume that it is made with a GET method.
A preflight request is NOT made with a HTTPS GET method.As a developer you would probably be thinking how you would go about writing code to make such a preflight request in the frontend code.
This same question popped into my head:
So who makes the preflight request to the server?
And here is a VERY useful answer to that question from the awesome MDN website:
“A preflight request is automatically issued by a browser and in normal cases, front-end developers don’t need to craft such requests themselves”
You can read more about it here:
What does the browser need to know before unblocking CORS?
It needs to first wait for a preflight response back from the server it plans to make a HTTPS request to.
Pro Tip: DO NOT confuse a frontend application with the browser.
They are separate things! For example, if we were making a HTTPS request from “medium.com” to an external server on “example.com”, then the external server at “example.com” could send a response back to the browser like this:
let responseObj = {
statusCode: 200,
body: JSON.stringify(body),
headers: {
'Content-Type': 'application/json',
'Access-Control-Allow-Origin': 'medium.com'
}
};return responseObj
For CORS, the important bit is this part:
The browser needs to find this information in the preflight response from the server.
'Access-Control-Allow-Origin': 'medium.com'What should I be thinking about after this?
The “Access-Control-Allow-Origin” is only sending back “medium.com” — what about if my user is on “medium.com/someblog”? Would CORS be okay with just “medium.com”?
So what is considered as same-origin policy by CORS?
This is a snippet taken from the MDN site:
“Two URLs have the same origin if the protocol, port (if specified), and host are the same for both. You may see this referenced as the “scheme/host/port tuple”, or just “tuple”. (A “tuple” is a set of items that together comprise a whole — a generic form for double/triple/quadruple/quintuple/etc.)”
Examples from the MDN site:
For example, if you were making a request to a server and the CORS configuration allows for “https://store.company.com”, then the following urls will be allowed by CORS:
So if you were making a request to that server from https://store.company.com/dir2/other.html, then CORS will allow the request to be sent to the server.
CORS will treat them as “same origin” because only the paths differ.
Only the paths differ!Paths here refers to anything after https://store.company.com
You can read more about Access-Control-Allow-Origin here:
If you need help with learning Javascript or your Javascript coding interview, you can reach out to us at team@remoteupskill.com
We publish short tech tutorials on a regular basis so consider subscribing to our Medium Blog.
Until next time — keep coding while moving small steps forward on this coding adventure of yours.
But more importantly, stay focused!
