DEV Community

Cover image for ✋🏼🔥 CS Visualized: CORS
Lydia Hallie
Lydia Hallie

Posted on

✋🏼🔥 CS Visualized: CORS

It’s every developer’s frustration once in a while to see that big red Access to fetched has been blocked by CORS policy error in your console! 😬 Although there are some ways to quickly get rid of this error, let’s not take anything for granted today! Instead, let’s see what CORS is actually doing, and why it’s actually our friend 👏🏼

❗️ In this blog post I won’t explain HTTP basics. In case you’d like to know more about HTTP requests and responses, I wrote a small blog post about it a while ago though 🙂 In my examples I use HTTP/1.1 instead of HTTP/2, this doesn’t affect CORS.


On the frontend, we often want to display data that's located elsewhere! Before we can display this data, the browser first has to make a request to a server in order to fetch that data! The client sends an HTTP request with all the information that the server needs in order to send that data back to the client 🙂

Let’s say we’re trying to fetch some user information on our www.mywebsite.com website from a server that’s located at api.website.com!

Alt Text

Perfect! 😃 We just sent an HTTP request to the server, which then responded with the JSON data we asked for.

Let's try the exact same request but from another domain. Instead of making the request from www.mywebsite.com, we’re now making the request from a website located at www.anotherdomain.com.

Alt Text

Wait, what? We sent the exact same request, but this time the browser shows us a weird error?

We just saw CORS in action! 💪🏼 Let’s see why this error occurred, and what it exactly means.


✋🏼 Same-Origin Policy

The web enforces something called the same-origin policy. By default, we can only access resources that are located at the same origin as the origin of our request! 💪🏼 It's totally okay to load an image that's located at https://mywebsite.com/image1.png, for example.

A resource is cross-origin when it's located at a different (sub)domain, protocol, or port!

image3

Cool, but why does the same-origin policy even exist?

Let's say that the same-origin policy didn't exist, and you accidentally clicked one of the many virus links your aunt sent you on Facebook. This link redirects you to an "evil website" that has an iframe embedded which loads your bank's website, and successfully logs you in by some set cookies! 😬

The developers of this "evil website" made it possible for the website to access this iframe and interact with the DOM contents of your bank's website in order to send money to their account on your behalf!

Alt Text

Yeah... this is a huge security risk! We don't want anyone to just be able to access everything 😧

Luckily, the same-origin policy helps us out here! This policy makes sure that we can only access resources from the same origin.

Alt Text

In this case, the origin www.evilwebsite.com tried to access cross-origin resources from www.bank.com! The same-origin policy blocked this from happening and made sure that the evil website's devs couldn't just access our bank data 🥳

Okay, so... what does this have to do with CORS?


🔥 Client-side CORS

Although the same-origin policy actually only applies to scripts, browsers "extended" this policy for JavaScript requests: by default, we can only access fetched resources from the same origin!

Alt Text

Hmm, but... We often have to access cross-origin resources 🤔 Maybe our frontend needs to interact with our backend API in order to load the data? In order to allow cross-origin requests safely, the browser uses a mechanism called CORS! 🥳

CORS stands for Cross-Origin Resource Sharing. Although the browser disallows us from accessing resources that aren’t located at the same origin, we can use CORS to change those security restrictions a bit while still making sure that we’re accessing those resources safely 🎉

User agents (a browser, for example) can use the CORS mechanism in order to allow cross-origin requests which otherwise would've been blocked, based on the values of certain CORS-specific headers in the HTTP response! ✅

When a cross-origin request is made, the client automatically adds an extra header to our HTTP request: Origin. The value of the Origin header is the origin where the request came from!

Alt Text

In order for the browser to allow accessing cross-origin resources, it expects certain headers from the server's response, which specify whether this server allows cross-origin requests!


💻 Server-side CORS

As a server developer, we can make sure that cross-origin requests are allowed by adding extra headers to the HTTP response, which all start with Access-Control-* 🔥 Based on the values of these CORS response headers, the browser can now allow certain cross-origin responses which would’ve normally been blocked by the same-origin policy!

Although there are several CORS headers we can use, there is one header that the browser needs in order to allow cross-origin resource access: Access-Control-Allow-Origin! 🙂
The value of this header specifies which origins are allowed to access the resources that they're requesting from the server.

