
Attacks like CSRF or XSS are still not clear to many of us. It is not because they are super hard to understand, but it requires some basic understanding of concepts like SOP, CORS, CSP, HTTPS. In this series of posts, I’ll try to clear them up one-by-one, and next time you read about attacks, you’ll understand everything.

![[posts/img/web-security-unknowns-same-origin-policy/cover.jpeg]]
<figcaption class="img-caption">Photo by <a href="https://unsplash.com/@randyfath">Randy Fath</a> on <a href="https://unsplash.com">Unsplash</a></figcaption>

## What is Same-origin Policy(SOP)

It is a security measure implemented by most browsers to protect users from the bad guys. It’s meant to keep you secure and it isn’t something new. It dates back to the old Netscape times. What it does is simple, blocks reading resources from other domains, only same-origin is allowed.

The resource here can be the DOM of an iframe you embedded in the page, a JSON response in an http request, or cookies.

Why does it exist? It’s there to keep you secure from the malicious scripts which might be running on the websites you visit. Although you’re visiting _evil.com_, scripts running on this site can make requests to _my-bank.com/get-account-details_, or embed an iframe with source _my-bank.com/get-account-details_ and then try to read the response/DOM to access your data. In case you think _“it’s fine as they don’t know my credentials”_, think twice. Browser will use existing cookies for _my-bank.com_ automatically. It means if you have an active session on _my-bank.com_, malicious scripts don’t need your credential.

There are also some common misconceptions on SOP. It does not block sending requests to the backend. It only blocks reading the response. _“That’s great, let me trigger a call to mybank.com/transfer-money in my malicious script. I just want the request to reach the backend, I don’t care about the response, I’ll see it in my bank account anyways”_ you might be saying. Not that fast. Of course, from SOP point of view, that’s perfectly fine. But, there are other security measures to prevent that. That’s the most important aspect you should really understand about SOP. Let’s repeat again: you can freely send any request to any domain, SOP does not care about requests, it only blocks reading the response from other domains.

Due to the same reason above, SOP not blocking the requests, it does not help with CSRF attacks. This attack relies on sending the request under the hood with the cookies you already have for that domain . It does not care about the response.

If you’re saying _“yes, there is no news here to me”_, great! you can stop reading. Otherwise, keep going.

## What is considered as same-origin

**Protocol** (http, https) **+Host** (example.com) **+Port** (8080)

