<h2 id="what-this-post-covers">What this post covers</h2>
<p>In this short post we look at the Origin header, and we use it to explain two browser locks that juniors often mix up: CORS and CSRF. Our example is the same blog API from the earlier posts, but the goal is bigger than one blog. Everything here helps you build safer APIs in general.</p>
<p>This post is for juniors who already know the five request verbs, the Content-Type, Accept, and Authorization headers, and the Cookie the browser attaches for you. We start with what Origin is. Then we meet CORS, the lock on reading, and CSRF, the lock on changing data. Finally, we look at the two holes that let a delete happen without anyone noticing, and why sending Delete as the verb and setting SameSite Lax close them.</p>
<p class="bd-statement">By the end you can say: Origin names the site that sent the request. CORS decides whether that site’s JavaScript may read the answer. CSRF is about whether another site can ride your Cookie to change data.</p>

<h2 id="origin-is-which-site-sent-this">Origin is which site sent this</h2>
<p>Picture an admin page at <code>https://tipsbymoh.tech/admin</code>. When the page loads, it calls <code>GET /api/blogs</code> to list the posts. You never typed an Origin header in your fetch call, yet the request carries one.</p>
<pre><code>GET /api/blogs
Origin: https://tipsbymoh.tech</code></pre>
<p>That is because the browser adds Origin, not your code. The Fetch standard marks Origin as a forbidden request header, which means page JavaScript is not allowed to set or change it (MDN, 2026). The value holds only three parts: the scheme, the host, and the port. There is no path. Because the port is part of it, <code>localhost:3000</code> and <code>localhost:8000</code> count as two different origins, which will matter in a moment.</p>
<figure>
  <img src="https://techtipsbymoh.tor1.cdn.digitaloceanspaces.com/techtipsbymoh-production/blogs/the-origin-header/4d0915989313437fa39241638a19baab_01-origin-stamp.png" alt="A teal wax stamp presses a mark onto a sealed envelope aimed at a small server rack.">
  <figcaption>The browser stamps Origin on the request: scheme, host, and port, with no path.</figcaption>
</figure>
<p>It helps to put Origin next to the headers you already know. Host says which server you are talking to. Cookie carries what the browser stored for that server. Authorization says who is asking, and you add it on purpose. Origin answers a different question: which site sent this request. (You may also see Referer, which can hold the full URL, but browsers often trim it, so we leave it aside.)</p>
<p class="bd-statement">Origin is written by the browser, so the server can trust it to say which site the request came from.</p>

<h2 id="cors-is-a-read-lock">CORS is a read lock</h2>
<p>The first lock shows up the moment two origins talk. Say your admin runs on <code>localhost:3000</code> and your API runs on <code>localhost:8000</code>. The admin fetches <code>localhost:8000/api/blogs</code>, and the browser sends the request with this Origin:</p>
<pre><code>GET /api/blogs
Origin: http://localhost:3000</code></pre>
<p>The server receives it, builds the list, and returns 200 with the JSON. You can even see the blogs in the Network tab. But the console shows “blocked by CORS policy,” and your JavaScript never gets the data. The reason is that the server did not say <code>localhost:3000</code> is allowed to read its answers, so the browser hides the response from your code.</p>
<p>This is what classic CORS means: the server answered, but the page’s JavaScript may not read it. Some servers also reject a bad Origin with 403, but that is an extra choice, not the default. It also explains why Postman and the api.http file still show the body. CORS is a rule the browser enforces for page JavaScript, and those tools are not a web page.</p>
<p>For some requests, the browser checks before sending anything. If the request carries Authorization, uses Delete, or sends JSON as its Content-Type, the browser first sends a small request with the Options method. Options is an HTTP method, just like Get and Delete. This first call is called a preflight: the browser is asking whether this Origin may send the real request. If the answer is no, the real Delete never leaves the browser.</p>
<p>The same rules apply to axios, a small JavaScript helper that sends requests the way fetch does. On your own admin, <code>axios.delete</code> is the correct way to delete a post. If an evil page tries the same axios call against your API, the preflight blocks it, and SameSite Lax keeps your Cookie off it anyway. So a cross-site axios call is not how the usual CSRF attack works. That attack uses something simpler, which we look at next.</p>
<p class="bd-statement">CORS hides the answer from another site’s JavaScript. It does not stop the server from receiving the request.</p>

<h2 id="csrf-is-a-change-lock">CSRF is a change lock</h2>
<p>CORS protects reading. CSRF is about something different: another site using your Cookie to change data. To see the difference, look at two more errors.</p>
<p>In the first one, the protection is working. You are logged into the blog admin, and your session Cookie is stored in the browser. You click delete, and the request goes out with that Cookie, but your code forgot to include the CSRF token, a secret the server put on your own page. The server answers 403. You see the error, and the blog is still there.</p>
<p>The second one is quiet, and that makes it worse. This time the session cookie was set with <code>SameSite=None; Secure</code>, which lets the browser attach it even when another site starts the request. While still logged in, you open a funny page. That page contains a hidden form that posts to your API:</p>
<pre><code>&lt;form action="/api/blogs/42/delete" method="POST"&gt;</code></pre>
<p>The form submits, the browser attaches your Cookie, and the server deletes post 42. There is no CORS error, because the funny page never tried to read the answer. It only needed the delete to happen. Notice that the form uses Post, not Delete. HTML forms can only send Get or Post, so the attacker needed a server that deletes on a Post.</p>
<p class="bd-callout bd-callout-warn">You find out later that the post is gone. Your console was clean the whole time.</p>

