Web security · try it live

Why do CORS and CSRF exist if the backend already checks auth?

There are two different sites here. Keep them straight and the whole thing clicks.

🏦 The bank (the server)

api.barisalgun.dev
The real backend. It checks your cookie, sets CORS headers, and guards transfers. You log in on its own site. Fake money, no real account.

😈 This page (some other site)

barisalgun.dev
Just a page you happened to open while logged into your bank. It is not the bank. Watch what it can and cannot do to your open session.

🔍

Open your browser DevTools → Network tab (F12) before you click. The whole point is to watch the requests leave, see which ones the browser lets this page read, and read the real response headers.

This page

barisalgun.dev

Your bank session

—

Balance

—

SETUP Step 0 — log into the bank on its own site

A CSRF attack only works against a session you already have. So first log into the demo bank on its own site (this is where the password would go, not here). Your browser stores a bank_session cookie for api.barisalgun.dev. Then come back to this tab.

🏦 Open the bank & log in ↗

Open the bank, click "Log in" there, then come back and check.

Can this page READ your data? CORS

Your cookie rides along automatically. But reading the reply needs the bank's permission via an Access-Control-Allow-Origin header. Watch the browser allow one and block the other.

—

Can this page CHANGE your data? CSRF

Reading is blocked, but a write does not need to read anything. The cookie still rides along. One endpoint has no CSRF token check, the other demands a token this page cannot obtain.

—

Request log

Everything is real: this page is on barisalgun.dev, the bank is on api.barisalgun.dev, same site but a different origin, exactly like a frontend and its API. The bank is a tiny PHP backend whose endpoints do or don't send CORS headers and do or don't check a CSRF token.