Given definition above, [http://example.com/abc](http://example.com/abc) and [http://example.com/xyz](http://example.com/xyz) will be in the same-origin, but not

- [http://example.com:8000/abc](http://example.com:8000/abc) due to different port
- [https://example.com/abc](https://example.com/abc) due to different protocol
- [http://test.example.com/abc](http://example.com/abc) due to different host

## SOP to rescue

Please note that below examples assume there is no additional security checks at the backend and focuses on SOP only.

### iframe

What happens when you type _gmail.com_? Assuming you have an account and already logged-in before, it will show all your emails. Let’s say I own _evil.com_ and used an iframe to embed _gmail.com_ in it. Once you hit _evil.com_, can you imagine what can go wrong if I read the content in that iframe with JavaScript as being the owner of _evil.com_? Yes, you guessed it, I can read all your emails and even save them in some DB. But, don’t worry. Since you’re on _evil.com_, scripts running on this domain will not be able to read DOM content in an iframe from another domain (ie. _gmail.com_).

SOP saves the day and blocks reading the DOM of an iframe which belong to another domain.

### http request

I hear some of you saying _“I never used iframe, do you have some other example?”_. Okay, let’s give the same example without iframes. I own _evil.com_ and you visit it since you don’t know I do evil things. The JS code I added in _evil.com_ sends a GET request to _gmail.com/get-all-emails_. Do you think I’ll be able to send it?

The answer is yes (what?!). Just to point out again, SOP does not do anything for the requests, it blocks response only. My request will be sent to gmail and browser will get a 200 success. When my script tries to see the response, however, it won’t be able to, neither will you when you check Network/Response tab in Chrome dev tools. Browser will block it as SOP promised. (This can be relaxed using CORS though)

SOP rescues us again and blocks reading the response of an http request from another domain.

### cookies

Web mostly relies on cookies for authentication. Web server sets some cookies for its domain so that it can identify you when it receives a request from you. To keep things simple, let’s say when you login to _gmail.com_ it sets a cookie username="test@gmail.com" for domain gmail.com. Whenever there is a request going to gmail.com, your browser will add all your valid cookies belong to that domain. That means, when you call _gmail.com/get-all-emails_, it will also send username=”test@gmail.com” without you realising. And Gmail’s web server will see who you are from the cookie and return all the emails you have.

In real world, it’s not that simple. Gmail actually sets something to identify you, but it’s more complex and if anyone changes any part of that string, they would know and refuse to respond to your request.

I think it’s somewhat clear now that whoever has that string can actually get all your emails. So, it’s super important for the browser not to expose cookies from one domain to another one. Again, as being the owner of _evil.com_, I can send a request to _gmail.com_ on your behalf and browser will include all cookies belong to _gmail.com_ domain. But, the scripts running on evil.com won’t be able to read the cookies and server’s response. Yayy!

Just a small note on this: different protocol and port does not make a resource cross-domain for cookies. For example, [http://example.com](http://example.com), [https://example.com](https://example.com) and [https://example.com:7000](https://example.com:7000) are considered as the same-origin.

### form

_“What about if I use a form”_ I hear you ask. Let’s say I did some JS tricks and submitted a form using my malicious code running on _evil.com_ which sends a request to _gmail.com/send-email_ with the payload I provided in the code. Same goes here, browser will send it. But after submitting, browser will take you from _evil.com_ to the action url (ie. _gmail.com/send-email_), so _evil.com couldn’t_ read the response from other domains as the user is redirected to _gmail_. Please note, this is not a feature of SOP, just default form behaviour in browsers.

## Is everything coming from another domain blocked?

Nope. You can still

- Embed iframes
- Use image, audio, video files
- Import script and css files
- Submit forms

However, you

- cannot read the DOM of the iframe you embedded
- cannot read the files/bytes of the image, audio and video files.
- cannot read the content of JS, CSS files you imported
- cannot read the response of the submitted form

In addition to that, there are some techniques for relaxing SOP. You can use Cross-origin Resource Sharing(CORS), JSON with Padding(JSONP), and some others. Please note, this is not something browser can do alone to workaround SOP. Both frontend and backend need to be configured properly to achieve accessing cross-domain resources.

## Wrap up

Browsers implement SOP to keep your resources secure since you never now what’s going on behind the scenes when you visit _evil.com_. SOP does not prevent taking actions(sending requests etc), but makes sure bad guys won’t be able to see the outcome of that action(reading response/cookies/DOM).

It does not block you from using images, videos, scripts, css files from other domains. Long live CDNs! And there are ways to relax SOP by using things like CORS, JSONP.

Hope this post gave you some understanding of Same-origin Policy. Keep reading other unknowns in my other posts to have the full picture. Fell free to leave comments below.

We are going to create a single component that supports text, textarea, select, radio, and checkbox. It will absorb all implementation differences for different inputs and will allow us using a unified component in our Formik forms.

Creating a unified Formik input field to support all input types seamlessly

In this post, we are going to setup an environment with API Gateway, Lambda and DynamoDB using serverless framework which can be deployed to AWS directly or run fully local.

Going Serverless Offline

Multitasking is the source of all evil. Until recently, I also liked having multiple screens and multi-tasking like many others. It was great to code on one screen while reading the slack messages and emails on the other screen. But, it was so easy to get distracted by continuous incoming notifications while trying to read, write or code something. Often, I was feeling tired in the middle of the day because continuous context switching was draining my energy and destroying my focus on the task I was working on. 

5 Tips To Stop Multitasking and Double Your Productivity

Although what react is doing looks quite complex, underlying logic is very simple. And the easiest way to understand is just running some simple examples. We’ll dive into how react renders components and updates the actual DOM.

How React Rendering Works - A Step by Step Guide

Maybe you’re just getting started with distributed systems and system design, or you just need a quick recap for your upcoming interview. In either case, in this post, you’ll find the most common concepts of system design and the most important aspects of them. Let’s get started.

Recap of System Design Interview Concepts

You solved 60 LeetCode hard and 300 LeetCode medium questions, you were a rockstar in your coding round and provided the most efficient solution in the world, but you couldn’t get the offer. Sounds familiar? Either case, keep reading, you might find some useful tips.

How to Succeed in Your Coding Interview

Attacks like CSRF or XSS are still not clear to many of us. It is not because they are super hard to understand, but it requires some basic understanding of concepts like SOP, CORS, CSP, HTTPS. Let's start with what's Same-origin Policy

Web security unknowns: Same-origin Policy

DynamoDB is Amazon’s NoSQL database which offers single-digit milliseconds latency. It is great for variety of use cases, but when you need to run complex search queries on your dataset, you quickly realise it is not designed for it.

Indexing DynamoDB Items to ElasticSearch using AWS Lambda

While making a simple request to https://google.com to see that simple search page, there are a lot of things going on behind the scenes to keep you secure. Understanding this flow will give you a lot of confidence in various topics like Digital Certificates and Signatures, Symmetric/Asymmetric key encryptions, Certificate Authorities and how they all work together to help you have secure communication.

What happens when you hit google.com using HTTPS

System design questions can be asked for any level with different expectations from the candidate, but to get a Senior offer, you have to rock this round. Practice makes perfect - like for anything else, it applies for system design interview too. So, keep practicing without taking shortcuts, practice as if it’s the real interview and always follow the same steps to make it perfect.