Whenever you are testing a website for cross-domain attacks such as XSS, CSRF, Clickjacking, etc. you must encounter with CORS, SOP and CSPs.

Most of the cross-origin attacks becomes successful just becuase of miscofigured CORS and CSPs.

So, understanding These things are the backbone knowledge of Cross-domain attacks. And for that reason, i will cover,

• What are SOP and CORS?
• History of SOP
• Why CORS exists?
• What causes vulnerabilities?
• How they help protect oursleves?
• Roles of SOP and CORS in cross-domain attacks?
• How to prevent CORS-based attacks?

Let’s start with the just a normal short explaination.

CORS, SOP and CSPs are Web browser security mechanisms that protects user and data. These web browser security mechanisms helps to prevent cross-site attacks such as Cross-site Scripting, CSRF, Clickjacking, etc.

CORS & SOP both are connected to each other, in such a way, that if we want to understand what is CORS then first we have to understand SOP.

Meanwhile, CSP is a vast topic, Therefore i will cover that in upcoming blogs.

What is Origin?

There are mainly three things are considered when we talk about the Origin:

• Protocol (Schema): Protocol used in the url (i.e. http, https, etc.)
• Domain: Actual domain (They also include subdomains) ie. google.com.
• Port: Port number (if port is not showing in URL, the port number for those URLs considered as: 80)

If any URLs in which these three things are same, they will be considered as Same Origins.

What is SOP?

SOP is a Web browser security mechanism. Yes, you heard right! Most people misunderstood SOP and CORS. They think that SOP or CORS is just a rule or security mechanism inforced by the server. But in reality they are inforced by a web browser and they are more then just a rule.

• Stands for Same-Origin Policy.
• It is restrictive cross-origin specification
• that limits the ability for a website to interact with resources outside of the source domain.
• It allows a domain to issue requests to other domains, but not to access the responses.

History of Same-Origin Policy (SOP)

The Same-Origin Policy (SOP) was introduced by Netscape Navigator 2.02 in 1995 to prevent malicious scripts on one website from accessing sensitive data, such as cookies or DOM elements, on another site. It was created as a preventative measure following the introduction of JavaScript and the first cross-site scripting (XSS) attacks.

• Evolution: Originally focused on DOM access, the SOP expanded to cover Cookies, LocalStorage, and XMLHttpRequests/AJAX requests, ensuring that scripts can only access data from the same origin.
• Exceptions: While SOP blocks most interactions, it allows certain cross-origin actions, such as embedding images (<img>), scripts (<script>), and CSS (<link>).
• Modern Era: SOP is not a single standard but a core browser security mechanism interpreted across all browsers. Modern web applications use mechanisms like Cross-Origin Resource Sharing (CORS) to safely bypass these restrictions when necessary.

What is CORS?

CORS is a security feature that relaxes SOP by allowing a server to explicitly whitelist certain third-party origins to access its resources.

• Stands for Cross-Origin Resource Sharing.
• Many websites interact with subdomains or third-party sites in a way that requires full cross-origin access.
• A controlled relaxation of the SOP is possible using CORS.
• CORS uses suite of HTTP protocols that defines trusted web origins and associated properties
• Ex. Whether authenticated access is permitted
• These are combined in a header exchange between a browser and the cross-origin web site that it is trying to access.

Vulnerabilities arising from CORS configuration issues

Many modern websites uses CORS to allows access to subdomains and trusted third parties. Their implementation of CORS may contain mistakes or not strictly implemented as expected to ensure that everything works, and this can result in exploitable vulnerabilities.

Server-generated ACAO header from client-specified Origin header

Some applications need to provide access to a number of other domains. Maintaining a allow list for domains requires ongoing efforts, and any mistakes risk breaking functionality.

So application use other easy route of effectively allowing access from any other domain.

One way of to do this is by reading the Origin header from the requests and including header stating that the origin is allowed.

These header state that access is allowed from the domain (malicious-website.com) and that the cross-domain requests can include cookies (Access-Control-Allow-Credentials: true) and so will be processed in-session.