<h2 id="two-holes-then-two-locks">Two holes, then two locks</h2>
<p>That quiet delete only worked because two holes lined up at the same time. Closing either one would have stopped it.</p>
<div class="bd-grid">
  <div class="bd-card-muted">
    <p><strong>Hole 1: the verb hid in the path</strong></p>
    <p>The server treated a Post to <code>/api/blogs/42/delete</code> as a real delete. If the API only accepted <code>DELETE /api/blogs/42</code>, the form would get 405 or 404, and nothing would be deleted.</p>
  </div>
  <div class="bd-card">
    <p><strong>Hole 2: the cookie rode cross site</strong></p>
    <p><code>SameSite=None</code> let the Cookie travel with a request from another site. With Lax or Strict, the browser would have left the Cookie off that foreign Post. Modern browsers often treat a missing SameSite as Lax (MDN, 2026).</p>
  </div>
</div>
<p>The first hole is why the verb belongs in the method, not in the path. It is also why the junior route from the first post, a Get to <code>/api/blog/:id/delete</code>, is dangerous. SameSite Lax still sends the Cookie on a top-level Get, such as a link the user clicks. An image tag pointing at that URL will not get the Cookie, but a clicked link will, and the post is gone.</p>
<p>Now we can put the two locks side by side:</p>
<div class="table-responsive scroll-type-one">
  <table class="blog-table">
    <thead>
      <tr><th>Lock</th><th>Stops</th><th>Does not stop</th></tr>
    </thead>
    <tbody>
      <tr>
        <td>CORS</td>
        <td>Another site’s JavaScript reading your answer</td>
        <td>A Cookie-backed delete that the server already ran</td>
      </tr>
      <tr>
        <td>CSRF defenses</td>
        <td>Another site using your Cookie to change data</td>
        <td>Nothing about reading; that is CORS’s job</td>
      </tr>
    </tbody>
  </table>
</div>
<figure>
  <img src="https://techtipsbymoh.tor1.cdn.digitaloceanspaces.com/techtipsbymoh-production/blogs/the-origin-header/f40d9af0ea5a442c92dcd3462d7467e6_02-two-locks.png" alt="A visor covers a response sheet on the left. On the right a cookie rides from a foreign stall toward a delete stamp.">
  <figcaption>CORS stops another site’s JavaScript from reading the answer. CSRF defenses stop another site from using your Cookie to change data.</figcaption>
</figure>
<p>So the CSRF defenses are the ones that matter for the quiet delete. On requests that change data with a Cookie, check the Origin header. Keep Get for reading only. Set SameSite Lax on the session cookie. Keep in mind that SameSite Lax is a flag on the Cookie, not a token. The CSRF token from the first error is a separate secret, and it is not the JWT you send in Authorization either.</p>
<p>That last point also explains when CSRF matters at all. A Bearer token in Authorization is something your code adds on purpose, so a funny page cannot make the browser send it for you. CSRF becomes a risk when login lives in a Cookie, because the browser attaches cookies on its own.</p>
<p class="bd-statement">This is why we write requests the standard way: five verbs, the token in the header, the Cookie attached by the browser, Origin checked, Delete sent as Delete, and SameSite Lax. Together they shrink these holes on any API.</p>

<h2 id="what-you-can-say">What you can say</h2>
<p>You can watch the same path in the companion tip, <a href="/tips/the-origin-header" rel="noopener noreferrer">The Origin header</a>. If you want to revisit the pieces it builds on, read <a href="/blog/five-request-verbs" rel="noopener noreferrer">Five request verbs</a>, <a href="/blog/request-headers" rel="noopener noreferrer">Request headers</a>, <a href="/blog/token-in-the-header" rel="noopener noreferrer">Token in the header</a>, and <a href="/blog/the-cookie-header" rel="noopener noreferrer">The Cookie header</a>.</p>
<p class="bd-statement">Origin names the site that sent the request. CORS is the lock on whether that site’s JavaScript may read the answer. CSRF is the lock on whether another site can ride your Cookie and change data. Delete as the verb, and SameSite Lax, close those holes. That is how a standard request keeps an API safer.</p>

For juniors who know Cookie and Authorization: Origin names the site that sent the request. CORS hides the JSON. CSRF rides your Cookie to change data.

The Origin header: CORS vs CSRF

The Origin header

For juniors who know the common request headers: the browser adds Cookie on the page. You do not set it in fetch. Postman can still paste it.

The Cookie header, not Authorization

The Cookie header

For juniors who know request headers: keep the bearer token in Authorization, not in the blog JSON, and see why a delete with no body still needs it.

Why the bearer token stays in the header

Token in the header

For juniors who know the five verbs: name Content-Type, Accept, and Authorization, use each on a blog API, then keep the token out of the URL.

The Origin header

More from the blog.

The Cookie header

Token in the header

Request headers