In-Depth Understanding of Browser Cross-Origin Principles and Multiple Solutions to Cross-Origin Issues

Cross-origin issues are a very common problem in front-end and back-end separated development. This article will provide a detailed explanation of the principles behind browser cross-origin behavior and summarize multiple solutions to resolve cross-origin issues.

Cross-origin refers to the scenario where JavaScript scripts running in the browser make requests to servers of different origins, but these requests are restricted by the browser's Same-Origin Policy.

The Same-Origin Policy is an important security mechanism that limits how scripts loaded from one origin can interact with resources from other origins. This is to prevent malicious websites from stealing sensitive data without the user's knowledge.

In other words, cross-origin issues occur only when client-side requests are made from a browser to a server. These issues do not exist in other scenarios because cross-origin restrictions are enforced by the browser.

Two URLs are considered same-origin if they meet all of the following conditions:

• Protocol is the same (e.g., http:// and https:// are considered different origins).
• Domain name is the same (e.g., example.com and api.example.com are considered different origins).
• Port number is the same (e.g., http://example.com:80 and http://example.com:8080 are considered different origins).

If any one of these aspects is different, the browser will classify it as a cross-origin request.

The Same-Origin Policy was introduced to protect users' privacy and data security by preventing malicious websites from accessing sensitive information without authorization. Browsers, as the core tool for client-server interactions, have access to sensitive user data like cookies and session information. Without Same-Origin restrictions, malicious websites (e.g., phishing sites) could easily exploit these data to launch attacks.

If the Same-Origin Policy were absent, security vulnerabilities such as Cross-Site Request Forgery (CSRF) would become far more severe and challenging to prevent.

CSRF is an attack where a malicious website exploits the user's authenticated session on a target website to perform unauthorized actions, such as transferring funds or modifying account information.

For example, suppose a user is logged into a banking website like https://bank.com, and the browser has stored a valid login cookie. If the user unknowingly visits a malicious website like http://malicious.com, the malicious site can make requests like the following:

<img src="https://bank.com/transfer?to=attacker&amount=5000">

Since the browser automatically includes the user's login cookie in the request, the banking server may mistakenly treat the request as legitimate and complete the transfer.

1. Blocking Cross-Origin DOM Access
   The Same-Origin Policy prevents JavaScript from directly accessing content on pages from a different origin, ensuring that malicious scripts cannot steal sensitive data.

2. Restricting Access to Cookies and LocalStorage
   Browsers only allow scripts from the same origin to access cookies, LocalStorage, and SessionStorage. This prevents unauthorized sites from stealing user data.

3. Restricting Cross-Origin XMLHttpRequest and Fetch Calls
   The Same-Origin Policy blocks front-end cross-origin requests unless the target server explicitly allows them through mechanisms like CORS (Cross-Origin Resource Sharing).

4. Preventing Cross-Origin iframe Script Interaction
   The Same-Origin Policy prohibits scripts in cross-origin iframes from interacting with each other, ensuring that pages from different origins cannot directly share data.**

1. Frontend-Backend Separation
   In a frontend-backend separated architecture, the frontend might run on https://frontend.example.com, while the backend service operates on https://api.example.com. When the frontend sends AJAX or Fetch requests to the backend, cross-origin restrictions are triggered.

2. Cross-Origin with Different Ports
   During local development, the frontend might run on http://localhost:3000, while the backend serves requests on http://localhost:5000. Since the ports differ, the browser treats them as different origins, leading to cross-origin issues.

3. CDN or Third-Party Services
   When the frontend loads resources (e.g., fonts, JavaScript files) from an external CDN, or interacts with third-party services, the browser may block the request if the service is not properly configured to handle cross-origin responses.

To address cross-origin issues, solutions can be implemented at the frontend, backend, or through a proxy layer.

JSONP (JSON with Padding) is a technique used to solve browser cross-origin issues. It leverages the <script> tag’s ability to load external scripts without being subject to cross-origin restrictions. Below is a detailed explanation of its principles, implementation steps, advantages, disadvantages, and use cases.

Principle

The core idea of JSONP is dynamically creating a <script> tag to load remote scripts. Since browsers do not enforce cross-origin restrictions on <script> tags, this allows fetching data from different origins.

In a JSONP request, the frontend specifies a callback function name when requesting data from the server. The server responds by wrapping the data in JavaScript code that calls the callback function, enabling data transfer to the client.

Implementation Steps

1. Client Prepares the Request:
   The frontend dynamically creates a <script> tag to send a request to the server. The request includes the name of the callback function.

   function handleResponse(data) {
       console.log(data);
   }
   
   const script = 

Advantages and Disadvantages

• Advantages:

  • Simple and Easy to Use: JSONP requires minimal setup; you just need to specify the callback function name in the request.
  • Good Compatibility: It works with older browsers since it relies on <script> tags instead of modern APIs like XMLHttpRequest.

• Disadvantages:

  • GET Requests Only: JSONP supports only GET requests and cannot handle POST or other HTTP methods.
  • Security Risks: JSONP executes JavaScript code directly, which may lead to XSS (Cross-Site Scripting) attacks if the server returns untrusted code. This poses a risk of sensitive data being stolen.
  • Debugging Challenges: Since the response is JavaScript code, debugging JSONP requests is less convenient compared to standard JSON responses.

Use Cases

• Public APIs: Many public APIs support JSONP, enabling developers to easily fetch data from external services.
• Third-Party Services: JSONP is a quick and straightforward solution for fetching data from third-party services, particularly when the backend does not support CORS.

CORS (Cross-Origin Resource Sharing) is a mechanism that allows browsers to make requests to servers with different origins. To ensure security, when a browser sends a complex cross-origin request, it first sends a preflight request.

Here are some key points to note:

• Do all cross-origin requests trigger preflight requests?
  No, only non-simple requests trigger preflight requests. Simple requests do not.

• If there’s a preflight request, is it always a cross-origin request?
  Yes, preflight requests are part of the CORS mechanism and occur only for cross-origin requests.

What is a Preflight Request?

A preflight request is an OPTIONS request that the browser sends before making the actual cross-origin request. Its purpose is to ask the target server whether the actual request is allowed. This mechanism mainly handles complex requests, such as those using HTTP methods like PUT or DELETE or those with custom headers.

• Simple requests do not trigger preflight requests.
• Non-simple requests require a preflight request.

What is a Simple Request?

A cross-origin request is considered a "simple request" if it meets the following conditions:

1. Request Method: The request uses one of these methods:

   • GET
   • POST
   • HEAD

2. Request Headers: Only the following headers are included (these are automatically set by the browser for "safe" CORS requests):

   • Accept
   • Accept-Language
   • Content-Language
   • Content-Type (limited to application/x-www-form-urlencoded, multipart/form-data, or text/plain)
   • DPR
   • Downlink
   • Save-Data
   • Viewport-Width
   • Width

3. No Custom Headers: The request does not include any developer-defined custom headers.

4. No Special Mechanisms: The resource does not use complex mechanisms, such as...