# Cross-Origin Resource Sharing (CORS) - Links: [[Security]] ## See also: - ### [[CSRF]] ## Notes - Remember, CORS is enforced on the **client** side, by the browser - => We need to uphold users' browsers' capabilities to protect them from CSRF attacks - The main issue is malicious sites using users' browser cookes to access our service when in fact the user is not using our service ## 3 Ways to Fix the CORS Error — and How the Access-Control-Allow-Origin Header Works https://medium.com/@dtkatz/3-ways-to-fix-the-cors-error-and-how-access-control-allow-origin-works-d97d55946d9 ### Notes I don't recommend any of the fixes - should do the security correctly. But the explanation if CORS / CSRF is quite good. - Don't use proxy - Don't use a browser extension - it might make you vulnerable to csrf attacks - If you use the extension, do so only on private windows, to isolate from your authenticated shit - Extension here: The fix is to (in the backend) specify the domains which are allowed to make requests to the server, e.g. ```text Access-Control-Allow-Origin: http://localhost:3000 ``` ### How the [[CSRF]] attack works The error stems from a security mechanism that browsers implement called the **same-origin policy.** The same-origin policy fights one of the most common cyber attacks out there: **cross-site request forgery.** In this maneuver, a malicious website attempts to take advantage of the browser’s cookie storage system. For every HTTP request to a domain, the browser attaches any HTTP cookies associated with that domain. This is especially useful for authentication, and setting sessions. For instance, it’s feasible that you would sign into a web app like facebook-clone.com. In this case, your browser would store a relevant session cookie for the facebook-clone.com domain: ![[Pasted image 20210828020009.png]] And this is great! The session cookie gets stored. And every time you re-visit the facebook-clone.com tab, and click around the app, you don’t have to sign in again. Instead, the API will recognize the stored session cookie upon further HTTP requests. The only trouble is that the browser automatically includes any relevant cookies stored for a domain when another request is made to that exact domain. Therefore, a scenario like this can happen. Say you clicked on a particularly trick popup add, opening evil-site.com. ![[Pasted image 20210828020056.png]] The evil site also has the ability send a request to facebook-clone.com/api. Since the request is going to the facebook-clone.com domain, the browser includes the relevant cookies. Evil-site sends the session cookie, and gains authenticated access to facebook-clone. Your account has been successfully hacked with a cross-site request forgery attack. - Then the attacker could post on your behalf, change your password, etc Luckily, in this situation, like a hawk ready to strike, the browser will step in and prevent the malicious code from making an API request like this. It will stop evil-site and say “Blocked by the same-origin policy.” ### How does the same-origin policy work under the hood? Under the hood, the browser checks if the origins of the web application and the server match. ==Above, the origins were simplified to the frontend application and backend server domains. But really, the origin is the combination of the protocol, host, and port.== For example, in https://www,facebook-clone.com, the protocol is https://, the host is www.facebook-clone.com, and the hidden port number is 443 (the port number typically used for https). To conduct the same-origin check, the browser accompanies all requests with a special request that sends the domain information receiving server. For example, for an app running on localhost:3000, the special request format looks like this: ```text Origin: http://localhost:3000 ``` #### The server can have two policies: 1. The server can be really strict, and specify that only one origin can access it: ```text Access-Control-Allow-Origin: http://localhost:3000 ``` 2. The server can let the gates go wide open, and specify the wildcard value to allow all domains to access its resources: ```text Access-Control-Allow-Origin: * ``` Once the browser receives this header information back, it compares the frontend domain with the Access-Control-Allow-Origin value from the server. If the frontend domain does not match the value, the browser raises the red flag and blocks the API request with the CORS policy error.