Because the application reflects arbitrary origins in the Access-Control-Allow-Origin header, this means that absolutely any domain can access resources from the vulnerable domain. If the response contains any sensitive information such as an API key or CSRF token, you could retrieve this by placing the following script on your website:

Errors parsing origin headers

Some applications that supports access from multiple origins do so by using a whitelist of allowed origins.

• When CORS request is received, it checks for whether the requesting origin is in the whitelist or not.
• If it appears on the whitelist then it is reflected in the Access-Control-Allow-Origin header so that access is granted.

Mistakes often arise when implementing CORS origin whitelist. Some organizations decide to allow access to all their subdomains (including their future subdomains that not even exists yet).

Some applications allow access from various other organizations’ domains including their subdomains.

These rules are often implemented by matching URL prefixes or suffixes, or using regular expressions. Any mistakes in the implementation can lead to access being granted to unintended external domains.

Whitelisted NULL origin value

The specification for the Origin header supports the value null. Browsers might send the value null in the Origin header in various unusual situations:

• Cross-origin redirects.
• Requests from serialized data.
• Request using the file: protocol.
• Sandboxed cross-origin requests.

Roles of SOP and CORS in cross-domain attacks?

Even Correctly configured CORS establishes trust relationships between two origins.

If website trust the origin that is vulnerable to XSS, then attacker could exploit the XSS to inject some JavaScript that uses CORS to retrieve sensitive information from the site that trusts the vulnerable application.

Intranets and CORS without credentials

Most CORS attacks rely on the presence of the response header:

Access-Control-Allow-Credentials: true

• Without that header, the victim user’s browser will refuse to send their cookies.
• Meaning the attacker will only gain access to unauthenticated content, which they could just as easily access by browsing directly to the target website.
• There is one common situation where an attacker can’t access a website directly: when it’s part of an organization’s intranet, and located within private IP address space.
• Internal websites are often held to a lower security standard than external sites, enabling attackers to find vulnerabilities and gain further access.
• For example, a cross-origin request within a private network may be as follows:

GET /reader?url=doc1.pdf
Host: intranet.normal-website.com
Origin: https://normal-website.com

And Server Response with:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *

How to prevent CORS-based attacks

CORS vulnerabilities arise primarily as misconfigurations. Therefore prevention is a configuration problem. The following sections describe some effective defenses against CORS attacks.

• Proper configuration or cross-origin requests

If a web resource contains sensitive information, the origin should be properly specified in the Access-Control-Allow-Origin header.

• Only allow trusted sites

It may seem obvious but origins specified in the Access-Control-Allow-Origin header should only be sites that are trusted. In particular, dynamically reflecting origins from cross-origin requests without validation is readily exploitable and should be avoided.

• Avoid whitelisting null

Avoid using the header Access-Control-Allow-Origin: null Cross-origin resource calls from internal documents and sandboxed requests can specify the null origin. CORS headers should be properly defined in respect of trusted origins for private and public servers.

• Avoid wildcards in internal networks

Avoid using wildcards in internal networks. Trusting network configuration alone to protect internal resources is not sufficient when internal browsers can access untrusted external domains.

• CORS is not a substitute for server-side security policies

CORS defines browser behaviors and is never a replacement for server-side protection of sensitive data — an attacker can directly forge a request from any trusted origin.

Therefore, web servers should continue to apply protections over sensitive data, such as authentication and session management, in addition to properly configured CORS.

Conclusion

Same-Origin Policy (SOP) and CORS are the backbone of browser security, quietly enforcing trust boundaries in an untrusted web.

• SOP prevents unauthorized cross-domain access, while CORS enables controlled data sharing without sacrificing safety.
• Most security failures arise not from their design, but from careless misconfigurations.
• When implemented correctly, SOP and CORS shut down cross-domain attacks, reduce data exposure, and turn the browser into a powerful security gatekeeper.
• Understanding them is not optional — it is essential for building secure, modern web applications.

If this blog helped you understand SOP and CORS better, give it a like 👍 and share it with someone building or securing web applications.

I’d love to hear your thoughts — have you ever encountered a real-world CORS misconfiguration or cross-domain issue?

Drop your experience or questions in the comments and let’s learn from each other.

Secure conversations build secure systems.

See you in the next blog, keep learning>>>