What is Same Origin Policy?
Same Origin Policy is a process that web browsers use to restrict how resources from one domain (webpage) can be accessed from another domain (webpage).
An example of a same-origin request is when you try to make a request from https://lesson.com to https://lesson.com/data. You can see that the URLs share the same protocol, hostname, and port.
Same-origin policy reduces vulnerabilities and prevents malicious threat actors from accessing sensitive data.
What are the limitations of the Same Origin Policy?
Same-origin policy is implemented within the client-side by the browser, this means it does not prevent server-side attacks.
If the browser is not configured properly, the same-origin policy can become inefficient.
When a web application needs to access a different resource, like a third-party API, cross-origin resource sharing should be configured to control access.
Cross-origin resource sharing is used to determine which websites are allowed to access resources on a server.
What is Cross-Origin Resource Sharing?
Cross-Origin Resource Sharing (CORS) allows controlled across different origins. For example, the sharing of resources between a server and a client. If the frontend and backend are hosted on different origins and CORS isn’t enabled, a CORS error will occur.
Cross-Origin Resource Sharing (CORS) allows certain requests and lets the server decide which origins can access its resources by using specific HTTP headers.
For example, when the browser makes a cross-origin request from the website From htttps://lesson.com to https://lesson.io, the browser includes an origin header in the request.
The https://lesson.io server would check if it wants to allow requests from https://lesson.com; if it does, it adds a response header like so:
(Access-Control-Allow-Origin: https://lesson.com )
This tells the browser it can go ahead and access the resource.
If the header is omitted in the request, the browser blocks access to the response and displays a CORS error.
Type of CORS Request
There are two main types of CORS requests:
Simple Request: A simple request is a type of cross-origin HTTP request that uses the GET, POST, or HEAD method. It is considered a simple request if it follows certain requirements, such as:
If these requirements are met, and the server responds with an Access-Control-Allow-Origin header that allows the origin making the request, the browser then permits the request.
Non-Simple Methods: When a request uses a non-simple content type, or HTTP methods such as PUT, DELETE, or PATCH, the browser sends a preflight request first. Preflight request asks the server for permission before making the main request.
The browser sends the following:
Preflight Request: The preflight is an OPTIONS request sent by the browser to check if the server would allow the request. If it does, the server responds with the right CORS header like so;
Access-Control-Allow-Origin: https://lesson.com,
and then it sends the actual request.
A preflight request is triggered when;
The request uses non-simple HTTP methods such as PUT, DELETE, or PATCH
The request includes custom headers such as authorization
The request has a non-simple content type, e.g., application/json.
Example of a preflight request;
fetch ("https://lesson.io/data", {
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": "Bearer myToken"
},
body:JSON.stringify({name:"Lesson"})
})
Before sending the POST request, the browser would automatically send an OPTIONS request. If the server responds with the appropriate CORS headers, the browser proceeds with the request.
Types of CORS Responses
The server uses the response header to share information about CORS with the browser, and the response may contain headers that include:
Access-Control-Allow-Origin: This header specifies which origins are allowed access to the server's resources. If the request origin doesn't match, the browser blocks access to the response.
Access-Control-Allow-Credentials: When a browser makes a cross-origin request, this header indicates whether the browser should include credentials such as an authentication token or cookies. This should have a specific origin and not a wildcard (*) value.
Access-Control-Allow-Headers: This header is used to respond to a preflight request. It tells the browser which headers are allowed in the main request.
Access-Control-Expose-Headers: This header specifies which response headers the browser is allowed to access from JavaScript. If the header is not specified here, it won't be accessible by client-side code.
What are the security implications of not enabling CORS?
If CORS is not properly configured it can lead to the following:
Data Exposure: If a server allows any origin, a malicious website can access sensitive data through the user's browser.
Loss of Trust and Integrity: Misconfigured CORS can cause users to become vulnerable to attacks which can lead to reputation damage.
Cross-Site Request Forgery: This is the type of vulnerability where a malicious site tricks a user's browser into making an unwanted request to another site where the user is authenticated. It uses the user's credentials, such as cookies, to perform unauthorised actions without their knowledge.
This is not a direct implication of CORS. However, Cross-Site Request Forgery (CSRF) can occur if there’s no proper CSRF protection in place, and if CORS is not properly enabled.
Benefits of CORS include the following;
Security: CORS helps prevent malicious websites from accessing sensitive information by enforcing restrictions during cross-origin requests. CORS reduces the risk of data exposure.
API integration: CORS is necessary for secure communication between web applications and external API integration, allowing developers to integrate third-party services (e.g., payment gateways) into their applications.
Standardization: CORS is supported by almost all major browsers, providing a reliable way to handle cross-origin requests.
Best Practices for CORS Implementation
CORS errors often result from server misconfigurations. There are several practices for implementing CORS, including;
Configure the server to allow CORS requests: Ensure that the server permits requests from only trusted origins. It is common practice to avoid using wildcards (*) in production, especially when sensitive data is involved.
Avoid the null origin: Null origin may occur in requests from local files on your computer or browser extension, and allowing them can introduce security risks.
Avoid wildcard value: Wildcards (*) are used for public APIs, but they can expose sensitive endpoints on private networks.
Only allow trusted sites: Use a strict whitelist of trusted domains that are allowed to access server resources.
Use a proxy to forward the request to the same origin: Using a proxy can help you bypass CORS legitimately. The proxy server fetches the data from the external API, as an intermediary, and then forwards it to your frontend.
Use the CORS browser extension: CORS browser extension is typically used for testing, you can use CORS everywhere extension to override CORS restrictions but it should be used for testing only, not for production.
Define the right appropriate access control headers: The server should always return the appropriate CORS headers e.g. Access-Control-Allow-Origin, Access-Control-Allow-Methods, etc.
Use security headers outside of CORS: Implementing additional security headers can add more security layers to your application.
