Same Origin Policy & Cookie Vulnerabilities

[00:00:00]
>> Steve Kinney: So let's just briefly kind of just talk a few more things about cookies, and then we will kind of get a little more nuance to everything we're doing. One of the policies that we'll see both in terms of how we can access resources when it comes to stuff like fetch and stuff along those lines, and slightly with cookies, there's some nuance to it is a foundational principle of the Web is this thing called the same origin policy.

[00:00:30]
Which is, if you've ever got yelled at by CORS, you already know what I'm talking about. And to be clear, if you've ever been like, I hate CORS, we'll change that by the end of this day, CORS is your friend. So the origin is basically a tuple, tuple with three parts in it, a triple, if you will, which is protocol, host and port.

[00:00:56]
If any of those things are different, then they are not the same origin, right? Which means host is the full subdomain and everything. So that would be whatever.frontendmasters.com, right? The port obviously in production is usually 80 for http, which we're not using anymore, right? Or 443 for https.

[00:01:18]
And then protocol is again, whether it's http, ftp, what have you. Cuz we all use ftp from the browser these days, right? If any of those change, they are not the same origin. Now, I will just see this in your brains now so we can reference it later.

[00:01:34]
You would think yeah, origin, that's like a site, same site and same origin mean two different things, kind of sort of. And we will talk about that in a little bit. And that is, again, one of those first places where the little nuances of the differences can mean everything for us.

[00:01:52]
And there have historically been lots of ways around it. There was the dark days of JSON with padding. Yeah, well Websock document.domain, which is interesting, there was a time period where you could actually on a given website be like, I understand that I am like stevekinney.net. But I wanna say that my domain is frontedmasters.com and that way we can be the same origin or site in this case.

[00:02:18]
Now it is super interesting because it seemed like a good idea, which is, because I couldn't just say that I am frontendmasters.com and access their stuff, right? They would also have to go in there and say they'd have to set, if you just redocumented that domain, it's whatever site you're on, the domain site, you could also set it.

[00:02:35]
So Frontend Masters could say, okay, in their code, document.domain equals Frontend Masters to opt in, and then if I did it on my site, we could share the same origin. What's the problem with that? So could anyone else. Right, it's like one of those good ideas that as soon as you think about it for an extra second, right falls apart.

[00:02:56]
So there have been various different ways around this, CORS is the acceptance Way. And so rather than thinking of course as some kind of burden, it is probably better to think about this course as a actual reasonable way to deal with the same origin policy that is in the browsers.

[00:03:09]
I did look up like, I was like, what was the world like before the same origin policy or anything along those lines, and there's not a lot of years in it. I think the same origin policy drops in like 2001, but it was something like when only IE5 had AJAX or whatever, there was a brief period of four years where they didn't simultaneously exist.

[00:03:29]
But it has always been the case that for most of modern web development for at least the last 20 years, they have always simultaneously existed. Cool, but as we kind of saw before, right, losing your cookies, man, can that be the title of this section? Losing your cookies has some bad things we saw, we could see, again.

[00:03:56]
I encrypted it, I signed it, I could still lose it, right? Someone could still get access to it, cuz again, if they can inject malicious JavaScript, right? There's a way that maybe they can get it now, if I say it's http only, I'm probably a little bit safer there as well, right?

[00:04:09]
If I do it over https, I'm safer than as well. Like cookies, arguably, because they're so important, have probably more safety mechanisms, and they are places where like Chrome and Firefox and Safari have just decided to break the web, right? Cuz in terms of we don't break the web, sometimes we do when in terms of cookies.

[00:04:26]
So a lot of times, cookies feel scary because they are usually the thing that got you in trouble or in the famous security vulnerabilities that we've seen. But because of that, they are also at this point have the most protections around them. But yeah if you have a problem with it, it is going to be problematic.