Instructor: In the last section,
we tried to create a new user account on our backend API,
but we very quickly got an error message down here
that said something like,
"No access controlled, allow origin.
Header is present on the requested resource."
So in this section,
we're gonna talk about what this error message means
and then very quickly figure out how we're going to fix it.
So first off, let's get a plain English definition
of what's going on here.
We're seeing this error message
due to something called a CORS error,
or a CORS request error.
CORS, spelled C-O-R-S,
stands for Cross Origin Resource Sharing.
CORS is a security feature
implemented inside of your browser.
So, specifically whatever browser you are using right now,
is what is really truly issuing this error message to us.
Let's take a look at a quick diagram
that's gonna help you get a better idea
of why we're seeing a CORS message at all.
Okay, so over here we're going to imagine for a second
that we are working on a completely different application.
I want you to imagine that you're working
on a banking application of some sort.
Maybe your application is hosted at my-bank.com.
And the primary purpose of your banking application
is to allow users to request to transfer money
from one account to another account.
So from my-bank.com,
you might load up a JavaScript file.
And whenever a user clicks on some button
inside of your application,
it runs some JavaScript that issues a request
to transfer money to our bank backend API,
hosted at my-bank.com/API/transfer.
So, everything I've showed you right here
ideally would be the way that our application would work.
But, let's imagine
that some really malicious person comes along.
And this is a person who wants to trick our customers
into creating requests to transfer money.
To send money from their account to the malicious person,
or the hacker's account instead.
So, maybe in an attack, some user,
or some very malicious person,
creates a new website called malicious-site.com.
Yeah, I know it should be pretty obvious it's a bad website.
But, let's imagine they create this website right here
and they trick some of our users going over to it.
So, some of our users,
for our banking application,
go over to this website and when this website loads up,
the user gets tricked into clicking a button
that makes that exact same request.
So, a user gets tricked into clicking a button
that tries to request to transfer money
from their account over to the hacker's account.
Now, the key thing to notice here
is that we are now at some different URL up here.
Some, malicious-site.com.
and we're going to try to issue a request to transfer money
over to our backend API,
hosted at my-bank.com.
So, in this situation right here,
we would want this request to fail.
We would want to figure out some way
to prevent a user, or some malicious person,
from making this impersonator website
and trying to make a request to transfer money
over to our backend API.
So, the mechanism that we use to disallow this behavior,
and this is just one mechanism
or one approach of many that we have
to prevent this sort of exploit right here,
are CORS requests or CORS restrictions.
So, let's talk about how we can use a CORS request,
or a CORS restriction,
to make sure that someone cannot make
this malicious-site.com website
and trick our users into making a request
over to our backend API.
Okay, so here's what happens behind the scenes.
Let's imagine that a user has been tricked
into going to malicious-site.com.
Some JavaScript code loads up inside that browser,
and it tries to make a request over to my-bank.com.
Now, our browser,
or your user's browser to be more precise,
is going to see
that specifically some JavaScript code
has tried to initiate a request to a different domain
than what the browser is currently at.
So right now,
this browser window is at the address of malicious-site.com.
Because this JavaScript code is trying to issue
a request over to our backend bank API,
which is hosted at a completely different domain,
so my-bank.com.
Our browser is gonna get suspicious.
The browser is gonna say, "You know what?
Something seems off here.
We're at this website,
but you're trying to make a request
over to this completely different website.
Something about that seems a little bit off."
So again, really important right here to understand
that this is our browser, specifically,
that is implementing the security rule.
The security rule,
and the fact that the browser finds this suspicious,
cannot be overridden.
It is hard-coded into your Chrome browser.
It is hard-coded into Internet Explorer, Firefox,
every other browser out there is hard-coded
to think that this is suspicious behavior.
So before, your browser says,
"Okay, you know, I'll process the request."
Your browser instead says,
"You know what? This seems really fishy.
I'm gonna follow up on this,
I'm gonna see if something just feels off here.
I wanna figure out what is going on with this request."
So before your browser
attempts to actually make that money transfer request,
the browser itself is going to do an initial request
over to our API.
This is the browser talking right here.
It's not our JavaScript code,
it is the browser talking and it says,
"Hey, API, banking API,
I'm trying to make a request over to you,
and the request is coming from a website
at malicious-site.com."
So, the browser specifically communicates to our backend API
and says, "You know,
I'm trying to make a request over to you,
it seems strange.
What do you think?"
So then, our backend API has the option,
it has the ability, to either allow the request
or disallow the request.
So, in this case, we might program our backend API to say,
"Hey, you know what browser?
I agree with you that does seem fishy,
and you should really only allow that request
if you're making it from my-bank.com."
And so, the backend API's response
goes back over to the browser,
and the browser says back to our JavaScript code,
it says, "Hey, you know what?
I'm so sorry about this,
but the server says that you cannot make a request
over to them at my-bank.com
while we, here inside the browser,
are at malicious-site.com.
That is seen as suspicious behavior,
something is off there,
and we're not gonna allow that to happen.
So, I'm sorry JavaScript code,
but we are not allowed to make that request."
So, that is exactly what's happening
inside of our application right now.
Our browser is currently looking at localhost:3000.
We have loaded up some JavaScript code
that is trying to make a request to a different domain.
Well, let's be precise here,
I wanna clarify that.
Just a second.
In both cases, we are at local host,
but the real comparison here,
the browser is gonna look to see
if there's a different sub-domain,
a different domain, or a different port.
If any of those things are different,
then this CORS stuff starts to kick in.
So in our case, we are at port 3000,
and we're trying to make a request over to port 3090.
And so our browser kicks in
and the browser specifically says,
"Something about this seems really off,
something is not right here."
So, the browser makes an initial request,
referred to as the pre-flight request right here,
and it asks our API, "Hey, you know what?
We are over on port 3000.
Is it okay if we make this request?"
And by default,
our express server is, by default,
configured to disallow CORS requests.
So, in response to our, excuse me, pre-flight request,
our express API essentially says back in return,
"You know, I'm so sorry, but you're on a different port.
I don't know what you're doing over on that website,
but definitely you can't make that request
over from that different domain or that different port."
And so our backend replies and says,
"Sorry can't do it, can't allow it."
And so, the browser in response says,
"Because of that, I'm sorry JavaScript code,
but the origin 3000 that you're at, looking at right now,
is not allowed access to that API running on port 3090."
Okay, so that is the summary.
That is like we've spoken about the initial theory
in this diagram
and then we've kind of applied it
over to our current running application.
So, that gives you a better idea
of why we're seeing this message.
Now, just some things I really wanna harp on here,
because this is some really important knowledge
and I can almost guarantee you,
I can almost promise you
that some aspects of all this stuff,
you might get asked at the job interview someday.
And I say that specifically 'cause I know I have.
So, some things I just really wanna clarify
about this one more time.
Again, the browser checks to see if the domain,
the sub-domain, or the port are different
when it makes a request over to this other API,
running on a different sub-domain, domain, or port.
If any of those things are different,
then this CORS stuff kicks into play.
That's step number one, that's important fact number one.
Important fact number two,
is to understand that this is specifically
a browser implemented security precaution.
So, it's solely the fact
that we are trying to execute
some JavaScript code inside of our browser,
that this CORS stuff kicks in.
And it is specifically the browser
that is making this limitation, or making this restriction.
That's why you probably see online,
if you go look at a lot of Stack Overflow posts,
you will see a lot of people saying like,
"How do I circumvent this error?"
You'll see people saying, "How do I get around this?
How do I make the browser just allow this request?"
And the answer is, you can't.
The entire idea behind these CORS restrictions,
are to keep developers, from you and I,
from trying to make nasty requests
over to some backend API that we don't control.
So, it is specifically your browser
that is doing the security check.
The reason that's so important,
is that it also explains
why you and I were able to make requests from Postman
when we were putting together our server.
When you make a request from Postman,
Postman says, "Hey, you know what? I don't care.
I don't care if you try to make a request
to this different API.
I'm not really the browser
and you can do anything you want."
So API clients like Postman,
or if you're running curl at the terminal,
they do not have this CORS stuff implemented.
So they don't care about this stuff.
It's specifically your browser
that tries to implement this security stuff,
solely on behalf of your users,
who probably have no idea
what web security is in the first place.
Alright, so that's it, that's my spiel on CORS.
So, now that we've got a better idea of what's going on,
we're gonna continue the next section
and we'll talk about
how we're going to solve this whole big issue.
So quick, quake and I will see you in just a minute.