If we’re developing a server that https://mywebsite.com should have access to, we can add the value of that domain to the Access-Control-Allow-Origin header!

Alt Text

Awesome! 🎉 This header is now added to the response that the server sends back to the client. By adding this header, the same-policy origin will no longer restrict us from receiving resources that were located at the https://api.mywebsite.com origin, if we sent the request from https://mywebsite.com!

Alt Text

The CORS mechanism within the browser checks whether the value of the Access-Control-Allow-Origin header equals the value of the Origin that was sent by the request 🤚🏼

In this case, the origin of our request is https://www.mywebsite.com, which is listed in the Access-Control-Allow-Origin response header!

Alt Text

Perfect! 🎉 We were able to receive the cross-origin resources successfully! So what happens when we’re trying to access these resources from an origin that’s not listed in the Access-Control-Allow-Origin header? 🤔

Alt Text

Ahh yeah, CORS throws the notorious error that can be so frustrating at times! But now we actually see that it makes total sense

The 'Access-Control-Allow-Origin' header has a value
 'https://www.mywebsite.com' that is not equal 
to the supplied origin. 
Enter fullscreen mode Exit fullscreen mode

In this case, the supplied origin was https://www.anotherwebsite.com. However, the server didn’t have this supplied origin in the list of allowed origins in the Access-Control-Allow-Origin header! CORS successfully blocked the request, and we cannot access the fetched data in our code 😃

CORS also allows us to add the wildcard * as the value for the allowed origins. This means that requests from all origins should have access to the requested resources, so be careful!


Access-Control-Allow-Origin is one of the many CORS headers we can provide. A server developer can extend the server's CORS policies in order to (dis)allow certain requests! 💪🏼

Another common header is the Access-Control-Allow-Methods header! CORS will only allow cross-origin requests if they were sent with the listed methods.

Alt Text

In this case, only requests with a GET, POST, or PUT method will be allowed! Other methods such as PATCH or DELETE will be blocked ❌

If you're curious about what the other possible CORS headers are and what they're used for, check out this list.

Speaking of PUT, PATCH, and DELETE requests, CORS actually handles those requests differently! 🙃 These "non-simple" requests initiate something called a preflight request!


🚀 Preflighted Requests

CORS has two types of requests: a simple request and a preflighted request. Whether a request is simple or preflighted depends on some values within the request (don't worry, you don't have to memorize this lol).

A request is simple when the request is a GET or POST method and doesn't have any custom headers! Any other request, such as requests with a PUT, PATCH, or DELETE method, will be preflighted.

In case you’re just curious about which requirements a request has to meet in order to be a simple request, MDN has a useful list!

Okay sure, but what does "preflighted request" even mean, and why does this happen?


Before the actual request gets sent, the client generates a preflighted request! The preflighted request contains information about the actual request we’re about to in its Access-Control-Request-* headers 🔥

This gives the server information about the actual request that the browser is trying to make: what is the method of the request, what are the additional headers, and so on.

Alt Text

The server receives this preflighted request, and sends an empty HTTP response back with the server's CORS headers! The browser receives the preflight response, which contains no data besides the CORS headers, and checks whether the HTTP request should be allowed! ✅

Alt Text

If that's the case, the browser sends the actual request to the server, which then responds with the data we asked for!

Alt Text

However, if it’s not the case, CORS will block the preflighted request, and the actual request never gets sent ✋🏼 The preflighted request is a great way to prevent us from accessing or modifying resources on servers that don't have any CORS policies enabled (yet)! Servers are now protected from potentially unwanted cross-origin requests 😃

💡 In order to reduce the number of roundtrips to our server, we can cache the preflighted responses by adding an Access-Control-Max-Age header to our CORS requests! We can cache the preflighted response this way, which the browser can use instead of sending a new preflighted request!


🍪 Credentials

Cookies, authorization headers, and TLS certificates are by default only set on same-origin requests! However, we may want to use these credentials in our cross-origin request. Maybe we want to include cookies on the request that the server can use in order to identify the user!

Although CORS doesn't include credentials by default, we can change this by adding the Access-Control-Allow-Credentials CORS header! 🎉

If we want to include cookies and other authorization headers to our cross-origin request, we need to set the withCredentials field to true on the request and add the Access-Control-Allow-Credentials header to the response.

