SOP vs CORS
Written by Eldar Zavida on
SOP vs CORS
Written by Eldar Zavida on
In web development, it’s common for web applications to fetch data and resources from various sources. However, doing so can expose users to security and privacy risks. As a mitigation method, web developers use two techniques – Same-Origin Policy (SOP) and Cross-Origin Resource Sharing (CORS).
In this article, we will explore the two fundamental techniques used in web development to mitigate security and privacy risks associated with fetching data and resources from different sources: Same-Origin Policy (SOP) and Cross-Origin Resource Sharing (CORS). We will dive into the concepts behind SOP and CORS, discussing how they work and the problems they aim to address. Additionally, we will compare and contrast these two techniques, examining their strengths, limitations, and appropriate use cases. By the end of this article, you will have a comprehensive understanding of SOP and CORS, enabling you to make informed decisions when implementing secure data fetching mechanisms in your web applications.
As the World Wide Web was evolving, In the mid-1990s, web browsers were becoming increasingly popular, and developers started building more interactive and dynamic web applications. Along with the growing complexity of web applications, security vulnerabilities have become a concern. In those early days, web browsers did not have strict security mechanisms in place to prevent malicious activities. Websites could load scripts and resources from any origin, which allowed attackers to execute malicious code on websites and exploit vulnerabilities to gain unauthorized access to user data or perform actions without the user’s consent.
To address these security concerns, “Netscape Navigator”, one of the early web browsers, introduced the concept of the Same Origin Policy in 1995.
The Same Origin Policy (SOP) is a fundamental security mechanism implemented by all major web browsers that restrict web pages from making requests to an origin (exact definition will be elaborated later) that is different than the web page and protects users from various web-based attacks such as Cross-site Scripting (XSS), Cross-site Request Forgery (CSRF), and sensitive data theft. The SOP was designed to enforce a security boundary between different origins, allowing only trusted interactions between web pages from the same origin, which is defined by three components:
- Protocol (e.g., HTTP/HTTPS)
- Host (e.g., www.example.com)
- Port (if specified, e.g., 80/443
Two web pages are considered to have the same origin only if all three components match. In the table below, the SOP checks are demonstrated against a specific URL.
However, as web applications became more sophisticated and interactive with advanced technologies, such as Single-Page Applications (SPAs) that usually communicate with a backend API remotely, a legitimate need for controlled and secure sharing of resources between different origins has arisen. To address this need while still maintaining security, the Cross-Origin Resource Sharing (CORS) mechanism was introduced.
Cross-Origin Resource Sharing (CORS) is a mechanism that builds upon the SOP to loosen the restrictions on cross-origin interactions in a controlled and secure manner. CORS enables web applications to make cross-origin requests and share resources between different origins while maintaining the necessary security measures. Before CORS was introduced, the SOP strictly enforced that web pages could only make requests to resources located on the same origin (as mentioned earlier), which posed a challenge for web developers who needed to interact with resources from different origins, such as accessing data from an API hosted on a different domain.
When a web application initiates a cross-origin request, the web browser sends an HTTP request with an “Origin” header, indicating the originated domain for the requesting resource in its value.
The server receiving the request can then respond with specific CORS headers that inform the browser about the permissions granted for cross-origin access. For example:
- Access-Control-Allow-Origin: Specifies which origins are allowed to access the server’s resources.
- Access-Control-Allow-Methods: Specifies the HTTP methods that are allowed for cross-origin requests (e.g., GET, POST, PUT, DELETE).
- Access-Control-Allow-Credentials: Indicates whether the server allows the inclusion of credentials (cookies, tokens) in cross-origin requests.
Those headers allow the server to grant or deny access based on the checks via the “Origin” header for protocol, host, and port (similar to the SOP mechanism).
Developers can define in their code a specific origin, a white list of origins, or a wildcard “*” value allowing requests from any origin.
If the server allows the origin, it will include the “Access-Control-Allow-Origin” header in the response, indicating that the request is permitted. However, if the origin is not allowed, the server will remove this header, signaling that the request has been denied. In such cases, the browser will display a CORS error, indicating that the request violated the cross-origin resource-sharing restrictions.
Implementing the Same Origin Policy (SOP) and Cross-Origin Resource Sharing (CORS) mechanisms plays a critical role in mitigating security threats posed by malicious scripts in web applications. SOP acts as an essential security measure, enforcing restrictions on script interactions between different origins, thereby preventing unauthorized access to sensitive data, user credentials, and unauthorized actions. By strictly enforcing SOP, browsers establish a robust security barrier that ensures the integrity and privacy of user browsing sessions.
On the other hand, CORS provides a controlled mechanism for legitimate cross-origin communication, allowing resources to be shared selectively across origins while maintaining essential security controls. CORS enables servers to specify access permissions for different origins, reducing the risk of unauthorized data exposure and enhancing overall web security. By combining the power of SOP and CORS, web developers can establish a comprehensive security framework that protects against security threats, enhances user privacy, and promotes secure and reliable web experiences.