CORS (Cross-Origin Resource Sharing) and CSRF (Cross-Site Request Forgery)

1. CORS - Cross-Origin Resource Sharing

CORS is a browser security mechanism that controls how web pages can request resources from a different origin (domain, protocol, or port) than the one that served the page. It builds on the Same-Origin Policy (SOP), which by default blocks cross-origin requests for security reasons.

Why It Exists

Without CORS, a malicious site could freely make requests to another site where you’re logged in and read sensitive data. CORS allows servers to explicitly declare which origins are allowed to access their resources.

How It Works

1. Browser sends a request to a different origin.
2. Server responds with special HTTP headers such as:
   • Access-Control-Allow-Origin: https://example.com
   • Access-Control-Allow-Methods: GET, POST
   • Access-Control-Allow-Headers: Content-Type
3. If the headers match the browser’s expectations, the browser allows the response to be read by the calling script.

Types of CORS Requests

• Simple Requests: GET, POST (with safe content types like application/x-www-form-urlencoded), HEAD.
• Preflight Requests: For non-simple requests, browser sends an OPTIONS request first to check if the actual request is allowed.

Example

If your React app runs on http://localhost:3000 and your API is on http://localhost:5000, without CORS enabled on the API, the browser will block the request.

CORS Flow Diagram

[Browser] -- Request --> [Server]
[Server] -- Access-Control-Allow-* headers --> [Browser]
[Browser] -- Allows or blocks response based on headers
  

Prevention of CORS Issues

• Confiture server to allow only trusted origins.
• Avoid Access-Control-Allow-Origin: * for sensitive endpoints.
• Use HTTPS to prevent man-in-the-middle attacks.

---

2. CSRF - Cross-Site Request Forgery

CSRF is an attack where a malicious site tricks a logged-in user’s browser into sending unwanted requests to a trusted site where the user is authenticated.

Why It’s Dangerous

Browsers automatically include cookies (session IDs) with requests to the target site, so the malicious request is executed with the victim’s privileges — potentially changing passwords, transferring funds, or deleting data.

How It Works

1. User logs into bank.com and gets a session cookie.
2. Without logging out, the user visits evil.com.
3. evil.com contains hidden code that sends a request to bank.com.
4. Browser sends the request with the user’s session cookie.
5. Bank processes it as if the user intended it.

CSRF Attack Flow Diagram

[User] -- Login --> [Trusted Site] -- Set Cookie --> [Browser]
[User] -- Visit --> [Malicious Site]
[Malicious Site] -- Hidden Request --> [Trusted Site]
[Trusted Site] -- Executes action using user's session
  

Example Attack

• Hidden from auto-submitting to a target site.
• Image tags or JavaScript making GET/POST requests.

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

Prevention Strategies

• CSRF Tokens: Unique, unpredictable token included in forms and verified server-side.
• SameSite Cookies: Set cookies with SameSite=Strict or Lax to prevent cross-site sending.
• Double Submit Cookie Pattern: Send token in both cookie and request body/header, verify match.
• Check Origin or Referer headers for trusted domains.

---

3. Key Differences Between CORS and CSRF

Aspect	CORS	CSRF
Type	Browser security feature	Security vulnerability/attack
Purpose	Controls cross-origin resource access	Exploits authenticated user’s session
Who Configures	Server sets allowed origins	Developer implements protections
Focus	Protects data from being read by unauthorized origins	Prevents unauthorized actions on behalf of a user

Quick Memory Hook

• CORS: "Who is allowed to talk to me?" (server’s decision)
• CSRF: "Who is making me do this?" (attacker’s trick)