Contents

About CORS(2)

   Jun 13, 2023     1 min read

This is an article about Cross-Origin Resource Sharing (CORS).

CORS Basic Sequence of Events

Developers often encounter the Cross-Origin Resource Sharing (CORS) error when dealing with APIs (especially FE developers!).

—.

Why does the browser, which sits between the client and the server, have a policy like CORS?

Because they can be exploited because they go straight through the webserver to make the request. To understand this, we need to be aware of the Same-Origin Policy (SOP).

  • An SOP is a security mechanism that restricts scripts running in a web browser from interacting with resources loaded from a different source (origin).
  • Making exceptions to the SOP is CORS! It allows cross-origin resources to be allowed within the scope of the policy, or allows the SOP to be bypassed by setting certain headers on the server side.
Here’s an example: It makes me wonder. How can this be exploited if it goes through a webserver?

Let’s take a look at the specific ways that making requests through the web server can be exploited.

  1. XSS attacks: XSS is an attack in which a malicious user injects a malicious script into a web page to be executed in another user’s browser. If you have access to resources on another domain, a web page with malicious scripts can steal or manipulate information by accessing resources on another domain.
  2. CSRF attacks: CSRF is an attack in which an authenticated user sends a request to a specific website against their will, based on the intentions of an attacker. If the resources of another domain are accessible, the malicious website can use the user’s credentials to send forged requests to services in the other domain. This is why SOPs were introduced to prevent such attacks, and CORS was created to securely control communication between sources.
You can read more about CORS here: ##### Which begs the question: do policies like CORS exist for server-to-server communication?

The short answer is: No. That’s because server-to-server communication happens directly, with no intermediary like a webserver. Servers operate in a trusted environment. This is because they verify each other’s identities and encrypt the data they communicate to ensure the confidentiality and integrity of the data.

I’m curious to know the details of the provenance comparison process.

We’ll cover it in part 3. Link