SOP vs CORS
Written by Eldar Zavida on
SOP vs CORS
Written by Eldar Zavida on
Introduction
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).
This article explores two key web development techniques for securing data fetching: Same-Origin Policy (SOP) and Cross-Origin Resource Sharing (CORS). We explain how they work, the issues they address, and compare their strengths, limitations, and use cases. By the end, you’ll understand SOP and CORS and know how to implement secure data-fetching mechanisms in your web applications.
History
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, letting attackers execute malicious code, steal user data, or perform unauthorized actions. To tackle these risks, Netscape Navigator introduced the Same-Origin Policy (SOP) in 1995.
SOP
The Same-Origin Policy (SOP) is a core security feature in all major web browsers that restricts web pages from making requests to a different origin. It protects users from attacks like Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), and data theft. SOP enforces a security boundary between origins, allowing only trusted interactions between pages from the same origin, 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.
ChatGPT said:
As web applications evolved, particularly with Single-Page Applications (SPAs) interacting with remote backend APIs, the need for secure cross-origin resource sharing emerged. To address this need securely, developers introduced the Cross-Origin Resource Sharing (CORS) mechanism.
CORS
Cross-Origin Resource Sharing (CORS) extends the Same-Origin Policy (SOP) by allowing controlled and secure cross-origin interactions. It lets web applications request and share resources across different origins while maintaining security. Before CORS, the SOP restricted web pages to the same origin, making it difficult for developers to access resources like APIs on other domains.
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.
ChatGPT said:
When the server allows an origin, it adds the “Access-Control-Allow-Origin” header to the response, granting permission. Conversely, if the origin is not allowed, the server omits this header, denying the request. In such cases, the browser will display a CORS error, indicating that the request violated the cross-origin resource-sharing restrictions.
Conclusion
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.