Alt Text

All set! We can now include credentials in our cross-origin request 🥳


Although I think we can all agree that CORS errors can be frustrating at times, it's amazing that it enables us to safely make cross-origin requests in the browser (it should receive a bit more love lol) ✨

Obviously there is so much more to the same-origin policy and CORS than I was able to cover here in this blog post! Luckily, there are many great resources out there like this one or the W3 spec if you want to read more about it 💪🏼

And as always, feel free to reach out to me! 😊

Twitter 👩🏽‍💻 Instagram 💻 GitHub 💡 LinkedIn 📷 YouTube 💌 Email

Discussion (66)

Collapse
vaibhavkhulbe profile image
Vaibhav Khulbe

This CS Visualized series is unique and a bomb because of those wonderful diagrammatical GIFs/explanation. I want to thank you for all the hard work you put in your articles.

Collapse
lydiahallie profile image
Lydia Hallie Author

Thank you! 😃

Collapse
ajiteshsingh profile image
Ajitesh Singh

welcome

Collapse
jreinhold profile image
Jeppe Reinhold

This is amazing - great down to earth explanation of how CORS works, but just as important, WHY CORS works. You rock!

If I may add, I think it's missing one of the most important parts of CORS, namely that it is NOT a reliable security measure. As it is an opt-in feature by the browsers, it can easily be bypassed by requesting with curl or Postman, or just by installing a browser extension that disables the policy client-side.
I've seen many software engineers mistakenly saying "oh, we've secured our endpoints with CORS, no unauthorized request can happen" - which is not true. It may prevent the user from being tricked into insecure flows (as you explained), but it will not stop hackers from explicitly trying to make malicious requests.

Collapse
yashsway profile image
Yash Kadaru

I love when anything is explained visually. This is so well made! Thank you!

Collapse
kewbish profile image
Emilie Ma

Really clear article - gj!

Collapse
hanskerkhof profile image
Hans Kerkhof

Great article, thanks! This article explains it so beautifully that I can send to colleagues back-enders who have a glassy look full of incomprehension when i mention I need CORS in the frontend. (and that happens more often than you think ;-) )

Collapse
pavelloz profile image
Paweł Kowalski • Edited on

Let’s say we’re trying to fetch some user information on our mywebsite.com website from a server that’s located at api.website.com!
...
Let's try the exact same request but from another domain. Instead of making the request from mywebsite.com, we’re now making the request from a website located at anotherdomain.com.

Either i dont understand the next couple sentences explaining how to tell if request is cross origin, or there is an error here, because it looks to me that both requests have been cross origin ;)

Collapse
jeromefitzpatrick profile image
jeromefitzpatrick

@Pawel Kowalski

You are correct - either this is an error or maybe api.website.com allows the mywebsite.com origin!

Collapse
owfm profile image
owfm

Sorry if I'm missing something... But in your very first example:

Let’s say we’re trying to fetch some user information on our mywebsite.com website from a server that’s located at api.website.com

And it goes through fine... How come this is not a cross origin request? It's a different domain and subdomain isn't it?

Collapse
epic_qi profile image
Epic Lee • Edited on

I believe that's a typo. Should both be mywebsite.com, otherwise it's a cross-origin request

Collapse
caioiglesias profile image
Caio Iglesias

You are correct. It's just an intro showing a request that works followed by one that fails. They seem similar, but are being affected by the same-origin policy.

api.website.com has to be returning Access-Control-Allow-Origin: https://www.mywebsite.com since the second example denies the request coming from anotherdomain.com.

Collapse
tommulkins profile image
Tom Mulkins • Edited on

Those animations really make it easy to digest the topic.

I might have missed it above but important to note that Access-Control-Allow-Origin allows for a single origin value. Otherwise the server will need some middleware to return the header with the right origin value when more than one origin is allowed.

developer.mozilla.org/en-US/docs/W...

Collapse
lydiahallie profile image
Lydia Hallie Author

Ohhh yes! I made the mistake once by padding an array instead haha. I'll update the post accordingly asap :)

Collapse
prof3ssorst3v3 profile image
Steve Griffith

Very well done.
One thing I would suggest pointing out to people is the HTTP Method OPTIONS for the Preflight request, and what that means on the server.
The OPTIONS method gives us a great hook to run server-side code that is specific to these preflight requests.

