DEV Community

Cover image for Know The Web: SOP (Same Origin Policy)

Know The Web: SOP (Same Origin Policy)

souvikinator profile image Souvik Kar Mahapatra ・Updated on ・4 min read

Hey folks! in this post we'll learn about SOP (Same Origin Policy).

Before understanding what SOP is and why we need it, let's ask a question

What will happens if

If I try to access or modify an iframe contents using JS? Let's find out,

<iframe name="my_frame" src=""></iframe>
Enter fullscreen mode Exit fullscreen mode

and open it in your browser. Now head over to the dev tools console and try accessing it using JS like so:

Enter fullscreen mode Exit fullscreen mode

Boom! we go an error:

VM1678:1 Uncaught DOMException: Blocked a frame with origin "null" from accessing a cross-origin frame.
at :1:17

notice, it says blocked frame from accessing cross-origin frame i.e since the origin inside the iframe and the origin of our website doesn't match the browser won't allow us to access the iframe contents.

Same Origin Policy

MDN Docs says:

The same-origin policy is a critical security mechanism that restricts how a document or script loaded from one origin can interact with a resource from another origin. It helps isolate potentially malicious documents, reducing possible attack vectors.

Okay so what they say is pretty clear but what is origin? How do we know whether two origins are the same or not?


Origin is the combination of protocols/scheme, hostname and port number.

origin without port number


origin with a port number

now, not to get confused with URL and origin, both are different. Head over to Now in the console do the following:

difference between URL and Origin

it's difficult to draw curly brackets πŸ˜… but now you can see the difference between URL and Origin.

Here is an example to understand same-origin and cross-origin

origin-1 origin-2 cross-origin or same-origin same-origin as 80 is default port number for http same-origin as a port, protocol, and hostname are same cross-origin as the protocol differs. Origin-1 has http and origin-2 has https cross-origin as origin-2 is subdomain(www) cross-origin as the top-level domain(.com,.net) in hostname do not match

from the above table, we can conclude that for two origins to be the same their protocols,hostname, and port number(if mentioned) have to be the same. Try testing the above examples using location.href and location.origin in the browser console.

We can explain why we were unable to access the content inside iframe in the very first question we asked. As the origin of our webpage and that of the website inside the iframe were different. Let's try to access iframe contents when the origin is same, here is a simple node js server:

const app=require('express')();
const path=require('path');


    res.send("Hi! I am inside iframe.");

   if(err) console.log(err);
Enter fullscreen mode Exit fullscreen mode


    <h1>Hi! I contain an iframe</h1>
    <iframe name="my_local_frame" src="/abc"></iframe>
Enter fullscreen mode Exit fullscreen mode

after running, head over to http://localhost:8080. we access the iframe content and boom! we get no error.

can access iframe content with same origin

if we check origin:

origin outside iframe

origin of iframe content

Okay, so things are pretty clear now. You may ask, how webpages are able to load external scripts and resources from CDNs, their origin does not match. It should rather block them.

Why would it block it?

SOP's purpose is not to block the dynamic loading of scripts, but to prevent a script from one site to access the data of another site.


Suppose, Same-Origin Policy didn't exist.

Let's say you visit, you log in, you get a valid session cookie & then you leave without logging out.

Next, you visit which tries to impersonate you & send an evil request to your browser). Since you never logged out & you still have a valid session cookie (which follows every request your browser makes to, the target will recognize your browser & (may) accept the evil request. This is called Cross-Site Request Forgery (CSRF). Using this attack, the attacker can access your personal details or may end up changing your account credentials and you are no longer able to log in.

This is where SOP comes into play.
Although the evil request won't be blocked by your browser (it's up to to protect itself against CSRF attacks), the response won't be made available to
So even if is misconfigured & falls for a CSRF attack that requests your personal info, for example, SOP won't allow to see that info.

That's what SOP does and that's all for this post. Feel free to suggest improvements and point out any mistakes :)

Discussion (0)

Editor guide