Same-Origin Policy vs CORS

The same-origin policy restricts what a page can read, not what it can send.

Internalise that and CSRF stops being confusing. A page on attacker.example is not allowed to read a response from bank.example — but it was never prevented from causing the request. The web has always allowed cross-origin sends: that is what makes <img>, <script>, <link>, and cross-site form posts work at all. Removing that ability would break the web, so it was never removed.

CORS did not change this. CORS is a mechanism for a server to opt in to letting a cross-origin page read a response it would otherwise be denied. It relaxes the read restriction. It adds no send restriction — with one partial exception, the preflight, which is a side effect rather than a design goal.

So the CSRF attacker's position is: I can make the request, I just cannot see the answer. For a state change, seeing the answer is optional.

CORS splits cross-origin requests in two. A simple request (the spec calls it a CORS-safelisted request) is sent straight to the server. Anything else gets an OPTIONS preflight first, and the real request is only sent if the preflight response approves it.

A request is simple when all of these hold:

• The method is GET, HEAD, or POST.
• The only headers set by the page are on the safelist: Accept, Accept-Language, Content-Language, Content-Type, and Range.
• If Content-Type is set, its value is one of exactly three: application/x-www-form-urlencoded, multipart/form-data, or text/plain.

That three-value list is the single most load-bearing fact in practical CSRF. It is why:

• An HTML form is a CSRF weapon — a form can only ever emit those three encodings, so a form request is always simple and never preflights.
• application/json is not directly attackable — it is not on the list, so it preflights, and the real request never leaves the browser unless CORS explicitly allows it.
• The text/plain trick exists at all — it is the only way to get a JSON document in front of a server without a preflight. See JSON, text/plain, and GraphQL.

A preflight is not a CSRF defence that anyone designed. It is an accident of CORS that happens to block some shapes.

A no-cors fetch resolves with an opaque Response: status is 0, ok is false, headers are empty, and the body is unreadable — regardless of what actually happened on the server. The same is true of an <img> that loads a non-image or an <iframe> pointed at a cross-origin page.

The practical consequences when testing:

• You cannot confirm the attack from the attacker page. Verify the effect on the target: reload the account page, check the audit log, watch the mailbox. A PoC that logs response.ok is measuring nothing.
• You cannot use CSRF to read data. Any "CSRF to exfiltrate" claim needs a second mechanism supplying the read — a CORS misconfiguration (CORS-Assisted CSRF), a JSONP endpoint, or XSS.
• Side channels are limited but real. Load timing, whether an onload versus onerror fires, and frame-count probing can leak a bit or two. Treat these as separate findings, not as CSRF.

For the tester this is a feature, not a limitation: a state change you can trigger blind is still a state change.

This confusion is common enough to be worth stating directly. Teams sometimes believe that because they have not configured CORS, they are safe from CSRF. They are not.

• A form does not consult CORS at all. An auto-submitting cross-site form has been legal since 1995 and is unaffected by any Access-Control-* header. The most effective CSRF delivery in 2026 bypasses CORS by never engaging it.
• Absent CORS blocks reads, which the attacker did not need.
• A misconfigured CORS policy makes things strictly worse, by adding a read primitive to the write primitive.

The converse is also worth knowing: a strict CORS policy does incidentally block the fetch-with-JSON shape, which is why pure JSON APIs that reject non-JSON content types are hard to attack. That is a real mitigation — it just comes from content-type enforcement, not from CORS. Enforce it deliberately: reject any request whose Content-Type is not application/json, and the text/plain smuggle closes too.