Collapse
serializator profile image
Julian van den Berkmortel

I guess I fell in love with the CS Visualised series right now, can't wait to read many more! 🎉

When I read about the "Origin" which is set on the request I thought "why not spoof it", obviously immediately after that I thought "if that would work I'd be Hans Klok" (I don't know whether that translation of the Dutch phrase works in English) 😅

Collapse
patarapolw profile image
Pacharapol Withayasakpunt

Does CORS affect cURL or wget? Or, does enforcing CORS help?

Collapse
lydiahallie profile image
Lydia Hallie Author • Edited on

Good question! By default, CORS is only enabled in user agents (e.g. a browser). So if I were to send the exact same request using cURL in say the terminal, this request wouldn't automatically contain the Origin header and CORS wouldn't be enabled.

If you want to test whether your server has CORS enabled, you can manually add the Origin header to the request. If the response contains the Access-Control-Allow-Origin header, you know it's working 😃

Collapse
charanweb profile image
CHARAN

Im a beginner but I understand so much only because of Animated/Gifs. Thanks is not enough for efforts and Hardwork. But Im jobless. I will definitely show my Gratitude when i get job. Thank you so much Mam❤️

Collapse
aryaorz profile image
Aryaorz

I hope you find these 10 CCNP 350-401 exam questions and answers helpful for your CCNP exam preparation!  We also provide PMP exercises download service.  Please contact us if you require a comprehensive 350-401 dump.  Kozypass 350-401 Practice exam is 100% unconditional and guaranteed exam!yinheedu.com

Collapse
a0viedo profile image
Alejandro Oviedo

I wanted to say first that I'm a big fan of your Visualized series! The amount of details and the quality of the animations is extraordinary.

Not-CORS-related question: what did you used for rendering the "SHORCUTS" table? is it plain HTML? It seems like anchor for the "Credentials" section is not working.

Collapse
bennycode profile image
Benny Neugebauer

@lydiahallie thank your for this very comprehensive article! Your illustrations and animations make dealing with CORS fun! Small note: The link to "a small blog post" actually shows a page called "essayhawk"?!

Collapse
mariofix profile image
Mario Hernandez

Very very easy to understand, thanks!!

Collapse
gitsanto profile image
RaiS4N2s

Your visual explanation is perfect for me to understand. Thank you @lydia.

Collapse
tcelestino profile image
Tiago Celestino

Great article.

Collapse
charan1692_10 profile image
Charan1692

Best articles with best GIF's . More power to you Lyndia.
Request : Can you write Blogs on Frontend Architecture.

Collapse
beginwithjs profile image
beginWithJS

How did you make those beautiful gifs ?It is awesome.Great Job!

Collapse
mitchobrian profile image
Michael Palmer

👍

Collapse
aaronjoemoreno profile image
aaron moreno

Amazing post. I didn’t realize you wrote this Lydia until I saw your pic at the end. Just saw your honeypot vid the other day. So awesome

Collapse
thatiitgirl profile image
thatIITgirl

WOW! I'm amazed with the clear explanation. Also Lydia, Could you tell me what software you are using for animations. I so want to work on that. :) . Please !!

Collapse
avcwisesa profile image
avcwisesa

Hi! This is an amazing post! I have to ask, how do you create these cool visualizations? Interested to try it out 😆

Collapse
rbaswmbrandel profile image
Marcus Brandel • Edited on

Is it possible/common that some server side error could occur which would prevent the full response from being generated so the Access-Control-Allow-Origin header is never returned on the response. Resulting in the dreaded CORS error. Even if the origin IS allowed?

Collapse
iamnihal profile image
Nihal

This is so nicely written. Thanks for this awesome article.

Collapse
artoodeeto profile image
aRtoo

I stand by my words. "YOU'RE THE GWOAT". Thank you for this.

Collapse
markgoho profile image
Mark Goho

They say there are two types of web developers: those that don't understand CORS and dirty, rotten liars. Thanks for proving there's a third option 😎

Collapse
shravan20 profile image
Shravan Kumar B

How do you create such apt animations?

Article was so neat and clean. Clever way of writing 👌

Collapse
reythedev profile image
Rey van den Berg

Thank you! These gifs give my brain life!
Fantastic explanations👏