Hacking Same-Origin Policy

• OWASP
• Hacking Same-Origin Policy

Same-Origin Policy

Alright, listen up! The Same-Origin Policy (SOP) is like the bouncer at the club, keeping sketchy scripts from one site from messing with data on another. It’s a hardcore security measure that keeps web vulnerabilities in check.

But here’s the deal—SOP is strict as hell, and most websites gotta work around it. And guess what? That’s where the real fun begins! Today, we’re diving deep into SOP, how it affects websites, and how attackers can flip the script and exploit it.

What’s the Same-Origin Policy (SOP)?

Straight up—SOP says that a script from Page A can only mess with Page B if they’re from the same origin. Period.

What Counts as Same-Origin?

Two URLs are considered same-origin if they have the same protocol, host, and port. Let’s break it down with an example.

Say Page A is at:

[https://z0rs.github.io/](HTTPS on port 443 by default)

Now, which of these are “same-origin” with it?

https://z0rs.github.io/ (same origin, same protocol, hostname & port)
https://z0rs.github.io/ (different origin, because protocol differs)
https://z0rs.github.io/ (different origin, because hostname differs)
https://z0rs.github.io/:8080/z0rs (different origin, because port differs)

What’s SOP Blocking?

SOP keeps scripts from Site A from reading data on Site B unless they match origins. The goal? To stop malicious scripts from hijacking sensitive info embedded in a different site’s DOM.

Heads up: SOP only restricts data access, not resource embedding. Stuff like images, CSS, and scripts? Those can still be loaded from anywhere.

Websites usually rely on HTTP cookies for authentication, and browsers automatically attach those cookies to requests. Without SOP, it’s open season for attackers.

Imagine This Nightmare

1. You log in to onlinebank.com.
2. Meanwhile, you open attacker.com in another tab.
3. If SOP wasn’t a thing, a sneaky script on attacker.com could swipe your session data from onlinebank.com and boom—game over.

This is why SOP is a big deal. It prevents scripts on attacker.com from reading any juicy data from onlinebank.com.

Loosening SOP (But Not Screwing It Up)

Yeah, SOP can be a bit of a buzzkill, especially for big websites with multiple subdomains that need to share data. So, how do sites bypass it without breaking security?

Tweaking document.domain

Setting document.domain on different subdomains (like a.domain.com and b.domain.com) to domain.com lets them talk to each other.

Warning: Doing this resets the port to null, which can behave differently across browsers. So, it might still not work in all cases.

Cross-Origin Resource Sharing (CORS)

CORS is like giving a VIP list to your bouncer. Servers can explicitly define which origins are allowed via Access-Control-Allow-Origin headers. If a request comes in, the server checks if the origin is cool or gets kicked out.

Cross-Domain Messaging (postMessage)

postMessage() lets pages chat across different origins safely—if done right. It’s commonly used between iframes and popups.

JSON with Padding (JSONP)

Old-school but still around—JSONP wraps JSON responses inside a function so they can be loaded via <script> tags (since scripts aren’t blocked by SOP). But let’s be real, now that CORS exists, JSONP is kinda obsolete.

Attacking SOP Like a Pro (Don’t Do This, Obviously 😉)

SOP isn’t bulletproof. If developers screw up, attackers can abuse it to leak sensitive data, hijack accounts, or bypass authentication.

XSS (Cross-Site Scripting) FTW

If an attacker injects JavaScript into a vulnerable site, that script runs under that site’s security context—completely bypassing SOP. That’s why XSS is a hacker’s best friend.

Abusing CORS Misconfigurations

Some websites try to be “too friendly” with their CORS policies. Common mistakes include:

• Weak regex validation: If a site allows all subdomains (e.g., www.site.com.attacker.com), an attacker can register that subdomain and slip through.
• Allowing null origin: Some devs unknowingly allow requests from null (like sandboxed iframes), which is basically a hacker’s golden ticket.
• Setting Access-Control-Allow-Origin: *: This seems dangerous, but it actually isn’t exploitable if credentials aren’t allowed.

Exploiting postMessage

If sites don’t validate who they’re talking to, attackers can:

1. Eavesdrop on data: If a site blindly trusts any incoming postMessage(), an attacker can create a fake site that listens and steals sensitive info.
2. Inject malicious data: If a page blindly processes incoming messages without checking the sender, an attacker can trigger unwanted actions on behalf of the victim.

Final Thoughts

SOP is one of the web’s OG security mechanisms, but it’s not flawless. Attackers are always hunting for weak CORS rules, bad postMessage handling, or XSS to get around it.

Stay sharp, secure your configs, and don’t let your site be an easy target. Peace! ✌️