It's more of a NextJS app router issue that you do no have a way to set common headers on the same URL for different http method. Most web-frameworks have CORS in mind and can let you easily setup CORS in some kind of middleware.
Most definitely, it just shows how immature these JS frameworks for backend are. I mean its not end of the world as CORS is not THAT complicated. Also the preflight (OPTIONS http verb call) is meant for browsers to check the response headers so that the actual request can/cannot be sent, if can be sent then after the actual request browser checks that request response headers for the actual response.
Oh yes these Js framework's are really immature, I did try to implement API using nextjs lots of issues like this. Java , phyton or c# is better for API development. I switched to remix for frontend from nextjs.... Much more flexible and uses unwrapped native node JS request and response.....
@@MrRaitiz indeed, he key point about OPTIONS is that it guards against any side effects of the request, effectively to guard against a CSRF attack. Servers could guard against this by checking the CORS headers before carrying out the request, but it looks like the CORS spec takes a precautionary approach and assumes the server does not do this, The weird thing is the websocket spec takes the opposite approach and relies on the web sockets server to validate the Origin header within the app logic. I wonder how many webscketa servers do not check the Origin.
I agree, this is a framework problem. On top of that, with server actions nextjs implemented an origin header check on the server. This is obnoxious part, instead of providing a good DX on top of a browser enforced CORS, they implement something else, that is much less flexible, adding another set of error messages to the pile. Have fun implementing a multi tenant app where users suppose to point their custom domain to your app. You’ll need to know all allowed hosts at build time AND still have to deal with CORS to prevent cross scripting issues between your tenants …
@@fnfal113 let's be real not everybody add's packages to handle cor's that's just reality of it, since dependency hell on nodejs all ready is a thing... Note: Also don't forget not everybody use latest and greatest stuff around, like we have spa vue.js v1.x with node.js that is a bit outdated, so each time is a gamble.
Thank you, exactly what I wanted to say. Nodejs logic: "we can't write proper code to handle a web standard or copy solution from other technologies" = "web standard is stupid". Guys, just look how it is done in other frameworks, why do JS devs need to invent everything again from scratch?
Problem is that web devs should learn fundamentals, and why we have CORS, and how to address these issues in non security threatening way. Most of devs solve it by allowing all origins, which intoduces many security risks.
@@31redorange08 what is worse is that many devs working in big companies do not know either. Since web dev became an industry, real knowledge has declined.
I think devs who hate CORS are devs who still didn't fully understand what CORS are for and how they work. I mean, what is there to hate, once you get them ? Security ? Isn't it a GOOD thing ?
wow did you say it? I agree! Also, you should never set Access-Control-Allow-Origin = *, unless your API is meant to accept requests from unknown sources.
@@Rust_Rust_Rust Ok, I can agree. But CORS couldn't be more simpler. I'd even argue its failure is to be too simple : for example being able to only declare one domain as an allowed origin. They could have allowed you to just send back a coma separated list. But I don't see how CORS is "difficult to work with". It's a bunch of headers that tells a browser what methods it can use and from what domain, for a certain URL. Nothing more.
@@TheNewtonI'd like to see him hook up a front end to an API he hasn't worked with before on a live stream. If you think CORS couldn't be "more simpler", either you're amazing, or don't code very much.
I disagree wholeheartedly with this. CORS is not flawed, next.js is flawed. The only time I've ever been caught out by CORS is when I forgot to configure CORS middleware. One commit later and there are no more issues. Use proper tooling for APIs and you won't run into half these issues.
Agree. CORS is basically a way for you to opt into which domains are allowed to interact with your server. How is that a bad thing? Complaining about CORS existing is like complaining about passwords existing. Would you be angry that passwords exist to allow you to opt in to who is able to access your accounts (if you even choose to allow this)? I doubt it. And from the other perspective, for those front end apps running in the browser on various domains out there, it was a backwards compatible way to make sure sensitive data wasn't being transmitted to 3rd party domains. Security by default is a good thing. The fact they added cross-domain AJAX support in a backwards compatible way like this is impressive. I do realize it can feel complex to people who've never worked with it before. And that complexity can be magnified when you're working with a 3rd party thing (like this video creator is) who is also doing something complex, like running things meant to be run on servers in the browser. Now you're at the mercy of how that 3rd party works. But you've always got the freedom to choose to simply not use that service. Anyone new to CORS who is frustrated with it should use the same solution they've probably found successful so far when dealing with new things. If it's too complex, provide feedback to its creators so they can simplify it (CORS probably cannot be simplified any further) and then try as hard as you can to learn it. MDN has great resources for learning how CORS works. One more tip I'll leave for people... embrace proxying if you need it. It's not the evil, dirty workaround it might seem to be. Browsers have no way to know that two domains are owned by the same party, so they have no way to trust a different domain when a request is being made to it. If you proxy the requests you want your app to make, hosting the proxy on your domain, the browser doesn't have to worry about this. You're vouching for that service to the browser. It simply makes another call to your domain, like it's doing for every other call to your backend. This doesn't even have to be a separate application. It can just be another route in your back end application if you want.
CORS is handled by the browser, the client needs the OPTIONS request to know whether or not the POST request is allowed, you're inflicting this pain upon yourself by hardcoding cors rules in javascript on different method calls, cors is supposed to be handled by the web server itself
Except for that not every request does need an option preflight request. As long as your request qualifies as a „simple request“ (specific content types and no non standard headers, etc) your browser will not issue a preflight request, but the response still needs the proper cord headers present
@@Mooooov0815 the "simple" requests are there for backwards compatibility reasons. GET calls with no additional headers (same as embedding an IMG tag in your document) or POST requests that do a simple application/x-www-form-urlencoded plain old form stuff.
@@Mooooov0815 If the request does not cause a modification on the server (i.e. GET), then it does not need a preflight, because you can simply filter when the response comes. But for a request that causes a modification on the server (i.e. POST), filtering on the response would be too late, so you need to check first.
I just want to point out, when watching your video in slow motion, at 5:52 when you close the image it is possible to read your X-Uploadthing-Api-Key. Thought you might want to fix that and reupload (or change the key).
@@ninjaasmoke People who are into security look very closely whenever somebody streams code. That black box redacting something which than moves behind that block is just asking to be checked out frame by frame 😂
This video would've been better by mentioning *why* the OPTIONS request exists and why websockets don't use CORS. If the OPTIONS pre-flight request wasn't there then the browser would still have to execute the request against the actual endpoint, and the endpoint would still do 'the thing it is supposed to do' (e.g. delete all your files). The OPTIONS call is an 'innocent' call that has 'no' risk of having any side effects. Whether the required confirmation on the actual resource is or isn't beneficial enough in the grand scheme of things I agree can be debated, but frankly in no project I ever did different resources have different CORS responses, so I always just threw it in as some type of quick middleware on all routes which took me all of 5 minutes. Obviously the more complex your architecture is, the less true the 5 minute statement becomes (e.g. in one architecture setup I 'helped out with' (just giving advice) they had to dynamically sent the list of allowed servers to the API server which then had to add them to the CORS list, but that was a pretty crazy setup). As to why websockets don't require CORS: The argument goes that if the web was invented today we wouldn't have CORS nor the same origin policy and instead checking the Origin header would simply be left to the server. As websockets were invented 'late enough' in the web's development the argument goes that there is no risk of legacy servers to be concerned with, so leaving the check to webservers directly is simply more efficient.
@@RaZziaN1 not quite - most properly written websites would have CSRF protection jest originated from the same request, but as the Origin header is recent and not sent on all requests it would probably not be checked at all
Yes, you're absolutely correct. Unless the application needs to dynamically set the allowed source based, for example, on the user authenticated, you should deal with CORDS on Nginx, Apache, etc.
Let's talk solutions. When you're stuck on a CORS issue and need a quick fix, there are tools out there to help. Beeceptor, for example, is a lifesaver. It's this cool HTTP proxy that handles CORS smoothly, adding required headers to the original API response. Frontend/Javascript devs looking to get past those annoying CORS blockers, a time saver!"
I can't understand where the issue is here? CORS is well dcoumented and super important. The preflight request happens because of the way http works, which means the browser doesn't want to send the actual request before asking the server, hey is this okay. And then it makes total sense it RE-verifies it on the actual request. This makes sure a clien't cant request a server if the server is limited to a specific origin. Regarding the sockets thing, http works over tcp sockets? So cors is only concerned with the content of the http request and doesnt care about anything below it. Further the argument: i had to write the headers twice, have people forgot something called middleware exists? I can understand it can be frustrating, but it seams this is more because the concept of cors wasn't understood rather then cors actually being wrong.
I think when he said sockets he meant websockets, which does not need CORS to go cross domain - instead the server is supposed to validate the Origin header. The reason CORS has a preflight request is because some web endpoints may predate CORS and not know to check the Origin header, and would be vulnerable.
Before CORS it was common to see the session or CSRF token in the URL for pages with potentially sensitive content that was server-rendered. It was a much bigger pain both as a developer and a user (couldn't just copy URL to send to a friend or colleague since it was unique to your session and sometimes to that specific page-access). Perhaps there's a 3rd option that would be better, but comparing to the way websockets did it for example: I think it's simpler for web servers to set one (sometimes you need the others, but in my experience it's rare) headers on the endpoints, where cross-origin is OK, than to check the origin header on every endpoint that may have sensitive data. The header can be set by the edge server, whereas the origin checks usually have to live in the application code.
I work on a legacy system, and someone was trying to add a more modern API (the new code is somehow worse than the old, but that is a tale for another day) on a separate domain, and strugled for days with CORS, I was like "come on, we are behind a reverse proxy, just put the API on the same domain with a url prefix" and everybody was happy ever after... except when someone needs to touch the new code
This is pain. But you know what's even more painful? The fact that you don't have canary deployments for stuff that you know might fail due to a developer's mistake
Honestly stuff like this is where having an API gateway and a proper deployment process where you can set rules like CORS and authentication as part of your infrastructure code instead of putting it in your javascript like you were doing in this video.
I love watching real world debugging. I think getting a peek into the mindset of somewhen when fighting issues is so important. So much of this work is about solving the right problem and checking the right things and not digging yourself deeper. Its also an extremely personal process. Thanks as always for sharing.
I always hated CORS, it seems like reinventing cookies would be a smarter move… Anyway, thanks for the video! Letting you know that the screen is flickering on darker tones like in 4:50. I thought there was a problem with my tv hahah
@@RaZziaN1its very subtle, I can see it in my tv and phone very well, but it is harder to spot on my monitor (I can still see it though, but it is definitely not as annoying as on my tv, probably due to local dimming)
I still will not forget the time i was learning laravel in my internship. For some reason, failed user validation in the backend would result in a CORS error. I had to figure out everything on my own. A fucking hellhole that was.
They don't want some website making requests to another website because cookies are sent by default, so by default, those requests could be authenticated. The solution was to list all websites that are allowed to make such requests. In my opinion, an easier solution would be to just not send the cookies in those cases instead of blocking the request. Sometimes you just want to make an unauthenticated request to a different domain and with the protocol we have now, you need to proxy the request to work around CORS. If you are just writing some html to run from the file system. You also don't get to do requests so you always have to spin a small web server. But it is too late to change how this works now. Maybe in the future with new protocols we won't have this problem anymore. I'd rather start from scratch than patch this in a way that won't break older pages.
The issue with this approach is that if the victim is on an internal network it would allow access to internal services through a malicious websites. The localhost restriction is probably there for a good security reason as well
I've literally never had an issue with CORS. I actually love that cors exists so I can deny malicious attackers. :D CSRF was so much pain to integrate and handle than cors, which I still have to do sometimes and make things work.
I hate to take this stance, and sound like Prime, but this seems like a skills issue. Setting up an endpoint to respond with the same CORS headers for OPTIONS or POST/GET without copy-pasting the code isn't hard. I understand that backend code running in the browser needs work to adhere to CORS, and I totally get how "wait my requests are running in the browser now" wouldn't necessarily occur to a dev immediately. But I feel like if you sit down and understand CORS these things become apparent and reasonable pretty quickly. The OPTIONS preflight is an effort to avoid server-side actions that the client can't read the result of. But the CORS checks still need to pass on the actual request for the browser JS to get access to the response (but you'll see the request did actually happen if you look at the server).
CORS is complicated & confusing, BUT PRETTY MUCH ESSENTIAL to prevent malicious websites doing bad things! I'm convinced that it needs to be what it is and work pretty much how it does. Use a good library (such as django-cors-headers) and just enable what needs to be allowed. I think what is confusing about CORS is it the browser restricting what the client can do, whereas normally it's the server restricting what the client can do.
I work at a billion+ dollar company and we had some CORS related problems last week. It wasnt that CORS was blocking anything its just that our logs in datadog went from a few hundred thousand to over 2million overnight when we launched a new product because the new product had a new service that talked with our core service and every request was hitting a CORS check. So I figured out we should just set Max-Age on the requests so CORS can effectively f-off for at least for some time. And then I learned that the max-age DIFFERS FROM BROWSER TO BROWSER. I hate CORS.
yea that "prefab" OPTION calls took us few hours too :D, and fixed only because we tried normal ajax and not fetch where you see "prefab" request in network ...
The funny part of this is you can just put the API calls behind a server and bypass CORS all together. In other words, the only nefarious actors thwarted by CORS are the lazy ones who want to just use a cross origin resource by copy/pasting a URL into their source.
It was definitely written by those esoteric programmers who are like 'read the manual' instead of making it good. I wonder how many millions of dollars they have cost in lost time. Almost as bad as certificates, just recently the windows 22H2 update made some sites use TLS1.3 ... which broke. good times.
I made a cross origin POST request to my own custom HTTP server. I got the request and parsed it correctly, but the browser refused to hand over the response because of CORS. What does that help? I have already processed the request on the server and sent a response knowing the source of the request. I know I can add some headers to allow access to the browser, but why? The server has decided to not reject the request, shouldn't that be enough?
It's frustrating when I am a junior developer who is trying to learn fullstack and suddenly you get CORS-policy violation. You have no clue what it means, what causes it and how to fix it. All you know is suddenly your app isn't working anymore. Good luck!
actually the biggest problem with cors in my opinion is that i've read countless explanations and still not sure why the fuck do we need this in the first place
In my 20 years of coding, for the backend, I have used Sping (JAVA), Laravel (PHP), Symfony (PHP), .NET, Django (Python), Flask (Python), Gin (Go). CORS has never been an issue and I have dealt with it more times than I can count. CORS was well designed and thought out and all the frameworks I have mentioned deal with it nicely. This video is nothing but a NEXTJS problem!! And the bigger picture is that javascript should have stayed in the browser!
The reason why cors is not enforced on websockets is because websockets requests results in a 101 and have no body. CORS is not an attempt to protect the origin site but the foreign resource itself, like images and what not. This enable backends to protect against malicious websites running on genuine user browser. Its pain because the server software you use is bad, but hating on cors is like hating on tls.
Why do you include Access-Control-Request-Method in the server code? That's just a header sent by the client during the OPTIONS pre-flight. I would remove that in cases it causes problems with some clients. Some clients are really picky about stuff (like Access-Control-Allow-Methods did not allow wildcards in the past). There's a lot of subtleties as you get into edge cases with credentials and allowed request headers. Even re-reading through my implementation for work just now, I realized my own implementation is not quite correct because for my OPTIONS response, I send back the origin requested in "Access-Control-Allow-Origin", but because I do that, I should add a "Vary" header specifying that so that any intervening proxies do not cache the "Access-Control-Allow-Origin" response just for that particular asked for origin.
CORS is a pretty good standard, I don't think it's a problem because of CORS, it's more about how the browser implements it and also does it allow you to pass your own preflight info or an API call. One of reasons why I don't like front-end development because it's mostly your browser and also some browsers gives stuff like blocking these kind of cases. If you deal with them you will hate CORS more than anything. Sometimes same happens with cookies too.
Not sure if you noticed but your (duplicated) cors headers code is out of sync ;) in options your settings are different than in post ;) Just like you said in the video (different methods listed ;) )
BFF is your best f****** friend. Pre-flights add significant extra latency, particularly if paying the Cloud Flare latency tax, and it's particularly bad for some users; like international. Serve your FE from the same origin as your API.
As an API developer never had to actually deal with CORS, mostly because framework handled it for me. All I had to do is to setup one middleware, and that's all.
It’s more about lot of the framework don’t have custom cors setting by deployment profile by default or it’s not flexible enough it’s so rigid nothing can be customized. It’s make developer need to setup cors header and OPTION manually in hacky way like demonstrated on this video. The easiest way to solve it in production is by using proxy server or api gateway to make all the cors setup centralized on one place.
My favourite „solution“ for Development landed in Chrome a couple of months ago. Overwriting response headers like setting Access-Control-Allow-Origin to * ruclips.net/video/e8tl_yp5BQg/видео.html
I as a user should be able to disable cors as easily as i can disable "Enhanced tracking protection" Not being a "webdev" my foray into dealing with js and cors has been complete hell (mainly getting data from apis i do not own like weather data that don't provide a way to deal with cors) The only good thing cors has done is to push me to just do all of that garbage on a local server and simply serve the data that way instead of having the "application" run within the browser
Is Theo saying that Chrome Extensions have the ability to bypass CORS? How? I feel like I've run into CORS errors plenty of times and had to resort to proxying even with extensions? Maybe its because I didn't do the pre flight first or are you supposed to do some trickery and make the calls from injected scripts?
StackOverflow says you add it to the permissions part of your chrome extension manifest. Hopefully this is still a correct answer, it’s 11 years old :) See “CORS Chrome Extension with manifest version 2 Is it possible to use CORS when writing a google chrome extension?”
At the time, I thought since running Node JS could circumvent CORS, I found StackBlitz, to run WebContainers with NodeJS, maybe this could get away too, but this always stayed a theory.
Its there to protect that user, not other users, so if a user jumps through the hoops (its surprisingly hard to do this on Chrome without an extension) then they’re at most screwing thenselves.
The thing about CORS I don't get is why are browsers subject to CORS policies, but not 3rd party apps that send these requests by themselves, like CURL? Is it that browsers are just a more common attack vector? That aspect makes the idea of CORS seem like a moot point to me, frankly, and it makes me wonder why did people even decide to make CORS a thing in the first place.
The risk it’s guarding against is people writing malicious sites which try and call other sites from the victims browser, allowing access to sensitive information due to the session cookies held by the or bypassing IP or VPN restrictions. It’s hard to get a victims computer to make curl requests, and it would not carry their cookies if possible.
Yes, it's because browsers are an attack vector due to the fact they can execute any JS code that gets served to them (not just JS code from the domain that served the web page). Let's expand your curl example. If you write a curl command make an HTTP request to data to a URL, you specify what data to send in the request explicitly. You might use the -H flag to set a header or the -d flag to set the body of the request. When a web browser is the HTTP client, it includes data implicitly (cookies). It's a good idea to restrict which domains requests can go to if they're going to automatically include data like this. A good example would be a website other than your online banking website being allowed to make a request to the domain of your online banking website. If the cookies were sent there, it would authenticate the request. You don't want that other website to get response data from your online banking website's servers. A good way to think about all of this is to remember that web browsers are capable of running a lot of different code. It's kind of like having an operating system where it can run any program you want it to by you installing it, except the web browser doesn't need the program to be installed into it. If the JS code is loaded via a element, it'll run. And you won't even be told it's running (you'd need to check dev tools in your browser to see it happening).
I would just whitelist origins that needs resource access includes localhost dev environments and everything's fine, I had issues back then ngl It turned out I had to configure cors on my nodejs app.
from time to time i get asked to integrate apps never designed for sso into enterprise sso infrastructure. trivial without asking the app devs to make major changes to their code using loadbalancers and oauth.... unless the app uses cors... then its best to forget the need for the app and the app. its just a pain and a curse
Look like it time to stop using js as a backend and switch to go. Also I feel like a simple Middleware is all you need. Cors is frustrating but not that bad. Maybe nextjs is just frustrating
5:05 you shouldn't have to write the same code twice. That's the reason Middleware is great. I'm sure we could make a better design. I'm not super familiar with nextjs new app router but it seems like some of your headache comes from these nextjs patterns. Maybe a server with Middleware is a better approach. Love your content let me know what you think
CORS is painful but a necessary evil. Otherwise the browser would trust the current page to connect to any server. Better to have an opt-in system like CORS, or better yet, serve everything from the same origin (same domain). HTTP proxying makes sense for most projects, and makes sense for StackBlitz.
I thought the OPTIONS call was the only one that needs the CORS headers as it's the pre-flight request. Then all subsequent requests that were allowed can just be made without any CORS headers at all. Guess not?
No, you always needed the subsequent requests to also respond with the appropriate CORS headers, otherwise the browser would not allow you to access the response.
CORS was not a mistake. It was created to drive frontend engineers to insanity, and it accomplishes that to perfection.
no need to drive them, frontend devs will do it by themselves
see also: OAuth 2
@@btonez13OAuth2 is great wdym?
It's also easy to implement yourself either from documentations (Microsoft has some good ones) or from the RFC
Omg literally me
I believe all front-end tech has that goal
I could say that the web is CORSed
Get out!!!
@@rubendacostaesilva8442😂😂😂😂
Banger
Bruh
FR1!1!
It's more of a NextJS app router issue that you do no have a way to set common headers on the same URL for different http method. Most web-frameworks have CORS in mind and can let you easily setup CORS in some kind of middleware.
Yeah. CORS is definitely a flawed spec, no doubt about it, but the “obnoxious” bit here is a Next thing
Most definitely, it just shows how immature these JS frameworks for backend are. I mean its not end of the world as CORS is not THAT complicated. Also the preflight (OPTIONS http verb call) is meant for browsers to check the response headers so that the actual request can/cannot be sent, if can be sent then after the actual request browser checks that request response headers for the actual response.
Oh yes these Js framework's are really immature, I did try to implement API using nextjs lots of issues like this. Java , phyton or c# is better for API development. I switched to remix for frontend from nextjs.... Much more flexible and uses unwrapped native node JS request and response.....
@@MrRaitiz indeed, he key point about OPTIONS is that it guards against any side effects of the request, effectively to guard against a CSRF attack.
Servers could guard against this by checking the CORS headers before carrying out the request, but it looks like the CORS spec takes a precautionary approach and assumes the server does not do this,
The weird thing is the websocket spec takes the opposite approach and relies on the web sockets server to validate the Origin header within the app logic.
I wonder how many webscketa servers do not check the Origin.
I agree, this is a framework problem.
On top of that, with server actions nextjs implemented an origin header check on the server. This is obnoxious part, instead of providing a good DX on top of a browser enforced CORS, they implement something else, that is much less flexible, adding another set of error messages to the pile. Have fun implementing a multi tenant app where users suppose to point their custom domain to your app. You’ll need to know all allowed hosts at build time AND still have to deal with CORS to prevent cross scripting issues between your tenants …
I hate that this video gives the impression that the problem is CORS, but in fact, the real problem is with Next.js.
yea this video missed the mark soo bad, it comes off like Theo doesn't really understand what CORS solves.
Most backend frameworks, like laravel or aspnet.core, deal with CORS gracefully.
This is more of an issue with nextjs than any other thing.
that won't solve node.js cor's issues :D
@@GamePlayByFaks fun fact cors package is configurable on nodejs
@@fnfal113 let's be real not everybody add's packages to handle cor's that's just reality of it, since dependency hell on nodejs all ready is a thing...
Note:
Also don't forget not everybody use latest and greatest stuff around, like we have spa vue.js v1.x with node.js that is a bit outdated, so each time is a gamble.
Thank you, exactly what I wanted to say. Nodejs logic: "we can't write proper code to handle a web standard or copy solution from other technologies" = "web standard is stupid". Guys, just look how it is done in other frameworks, why do JS devs need to invent everything again from scratch?
@proosee
because node isn't a framework, it's an engine to run JS outside of the browser.
Problem is that web devs should learn fundamentals, and why we have CORS, and how to address these issues in non security threatening way. Most of devs solve it by allowing all origins, which intoduces many security risks.
The Twitter replies shown in this video are enough to conclude that people have no idea what they are doing.
@@31redorange08 what is worse is that many devs working in big companies do not know either. Since web dev became an industry, real knowledge has declined.
Agreed allowing all in prod is NOT a solution.
the entire video itself is just web dev skill issues
Productive devs vs senior devs problem right there. @@phillipgilligan8168
There are two kinds of webdevs, those who hate CORS and those who can read a full MDN page to understand something.
I think devs who hate CORS are devs who still didn't fully understand what CORS are for and how they work. I mean, what is there to hate, once you get them ? Security ? Isn't it a GOOD thing ?
You can hate something that is difficult to work with even if that added difficulty is a net good.
wow did you say it? I agree! Also, you should never set Access-Control-Allow-Origin = *, unless your API is meant to accept requests from unknown sources.
@@Rust_Rust_Rust Ok, I can agree. But CORS couldn't be more simpler. I'd even argue its failure is to be too simple : for example being able to only declare one domain as an allowed origin. They could have allowed you to just send back a coma separated list.
But I don't see how CORS is "difficult to work with". It's a bunch of headers that tells a browser what methods it can use and from what domain, for a certain URL. Nothing more.
@@Hexalyse lol lol arguing it's too simple while pointing out a main cause of why it's not simple. LOL 🤡🤸
@@TheNewtonI'd like to see him hook up a front end to an API he hasn't worked with before on a live stream. If you think CORS couldn't be "more simpler", either you're amazing, or don't code very much.
I disagree wholeheartedly with this. CORS is not flawed, next.js is flawed. The only time I've ever been caught out by CORS is when I forgot to configure CORS middleware. One commit later and there are no more issues. Use proper tooling for APIs and you won't run into half these issues.
Agree. CORS is basically a way for you to opt into which domains are allowed to interact with your server. How is that a bad thing? Complaining about CORS existing is like complaining about passwords existing. Would you be angry that passwords exist to allow you to opt in to who is able to access your accounts (if you even choose to allow this)? I doubt it. And from the other perspective, for those front end apps running in the browser on various domains out there, it was a backwards compatible way to make sure sensitive data wasn't being transmitted to 3rd party domains. Security by default is a good thing. The fact they added cross-domain AJAX support in a backwards compatible way like this is impressive.
I do realize it can feel complex to people who've never worked with it before. And that complexity can be magnified when you're working with a 3rd party thing (like this video creator is) who is also doing something complex, like running things meant to be run on servers in the browser. Now you're at the mercy of how that 3rd party works. But you've always got the freedom to choose to simply not use that service.
Anyone new to CORS who is frustrated with it should use the same solution they've probably found successful so far when dealing with new things. If it's too complex, provide feedback to its creators so they can simplify it (CORS probably cannot be simplified any further) and then try as hard as you can to learn it. MDN has great resources for learning how CORS works.
One more tip I'll leave for people... embrace proxying if you need it. It's not the evil, dirty workaround it might seem to be. Browsers have no way to know that two domains are owned by the same party, so they have no way to trust a different domain when a request is being made to it. If you proxy the requests you want your app to make, hosting the proxy on your domain, the browser doesn't have to worry about this. You're vouching for that service to the browser. It simply makes another call to your domain, like it's doing for every other call to your backend. This doesn't even have to be a separate application. It can just be another route in your back end application if you want.
CORS is handled by the browser, the client needs the OPTIONS request to know whether or not the POST request is allowed, you're inflicting this pain upon yourself by hardcoding cors rules in javascript on different method calls, cors is supposed to be handled by the web server itself
web people don’t actually understand how the web works
Except for that not every request does need an option preflight request. As long as your request qualifies as a „simple request“ (specific content types and no non standard headers, etc) your browser will not issue a preflight request, but the response still needs the proper cord headers present
@@Mooooov0815 the "simple" requests are there for backwards compatibility reasons. GET calls with no additional headers (same as embedding an IMG tag in your document) or POST requests that do a simple application/x-www-form-urlencoded plain old form stuff.
@@Mooooov0815 If the request does not cause a modification on the server (i.e. GET), then it does not need a preflight, because you can simply filter when the response comes. But for a request that causes a modification on the server (i.e. POST), filtering on the response would be too late, so you need to check first.
I just want to point out, when watching your video in slow motion, at 5:52 when you close the image it is possible to read your X-Uploadthing-Api-Key. Thought you might want to fix that and reupload (or change the key).
Ty for heads up, thankfully that key hasn't been valid for over 2 months lol
why were you watching it in slow motion? 😂
@@ninjaasmoke People who are into security look very closely whenever somebody streams code. That black box redacting something which than moves behind that block is just asking to be checked out frame by frame 😂
@@ninjaasmoke there have been cases of filtering of... fingerprints or other codes. Wikipedia was requested to remove the FBI badge at wikimedia
This is why cors in laravel is global or per route or both. It's awesome. Makes cors easy
Laravel has built in package to handle that but if you have outer api for spa or whatever then that solves only one way not the other from node.js
@@GamePlayByFaks i meant cors.php in config folder
@@SanderCokart okay.
This video would've been better by mentioning *why* the OPTIONS request exists and why websockets don't use CORS. If the OPTIONS pre-flight request wasn't there then the browser would still have to execute the request against the actual endpoint, and the endpoint would still do 'the thing it is supposed to do' (e.g. delete all your files). The OPTIONS call is an 'innocent' call that has 'no' risk of having any side effects. Whether the required confirmation on the actual resource is or isn't beneficial enough in the grand scheme of things I agree can be debated, but frankly in no project I ever did different resources have different CORS responses, so I always just threw it in as some type of quick middleware on all routes which took me all of 5 minutes. Obviously the more complex your architecture is, the less true the 5 minute statement becomes (e.g. in one architecture setup I 'helped out with' (just giving advice) they had to dynamically sent the list of allowed servers to the API server which then had to add them to the CORS list, but that was a pretty crazy setup). As to why websockets don't require CORS: The argument goes that if the web was invented today we wouldn't have CORS nor the same origin policy and instead checking the Origin header would simply be left to the server. As websockets were invented 'late enough' in the web's development the argument goes that there is no risk of legacy servers to be concerned with, so leaving the check to webservers directly is simply more efficient.
" instead checking the Origin header would simply be left to the server." - im pretty sure that's how it is anyway.
@@RaZziaN1 The point is that for normal HTTP calls that's *not* the case right now, just for websockets as those are new.
@@RaZziaN1 not quite - most properly written websites would have CSRF protection jest originated from the same request, but as the Origin header is recent and not sent on all requests it would probably not be checked at all
...because backwards compatibility minutiae is piling up saddling modern web development with past bad decisions.
@@DavidMulderOne but I can just extract the origin, validate it, and set the cors to allow it? or am i missing something?
Dam there are like 3 rules to support CORS its really not that hard.
Second thing dont support CORS in your app, but in your infrastructure
Yes, you're absolutely correct. Unless the application needs to dynamically set the allowed source based, for example, on the user authenticated, you should deal with CORDS on Nginx, Apache, etc.
Let's talk solutions. When you're stuck on a CORS issue and need a quick fix, there are tools out there to help. Beeceptor, for example, is a lifesaver. It's this cool HTTP proxy that handles CORS smoothly, adding required headers to the original API response. Frontend/Javascript devs looking to get past those annoying CORS blockers, a time saver!"
Let us connet, I would like to test my online voting solution API .
This video convinced me CORS should stay the same. They guard you from this messy approach
I can't understand where the issue is here? CORS is well dcoumented and super important.
The preflight request happens because of the way http works, which means the browser doesn't want to send the actual request before asking the server, hey is this okay.
And then it makes total sense it RE-verifies it on the actual request.
This makes sure a clien't cant request a server if the server is limited to a specific origin.
Regarding the sockets thing, http works over tcp sockets? So cors is only concerned with the content of the http request and doesnt care about anything below it.
Further the argument: i had to write the headers twice, have people forgot something called middleware exists?
I can understand it can be frustrating, but it seams this is more because the concept of cors wasn't understood rather then cors actually being wrong.
I think when he said sockets he meant websockets, which does not need CORS to go cross domain - instead the server is supposed to validate the Origin header.
The reason CORS has a preflight request is because some web endpoints may predate CORS and not know to check the Origin header, and would be vulnerable.
Skill issue
I was just about to say. This is no more than a skill issue. Dont't be hating on stuff that increases security and safety on the net.
The only reasonable comment here.
Before CORS it was common to see the session or CSRF token in the URL for pages with potentially sensitive content that was server-rendered. It was a much bigger pain both as a developer and a user (couldn't just copy URL to send to a friend or colleague since it was unique to your session and sometimes to that specific page-access). Perhaps there's a 3rd option that would be better, but comparing to the way websockets did it for example: I think it's simpler for web servers to set one (sometimes you need the others, but in my experience it's rare) headers on the endpoints, where cross-origin is OK, than to check the origin header on every endpoint that may have sensitive data. The header can be set by the edge server, whereas the origin checks usually have to live in the application code.
I work on a legacy system, and someone was trying to add a more modern API (the new code is somehow worse than the old, but that is a tale for another day) on a separate domain, and strugled for days with CORS, I was like "come on, we are behind a reverse proxy, just put the API on the same domain with a url prefix" and everybody was happy ever after... except when someone needs to touch the new code
Only calling it Cross Origin Request Stuff from now on
CORS or and TLS specific code shouldn't be written in node. That is the only problem here.
I'm currently building my first real full stack app and I'm currently facing exactly this problem lol, thank you Theo for hearing out my soul always
This is pain. But you know what's even more painful? The fact that you don't have canary deployments for stuff that you know might fail due to a developer's mistake
senior engineer and don't know how to deal with CORS?
Honestly stuff like this is where having an API gateway and a proper deployment process where you can set rules like CORS and authentication as part of your infrastructure code instead of putting it in your javascript like you were doing in this video.
I love watching real world debugging. I think getting a peek into the mindset of somewhen when fighting issues is so important. So much of this work is about solving the right problem and checking the right things and not digging yourself deeper. Its also an extremely personal process.
Thanks as always for sharing.
"I FIXED IT"
"I did not fix it."
Yeah, sounds like cors.
I always hated CORS, it seems like reinventing cookies would be a smarter move… Anyway, thanks for the video! Letting you know that the screen is flickering on darker tones like in 4:50. I thought there was a problem with my tv hahah
no issue with flickering for me
@@RaZziaN1its very subtle, I can see it in my tv and phone very well, but it is harder to spot on my monitor (I can still see it though, but it is definitely not as annoying as on my tv, probably due to local dimming)
I still will not forget the time i was learning laravel in my internship. For some reason, failed user validation in the backend would result in a CORS error. I had to figure out everything on my own. A fucking hellhole that was.
error pages usually dont emit the correct cors headers
They don't want some website making requests to another website because cookies are sent by default, so by default, those requests could be authenticated. The solution was to list all websites that are allowed to make such requests. In my opinion, an easier solution would be to just not send the cookies in those cases instead of blocking the request. Sometimes you just want to make an unauthenticated request to a different domain and with the protocol we have now, you need to proxy the request to work around CORS. If you are just writing some html to run from the file system. You also don't get to do requests so you always have to spin a small web server. But it is too late to change how this works now. Maybe in the future with new protocols we won't have this problem anymore. I'd rather start from scratch than patch this in a way that won't break older pages.
The issue with this approach is that if the victim is on an internal network it would allow access to internal services through a malicious websites.
The localhost restriction is probably there for a good security reason as well
At 5:36 you leak a few character from the key, definitely not enough to access something but maybe still a good reason to recreate it
I've literally never had an issue with CORS. I actually love that cors exists so I can deny malicious attackers. :D CSRF was so much pain to integrate and handle than cors, which I still have to do sometimes and make things work.
In my recent battle with CORS, I just slapped some "no cors" in there and called it a day
I hate to take this stance, and sound like Prime, but this seems like a skills issue. Setting up an endpoint to respond with the same CORS headers for OPTIONS or POST/GET without copy-pasting the code isn't hard.
I understand that backend code running in the browser needs work to adhere to CORS, and I totally get how "wait my requests are running in the browser now" wouldn't necessarily occur to a dev immediately. But I feel like if you sit down and understand CORS these things become apparent and reasonable pretty quickly.
The OPTIONS preflight is an effort to avoid server-side actions that the client can't read the result of. But the CORS checks still need to pass on the actual request for the browser JS to get access to the response (but you'll see the request did actually happen if you look at the server).
CORS is complicated & confusing, BUT PRETTY MUCH ESSENTIAL to prevent malicious websites doing bad things! I'm convinced that it needs to be what it is and work pretty much how it does. Use a good library (such as django-cors-headers) and just enable what needs to be allowed. I think what is confusing about CORS is it the browser restricting what the client can do, whereas normally it's the server restricting what the client can do.
Consider writing a server that, after recieving a request, queries a database and then serves html
😂😂omfg
So let's fix it. How would we start doing that?
I work at a billion+ dollar company and we had some CORS related problems last week. It wasnt that CORS was blocking anything its just that our logs in datadog went from a few hundred thousand to over 2million overnight when we launched a new product because the new product had a new service that talked with our core service and every request was hitting a CORS check. So I figured out we should just set Max-Age on the requests so CORS can effectively f-off for at least for some time. And then I learned that the max-age DIFFERS FROM BROWSER TO BROWSER.
I hate CORS.
Does it differ in between different versions of same browser though?
Just wondering, because knowing world of developers it could very well be so.
CORS: an ordeal every time
Partytown with GTM has this issue. I don't control GTM backend so how to solve it even 😂?
If you don't use cookies
Leave cors open
damm, i was dying fixing cors errors for 2 hours just 30 min ago
How did you fix it?
Currently smashing my head into my keyboard because of CORS, surprised the keys still work well enough for me to type this.
yea that "prefab" OPTION calls took us few hours too :D, and fixed only because we tried normal ajax and not fetch where you see "prefab" request in network ...
Listening is already so complicated, could you imagine dealing with these?
The funny part of this is you can just put the API calls behind a server and bypass CORS all together. In other words, the only nefarious actors thwarted by CORS are the lazy ones who want to just use a cross origin resource by copy/pasting a URL into their source.
It was definitely written by those esoteric programmers who are like 'read the manual' instead of making it good. I wonder how many millions of dollars they have cost in lost time.
Almost as bad as certificates, just recently the windows 22H2 update made some sites use TLS1.3 ... which broke. good times.
I made a cross origin POST request to my own custom HTTP server. I got the request and parsed it correctly, but the browser refused to hand over the response because of CORS. What does that help? I have already processed the request on the server and sent a response knowing the source of the request. I know I can add some headers to allow access to the browser, but why? The server has decided to not reject the request, shouldn't that be enough?
It's frustrating when I am a junior developer who is trying to learn fullstack and suddenly you get CORS-policy violation. You have no clue what it means, what causes it and how to fix it. All you know is suddenly your app isn't working anymore. Good luck!
actually the biggest problem with cors in my opinion is that i've read countless explanations and still not sure why the fuck do we need this in the first place
It gets even worse when the headers get cached during development. Oh boy does it get worse…
In my 20 years of coding, for the backend, I have used Sping (JAVA), Laravel (PHP), Symfony (PHP), .NET, Django (Python), Flask (Python), Gin (Go). CORS has never been an issue and I have dealt with it more times than I can count. CORS was well designed and thought out and all the frameworks I have mentioned deal with it nicely. This video is nothing but a NEXTJS problem!! And the bigger picture is that javascript should have stayed in the browser!
The reason why cors is not enforced on websockets is because websockets requests results in a 101 and have no body.
CORS is not an attempt to protect the origin site but the foreign resource itself, like images and what not.
This enable backends to protect against malicious websites running on genuine user browser.
Its pain because the server software you use is bad, but hating on cors is like hating on tls.
its improperly named, it should be called CORB: Cross-Origin Resource Blocking because thats all it seems able to do
No, you apparently don't understand CORS.
My service just returns the exact same cors headers on every single request. Does Next not have a middleware setup like Express?
argh, I feel this pain, I wouldn't piss on cors' burning body...it's always a pain in the neck
Couldn't you write a rule implemented as a function or class that encapsulates all of this in one place?
"WE SHOULD NOT BE HERE, CATCH YOUR FAILURES EARLIER" xddd
I feel like I've just been to a successful support group meeting :)
Why do you include Access-Control-Request-Method in the server code? That's just a header sent by the client during the OPTIONS pre-flight. I would remove that in cases it causes problems with some clients. Some clients are really picky about stuff (like Access-Control-Allow-Methods did not allow wildcards in the past). There's a lot of subtleties as you get into edge cases with credentials and allowed request headers. Even re-reading through my implementation for work just now, I realized my own implementation is not quite correct because for my OPTIONS response, I send back the origin requested in "Access-Control-Allow-Origin", but because I do that, I should add a "Vary" header specifying that so that any intervening proxies do not cache the "Access-Control-Allow-Origin" response just for that particular asked for origin.
CORS is a pretty good standard, I don't think it's a problem because of CORS, it's more about how the browser implements it and also does it allow you to pass your own preflight info or an API call. One of reasons why I don't like front-end development because it's mostly your browser and also some browsers gives stuff like blocking these kind of cases. If you deal with them you will hate CORS more than anything. Sometimes same happens with cookies too.
Not sure if you noticed but your (duplicated) cors headers code is out of sync ;) in options your settings are different than in post ;) Just like you said in the video (different methods listed ;) )
I gave up trying to get CORS working while having my entire app in docker containers in development.
BFF is your best f****** friend. Pre-flights add significant extra latency, particularly if paying the Cloud Flare latency tax, and it's particularly bad for some users; like international.
Serve your FE from the same origin as your API.
This is kind of a Next problem rather than a CORS problem.
CORS is a true nightmare, lol! A labyrinth within a maze!
Man, you gotta take a break when you're stuck on a bug that long. It's always easier to fix with a clear head the next day.
As an API developer never had to actually deal with CORS, mostly because framework handled it for me. All I had to do is to setup one middleware, and that's all.
CORS should be a turn on feature rather than a turn off feature
It’s more about lot of the framework don’t have custom cors setting by deployment profile by default or it’s not flexible enough it’s so rigid nothing can be customized. It’s make developer need to setup cors header and OPTION manually in hacky way like demonstrated on this video.
The easiest way to solve it in production is by using proxy server or api gateway to make all the cors setup centralized on one place.
My favourite „solution“ for Development landed in Chrome a couple of months ago. Overwriting response headers like setting Access-Control-Allow-Origin to *
ruclips.net/video/e8tl_yp5BQg/видео.html
So many answers on stack overflow do the same... Which is a pity.. always try to understand why things happen
Honestly, I'd rather deal with CORS, than trying to wrestle wth nx, typescript, babel and webpack.
I remember the OPTIONS headache - and different implementations in different browsers.
I as a user should be able to disable cors as easily as i can disable "Enhanced tracking protection"
Not being a "webdev" my foray into dealing with js and cors has been complete hell (mainly getting data from apis i do not own like weather data that don't provide a way to deal with cors)
The only good thing cors has done is to push me to just do all of that garbage on a local server and simply serve the data that way instead of having the "application" run within the browser
I actually had a cors issue today. Found an easy fix though, thankfully.
Is Theo saying that Chrome Extensions have the ability to bypass CORS? How? I feel like I've run into CORS errors plenty of times and had to resort to proxying even with extensions? Maybe its because I didn't do the pre flight first or are you supposed to do some trickery and make the calls from injected scripts?
StackOverflow says you add it to the permissions part of your chrome extension manifest. Hopefully this is still a correct answer, it’s 11 years old :)
See “CORS Chrome Extension with manifest version 2 Is it possible to use CORS when writing a google chrome extension?”
Yeah, that's what you get for being spiteful about other's misfortune.
I feel like this is a CORS + BROWSER issue
Cors are easy, I have been able to learn about them perfectly after dealing with errors related to them for few days, after that it's easy.
I’d love to hear about conceptual alternatives
At the time, I thought since running Node JS could circumvent CORS, I found StackBlitz, to run WebContainers with NodeJS, maybe this could get away too, but this always stayed a theory.
MeToo
csrf token that rotates after every request
LOL I ran into the OPTIONS issue when trying to make an OpenAI Compatible Endpoint... the things you learn trying to make a server...
This seems like a Next issue and not really a CORS issue.. I do not have any problems dealing with it in python, java or rust backends ive tried
To make it more fun, it's ultimately just a client side measure that can be disabled by a user (browser).
Its there to protect that user, not other users, so if a user jumps through the hoops (its surprisingly hard to do this on Chrome without an extension) then they’re at most screwing thenselves.
You shouldn't write cors in your request handler. Cors should probably be in a filter somewhere
CORS is way better than the hacks we used to have to do (like JSONP). The issue is your framework.
I suggest we call it kors as in causing korsakov
The thing about CORS I don't get is why are browsers subject to CORS policies, but not 3rd party apps that send these requests by themselves, like CURL? Is it that browsers are just a more common attack vector? That aspect makes the idea of CORS seem like a moot point to me, frankly, and it makes me wonder why did people even decide to make CORS a thing in the first place.
The risk it’s guarding against is people writing malicious sites which try and call other sites from the victims browser, allowing access to sensitive information due to the session cookies held by the or bypassing IP or VPN restrictions.
It’s hard to get a victims computer to make curl requests, and it would not carry their cookies if possible.
Yes, it's because browsers are an attack vector due to the fact they can execute any JS code that gets served to them (not just JS code from the domain that served the web page).
Let's expand your curl example. If you write a curl command make an HTTP request to data to a URL, you specify what data to send in the request explicitly. You might use the -H flag to set a header or the -d flag to set the body of the request. When a web browser is the HTTP client, it includes data implicitly (cookies). It's a good idea to restrict which domains requests can go to if they're going to automatically include data like this. A good example would be a website other than your online banking website being allowed to make a request to the domain of your online banking website. If the cookies were sent there, it would authenticate the request. You don't want that other website to get response data from your online banking website's servers.
A good way to think about all of this is to remember that web browsers are capable of running a lot of different code. It's kind of like having an operating system where it can run any program you want it to by you installing it, except the web browser doesn't need the program to be installed into it. If the JS code is loaded via a element, it'll run. And you won't even be told it's running (you'd need to check dev tools in your browser to see it happening).
My most popular stackoverflow question and answer are about CORS
You also "have do deal with" seatbelts if you drive anywhere :)
isnt this a reupload? or am i not remember right
Hello world
That CORS frustration you got there is pretty cool. It would be a shame if someone
MADE A SERVER-SIDE PARTNER TO IT CALLED XSRF-CSRF
🤬🤬🤬🤬
CORS feels like a Microsoft API from 8 years ago.
I would just whitelist origins that needs resource access includes localhost dev environments and everything's fine, I had issues back then ngl It turned out I had to configure cors on my nodejs app.
It's definitely a CORS for concern
from time to time i get asked to integrate apps never designed for sso into enterprise sso infrastructure. trivial without asking the app devs to make major changes to their code using loadbalancers and oauth.... unless the app uses cors... then its best to forget the need for the app and the app. its just a pain and a curse
Look like it time to stop using js as a backend and switch to go. Also I feel like a simple Middleware is all you need. Cors is frustrating but not that bad. Maybe nextjs is just frustrating
What issues in this video were Next specific?
So nextjs address this issue with elegant solution?
5:05 you shouldn't have to write the same code twice. That's the reason Middleware is great. I'm sure we could make a better design. I'm not super familiar with nextjs new app router but it seems like some of your headache comes from these nextjs patterns. Maybe a server with Middleware is a better approach. Love your content let me know what you think
CORS is painful but a necessary evil. Otherwise the browser would trust the current page to connect to any server. Better to have an opt-in system like CORS, or better yet, serve everything from the same origin (same domain). HTTP proxying makes sense for most projects, and makes sense for StackBlitz.
I thought the OPTIONS call was the only one that needs the CORS headers as it's the pre-flight request. Then all subsequent requests that were allowed can just be made without any CORS headers at all. Guess not?
No, you always needed the subsequent requests to also respond with the appropriate CORS headers, otherwise the browser would not allow you to access the response.
Wow, that seems a bit excessive, I wonder why that was designed in such a manner.