CORS to mechanizm przeglądarki, nie błąd serwera. Dlatego Postman działa, a Twoja wdrożona aplikacja nie. Ten poradnik krok po kroku pokaże Ci, jak to naprawić właściwie.
CORS is a browser mechanism, not a server bug. That's why Postman works but your deployed app doesn't. This is a step-by-step guide to fix it properly.
CORS är en webbläsarmekanism, inte ett serverfel. Därför fungerar Postman men din driftsatta app gör det inte. Den här guiden visar steg för steg hur du löser det på rätt sätt.
CORS er en nettlesermekanisme, ikke en serverfeil. Derfor fungerer Postman, men den utrullede appen din gjør det ikke. Denne guiden viser deg steg for steg hvordan du fikser det riktig.
CORS jest mechanizmem przeglądarki. Za każdym razem, gdy Twoja aplikacja próbuje wysłać zapytanie do innego hosta, przeglądarka pyta serwer, czy wolno jej to zrobić. To nie jest błąd w Twoim kodzie — to warstwa bezpieczeństwa wbudowana w każdą przeglądarkę. Problem w tym, że większości ludzi nikt tego nie wytłumaczył.
Kod generowany przez AI plus publiczne wdrożenie to miejsce, w którym większości ludzi CORS eksploduje w twarz. Na localhost wszystko działało, bo frontend i backend żyli pod tym samym adresem. Po deploy'u — są na różnych domenach i przeglądarka blokuje zapytania.
Ten artykuł to praktyczny poradnik krok po kroku. Wyjaśniamy, czym CORS naprawdę jest, dlaczego narzędzia AI robią to gorzej, i jak to naprawić raz a dobrze — z kodem, który możesz skopiować i użyć od razu.
CORS is a browser mechanism. Whenever your app tries to send a request to a different host, the browser asks the server if it's allowed to do so. It's not a bug in your code — it's a security layer built into every browser. The problem is that most people were never taught how it works.
AI-generated code plus public deployment is where most people get burned. On localhost everything worked because the frontend and backend lived at the same address. After deployment — they're on different domains and the browser blocks the requests.
This article is a practical step-by-step guide. We explain what CORS actually is, why AI tools make it worse, and how to fix it once and for all — with code you can copy and use immediately.
CORS är en webbläsarmekanism. Varje gång din app försöker skicka en förfrågan till en annan host frågar webbläsaren servern om det är tillåtet. Det är inte en bugg i din kod — det är ett säkerhetslager inbyggt i varje webbläsare. Problemet är att de flesta aldrig lärde sig hur det fungerar.
AI-genererad kod plus publik driftsättning är där de flesta bränner sig. På localhost fungerade allt eftersom frontend och backend levde på samma adress. Efter driftsättning — de är på olika domäner och webbläsaren blockerar förfrågningarna.
Den här artikeln är en praktisk steg-för-steg-guide. Vi förklarar vad CORS egentligen är, varför AI-verktyg gör det värre, och hur du fixar det en gång för alla — med kod du kan kopiera och använda direkt.
CORS er en nettlesermekanisme. Hver gang appen din prøver å sende en forespørsel til en annen host, spør nettleseren serveren om det er tillatt. Det er ikke en feil i koden din — det er et sikkerhetslag innebygd i hver nettleser. Problemet er at de fleste aldri lærte hvordan det fungerer.
AI-generert kode pluss offentlig utrulling er der de fleste brenner seg. På localhost fungerte alt fordi frontend og backend levde på samme adresse. Etter utrulling — de er på ulike domener og nettleseren blokkerer forespørslene.
Denne artikkelen er en praktisk steg-for-steg-guide. Vi forklarer hva CORS egentlig er, hvorfor AI-verktøy gjør det verre, og hvordan du fikser det en gang for alle — med kode du kan kopiere og bruke med en gang.
CORS (Cross-Origin Resource Sharing) to mechanizm bezpieczeństwa przeglądarki, nie błąd serwera. Działa tak: za każdym razem, gdy Twoja aplikacja próbuje wysłać zapytanie HTTP do innego originu (innej domeny, portu lub protokołu), przeglądarka najpierw pyta serwer docelowy, czy jest to dozwolone.
Na localhost Twój frontend i backend zwykle działają pod tym samym adresem — na przykład http://localhost:3000. To jest same-origin — ta sama domena, ten sam port, ten sam protokół. Przeglądarka nie widzi problemu, bo zapytanie idzie do tego samego hosta. Dlatego właśnie na etapie developmentu wszystko działa.
Po wdrożeniu Twój frontend zaczyna żyć na https://mojaapka.com, a backend na https://api.mojaapka.com albo na zupełnie innej domenie. To jest już cross-origin. I tu przeglądarka wchodzi do gry.
Zanim przeglądarka wyśle Twoje prawdziwe zapytanie (POST, PUT, DELETE), najpierw wysyła tak zwane zapytanie preflight — zapytanie OPTIONS do tego samego URL-a. To jest pytanie: «Hej serwer, czy frontend z domeny X może Ci wysyłać zapytania typu POST z takimi nagłówkami?» Jeśli serwer nie odpowie właściwymi nagłówkami CORS, przeglądarka zablokuje zapytanie zanim je w ogóle wyśle.
Kluczowa sprawa: CORS to mechanizm przeglądarki. Postman, curl, zapytania z serwera — żadne z nich nie stosuje CORS. Dlatego Twoje API może działać doskonale w Postmanie, a w przeglądarce wyrzucać błędy. To nie jest błąd API — to przeglądarka robi swoją robotę.
CORS (Cross-Origin Resource Sharing) is a browser security mechanism, not a server error. Here's how it works: whenever your application tries to send an HTTP request to a different origin (a different domain, port, or protocol), the browser first asks the target server whether this is allowed.
On localhost, your frontend and backend usually run at the same address — for example http://localhost:3000. That's same-origin — same domain, same port, same protocol. The browser sees no issue because the request goes to the same host. This is why everything works during development.
After deployment, your frontend lives at https://myapp.com and your backend at https://api.myapp.com or an entirely different domain. That's cross-origin. And this is where the browser steps in.
Before the browser sends your actual request (POST, PUT, DELETE), it first sends a so-called preflight request — an OPTIONS request to the same URL. It's essentially asking: "Hey server, is the frontend from domain X allowed to send POST requests with these headers?" If the server doesn't respond with the right CORS headers, the browser blocks the request before it's even sent.
The key thing to understand: CORS is a browser mechanism. Postman, curl, server-to-server requests — none of them enforce CORS. That's why your API can work perfectly in Postman while throwing errors in the browser. It's not an API bug — it's the browser doing its job.
CORS (Cross-Origin Resource Sharing) är en säkerhetsmekanism i webbläsaren, inte ett serverfel. Så här fungerar det: varje gång din applikation försöker skicka en HTTP-förfrågan till en annan origin (en annan domän, port eller protokoll) frågar webbläsaren först målservern om det är tillåtet.
På localhost kör din frontend och backend vanligtvis på samma adress — till exempel http://localhost:3000. Det är same-origin — samma domän, samma port, samma protokoll. Webbläsaren ser inget problem eftersom förfrågan går till samma host. Det är därför allt fungerar under utveckling.
Efter driftsättning lever din frontend på https://minapp.com och din backend på https://api.minapp.com eller en helt annan domän. Det är cross-origin. Och där kliver webbläsaren in.
Innan webbläsaren skickar din faktiska förfrågan (POST, PUT, DELETE) skickar den först en så kallad preflight-förfrågan — en OPTIONS-förfrågan till samma URL. Den frågar i princip: «Hej server, får frontend från domän X skicka POST-förfrågningar med dessa headers?» Om servern inte svarar med rätt CORS-headers blockerar webbläsaren förfrågan innan den ens skickas.
Det viktigaste att förstå: CORS är en webbläsarmekanism. Postman, curl, server-till-server-förfrågningar — ingen av dem tillämpar CORS. Därför kan ditt API fungera perfekt i Postman medan det kastar fel i webbläsaren. Det är inte en API-bugg — det är webbläsaren som gör sitt jobb.
CORS (Cross-Origin Resource Sharing) er en sikkerhetsmekanisme i nettleseren, ikke en serverfeil. Slik fungerer det: hver gang applikasjonen din prøver å sende en HTTP-forespørsel til en annen origin (et annet domene, port eller protokoll), spør nettleseren først målserveren om det er tillatt.
På localhost kjører frontend og backend vanligvis på samme adresse — for eksempel http://localhost:3000. Det er same-origin — samme domene, samme port, samme protokoll. Nettleseren ser ikke noe problem fordi forespørselen går til samme host. Det er derfor alt fungerer under utvikling.
Etter utrulling lever frontend på https://minapp.com og backend på https://api.minapp.com eller et helt annet domene. Det er cross-origin. Og der trer nettleseren inn.
Før nettleseren sender din faktiske forespørsel (POST, PUT, DELETE), sender den først en såkalt preflight-forespørsel — en OPTIONS-forespørsel til samme URL. Den spør i bunn og grunn: «Hei server, har frontend fra domene X lov til å sende POST-forespørsler med disse headerne?» Hvis serveren ikke svarer med riktige CORS-headere, blokkerer nettleseren forespørselen før den i det hele tatt sendes.
Det viktigste å forstå: CORS er en nettlesermekanisme. Postman, curl, server-til-server-forespørsler — ingen av dem håndhever CORS. Derfor kan API-et ditt fungere perfekt i Postman mens det kaster feil i nettleseren. Det er ikke en API-feil — det er nettleseren som gjør jobben sin.
CORS jest mechanizmem przeglądarki. Za każdym razem, gdy próbujemy wysłać zapytanie do innego hosta, przeglądarka pyta, czy wolno jej to zrobić. Dlatego Postman działa, a Twoja przeglądarka nie — Postman nie jest przeglądarką i nie stosuje tej reguły.
CORS is a browser mechanism. Whenever you try to send a request to another host, your browser asks if it's allowed to do so. That's why Postman works but your browser doesn't — Postman isn't a browser and doesn't enforce this rule.
CORS är en webbläsarmekanism. Varje gång du försöker skicka en förfrågan till en annan host frågar din webbläsare om det är tillåtet. Därför fungerar Postman men din webbläsare gör det inte — Postman är inte en webbläsare och tillämpar inte denna regel.
CORS er en nettlesermekanisme. Hver gang du prøver å sende en forespørsel til en annen host, spør nettleseren om det er tillatt. Derfor fungerer Postman mens nettleseren din ikke gjør det — Postman er ikke en nettleser og håndhever ikke denne regelen.
Typowy scenariusz: widzisz błąd CORS w konsoli. Mówisz AI «napraw CORS». AI zmienia coś w kodzie serwera. Błąd CORS znika — ale teraz coś innego nie działa. Mówisz AI «napraw to». AI przepisuje kolejną część kodu. I tak zaczyna się kaskada.
Widziałem to na własne oczy u klientów: pozwolenie AI «naprawić CORS» przepisało kod serwera, zepsuło importy, selekty z bazy danych i kształt odpowiedzi. Trzy dni na cofnięcie tego, co AI zrobiło w sekundy.
Problem jest fundamentalny: AI nie rozumie granicy między frontendem a backendem. Nie wie, który kod działa w przeglądarce, a który na serwerze. Kiedy prosisz o naprawę CORS, AI często modyfikuje frontend (dodaje mode: 'no-cors' do fetch) lub zmienia kod serwera w sposób, który psuje wszystko inne.
Najgorsze co AI robi:
Access-Control-Allow-Origin: * wszędzie — wildcard zamiast konkretnych domen. Niebezpieczne w produkcji.OPTIONS — preflight zostaje bez odpowiedzi, więc przeglądarka blokuje wszystko.mode: 'no-cors' do fetch po stronie frontendu — to chowa problem, a nie go naprawia. Odpowiedź staje się «opaque» i nie można odczytać żadnych danych.Kiedy coś się psuje, ludzie reagują naturalnie: promptują dalej. «Napraw to». «Teraz tamto nie działa». «Cofnij ostatnią zmianę, ale zachowaj poprawkę CORS». Każdy kolejny prompt pogarsza sytuację, bo AI nie pamięta, dlaczego kod wyglądał tak, jak wyglądał.
Here's the typical scenario: you see a CORS error in the console. You tell AI "fix CORS." AI changes something in the server code. The CORS error disappears — but now something else is broken. You tell AI "fix that." AI rewrites another part of the code. And that's how the cascade begins.
I've seen this firsthand with clients: letting AI "fix CORS" rewrote server code, broke imports, database selects, and response shapes. Three days to undo what AI did in seconds.
The problem is fundamental: AI doesn't understand the boundary between frontend and backend. It doesn't know which code runs in the browser and which runs on the server. When you ask it to fix CORS, AI often modifies the frontend (adds mode: 'no-cors' to fetch) or changes server code in ways that break everything else.
The worst things AI does:
Access-Control-Allow-Origin: * everywhere — a wildcard instead of specific domains. Dangerous in production.OPTIONS requests — the preflight goes unanswered, so the browser blocks everything.mode: 'no-cors' to fetch on the frontend — this hides the problem, not fixes it. The response becomes "opaque" and you can't read any data.When things break, people react naturally: they keep prompting. "Fix this." "Now that doesn't work." "Revert the last change but keep the CORS fix." Each successive prompt makes things worse because AI doesn't remember why the code looked the way it did.
Här är det typiska scenariot: du ser ett CORS-fel i konsolen. Du säger till AI «fixa CORS». AI ändrar något i serverkoden. CORS-felet försvinner — men nu är något annat trasigt. Du säger till AI «fixa det». AI skriver om en annan del av koden. Och så börjar kaskaden.
Jag har sett det här på första hand hos kunder: att låta AI «fixa CORS» skrev om serverkoden, förstörde importer, databasfrågor och svarsformatering. Tre dagar att ångra det som AI gjorde på sekunder.
Problemet är fundamentalt: AI förstår inte gränsen mellan frontend och backend. Den vet inte vilken kod som kör i webbläsaren och vilken som kör på servern. När du ber den fixa CORS ändrar AI ofta frontend (lägger till mode: 'no-cors' i fetch) eller ändrar serverkoden på sätt som förstör allt annat.
Det värsta AI gör:
Access-Control-Allow-Origin: * överallt — ett wildcard istället för specifika domäner. Farligt i produktion.OPTIONS-förfrågningar — preflight-förfrågan förblir obesvarad, så webbläsaren blockerar allt.mode: 'no-cors' i fetch på frontend — det döljer problemet istället för att lösa det. Svaret blir «opaque» och du kan inte läsa någon data.När saker går sönder reagerar folk naturligt: de fortsätter prompta. «Fixa det här.» «Nu fungerar inte det där.» «Ångra senaste ändringen men behåll CORS-fixen.» Varje ny prompt gör saken värre eftersom AI inte minns varför koden såg ut som den gjorde.
Her er det typiske scenariet: du ser en CORS-feil i konsollen. Du sier til AI «fiks CORS». AI endrer noe i serverkoden. CORS-feilen forsvinner — men nå er noe annet ødelagt. Du sier til AI «fiks det». AI skriver om en annen del av koden. Og slik begynner kaskaden.
Jeg har sett dette på førstehånd hos kunder: å la AI «fikse CORS» skrev om serverkoden, ødela importer, databasespørringer og svarsformater. Tre dager på å angre det AI gjorde på sekunder.
Problemet er fundamentalt: AI forstår ikke grensen mellom frontend og backend. Den vet ikke hvilken kode som kjører i nettleseren og hvilken som kjører på serveren. Når du ber den fikse CORS, endrer AI ofte frontend (legger til mode: 'no-cors' i fetch) eller endrer serverkode på måter som ødelegger alt annet.
Det verste AI gjør:
Access-Control-Allow-Origin: * overalt — et wildcard i stedet for spesifikke domener. Farlig i produksjon.OPTIONS-forespørsler — preflight-forespørselen forblir ubesvart, så nettleseren blokkerer alt.mode: 'no-cors' i fetch på frontend — dette skjuler problemet i stedet for å fikse det. Svaret blir «opaque» og du kan ikke lese noen data.Når ting går i stykker, reagerer folk naturlig: de fortsetter å prompte. «Fiks dette.» «Nå fungerer ikke det.» «Angre siste endring, men behold CORS-fiksen.» Hver nye prompt gjør ting verre fordi AI ikke husker hvorfor koden så ut som den gjorde.
Pozwolenie AI «naprawić CORS» przepisało kod serwera, zepsuło importy, selekty z bazy danych i format odpowiedzi. Trzy dni na cofnięcie tego, co AI zrobiło w sekundy. Nie promptuj dalej — zatrzymaj się i zrozum problem.
Letting AI "fix CORS" rewrote server code, broke imports, DB selects, and response shapes. Three days to undo what AI did in seconds. Don't keep prompting — stop and understand the problem.
Att låta AI «fixa CORS» skrev om serverkoden, förstörde importer, databasfrågor och svarsformat. Tre dagar att ångra det AI gjorde på sekunder. Fortsätt inte prompta — stanna upp och förstå problemet.
Å la AI «fikse CORS» skrev om serverkoden, ødela importer, databasespørringer og svarsformater. Tre dager på å angre det AI gjorde på sekunder. Ikke fortsett å prompte — stopp opp og forstå problemet.
Większość ludzi patrzy na błąd CORS w konsoli przeglądarki i myśli, że to problem z CORS. Ale często prawdziwy błąd jest gdzieś indziej. Otwieraj zakładkę Network w DevTools, a nie Console.
Znajdź zapytanie, które nie przeszło. Kliknij na nie i sprawdź kod odpowiedzi. Jeśli widzisz 500 Internal Server Error, to Twój serwer się wysypał — i bo się wysypał, nie dodał nagłówków CORS do odpowiedzi. Przeglądarka widzi brak nagłówka Access-Control-Allow-Origin i pokazuje błąd CORS, ale prawdziwy problem to błąd serwera.
Jeśli endpoint zwraca błąd (500), nagłówek Access-Control-Allow-Origin zwykle nie zostanie dodany. Napraw błąd serwera, a «błąd CORS» zniknie sam.
Most people look at the CORS error in the browser console and assume it's a CORS problem. But often the real error is elsewhere. Open the Network tab in DevTools, not Console.
Find the failed request. Click on it and check the response code. If you see 500 Internal Server Error, your server crashed — and because it crashed, it didn't add CORS headers to the response. The browser sees the missing Access-Control-Allow-Origin header and shows a CORS error, but the real problem is a server error.
If the endpoint errors out (500), Access-Control-Allow-Origin usually won't be added. Fix the server error, and the "CORS error" will disappear on its own.
De flesta tittar på CORS-felet i webbläsarens konsol och antar att det är ett CORS-problem. Men ofta är det verkliga felet någon annanstans. Öppna fliken Network i DevTools, inte Console.
Hitta den misslyckade förfrågan. Klicka på den och kontrollera svarskoden. Om du ser 500 Internal Server Error kraschade din server — och eftersom den kraschade lade den inte till CORS-headers i svaret. Webbläsaren ser den saknade Access-Control-Allow-Origin-headern och visar ett CORS-fel, men det verkliga problemet är ett serverfel.
Om endpointen ger fel (500) läggs Access-Control-Allow-Origin vanligtvis inte till. Fixa serverfelet, så försvinner «CORS-felet» av sig självt.
De fleste ser på CORS-feilen i nettleserkonsollen og antar at det er et CORS-problem. Men ofte er den virkelige feilen et annet sted. Åpne Network-fanen i DevTools, ikke Console.
Finn den mislykkede forespørselen. Klikk på den og sjekk svarkoden. Hvis du ser 500 Internal Server Error, krasjet serveren din — og fordi den krasjet, la den ikke til CORS-headere i svaret. Nettleseren ser den manglende Access-Control-Allow-Origin-headeren og viser en CORS-feil, men det virkelige problemet er en serverfeil.
Hvis endpointet feiler (500), legges Access-Control-Allow-Origin vanligvis ikke til. Fiks serverfeilen, og «CORS-feilen» forsvinner av seg selv.
Oto jak powinien wyglądać middleware CORS na serwerze Express.js. Zauważ, że ustawiamy konkretne domeny, a nie wildcard, obsługujemy zapytanie OPTIONS i ustawiamy credentials:
Here's what a CORS middleware should look like on an Express.js server. Notice that we set specific domains instead of wildcards, handle the OPTIONS request, and set credentials:
Här är hur ett CORS-middleware borde se ut på en Express.js-server. Notera att vi anger specifika domäner istället för wildcards, hanterar OPTIONS-förfrågan och ställer in credentials:
Slik bør et CORS-middleware se ut på en Express.js-server. Legg merke til at vi setter spesifikke domener i stedet for wildcards, håndterer OPTIONS-forespørselen og setter credentials:
A oto co zazwyczaj generuje AI, kiedy prosisz o «naprawienie CORS». Wygląda prosto, ale jest pełne problemów:
And here's what AI typically generates when you ask it to "fix CORS." It looks simple, but it's full of problems:
Och här är vad AI vanligtvis genererar när du ber den «fixa CORS». Det ser enkelt ut, men det är fullt av problem:
Og her er hva AI vanligvis genererer når du ber den «fikse CORS». Det ser enkelt ut, men er fullt av problemer:
Różnice są kluczowe: wildcard * oznacza, że każda strona na świecie może wysyłać zapytania do Twojego API. Brak obsługi OPTIONS oznacza, że zapytania preflight nie będą działać. Brak Allow-Credentials oznacza, że ciasteczka i tokeny nie będą przesyłane. To nie jest «naprawione» — to jest otwarta furtka bezpieczeństwa.
The differences are critical: the wildcard * means any website in the world can send requests to your API. No OPTIONS handling means preflight requests won't work. No Allow-Credentials means cookies and tokens won't be sent. This isn't "fixed" — it's an open security hole.
Skillnaderna är kritiska: wildcard * innebär att vilken webbplats som helst i världen kan skicka förfrågningar till ditt API. Ingen OPTIONS-hantering innebär att preflight-förfrågningar inte fungerar. Ingen Allow-Credentials innebär att cookies och tokens inte skickas. Det här är inte «fixat» — det är ett öppet säkerhetshål.
Forskjellene er kritiske: wildcard * betyr at hvilken som helst nettside i verden kan sende forespørsler til API-et ditt. Ingen OPTIONS-håndtering betyr at preflight-forespørsler ikke vil fungere. Ingen Allow-Credentials betyr at cookies og tokens ikke sendes. Dette er ikke «fikset» — det er et åpent sikkerhetshull.
Jeśli używasz Supabase Edge Functions (Deno), CORS musi być obsłużony ręcznie w każdej funkcji — lub, jeszcze lepiej, scentralizowany w jednym pliku pomocniczym. Oto poprawny wzorzec:
If you're using Supabase Edge Functions (Deno), CORS must be handled manually in each function — or, even better, centralized in a single helper file. Here's the correct pattern:
Om du använder Supabase Edge Functions (Deno) måste CORS hanteras manuellt i varje funktion — eller, ännu bättre, centraliseras i en enda hjälpfil. Här är det korrekta mönstret:
Hvis du bruker Supabase Edge Functions (Deno), må CORS håndteres manuelt i hver funksjon — eller, enda bedre, sentraliseres i en enkelt hjelpefil. Her er det korrekte mønsteret:
Jeden plik, jedno miejsce. Konfiguracja CORS powinna żyć w jednym miejscu w całym projekcie — nie rozproszona po każdym endpoincie i każdej funkcji. Stwórz plik cors.js (lub cors.ts) i importuj go wszędzie, gdzie jest potrzebny.
Jednocześnie zablokuj kształt odpowiedzi JSON — każdy endpoint powinien zwracać dane w tym samym formacie. Trzymaj plik wejściowy (entry file) jak najkrótszy — powinien tylko importować middleware i uruchamiać serwer. Cała logika biznesowa idzie do oddzielnych plików.
Dzięki temu, kiedy musisz zmienić dozwolone originy albo dodać nowy nagłówek, robisz to w jednym miejscu, a zmiana działa wszędzie. Brak centralizacji to jeden z głównych powodów, dla których aplikacje AI działają lokalnie, a padają na produkcji.
One file, one place. CORS configuration should live in one place across your entire project — not scattered across every endpoint and every function. Create a cors.js (or cors.ts) file and import it everywhere it's needed.
At the same time, lock down your JSON response shape — every endpoint should return data in the same format. Keep your entry file tiny — it should only import middleware and start the server. All business logic goes into separate files.
This way, when you need to change allowed origins or add a new header, you do it in one place, and the change works everywhere. Lack of centralization is one of the main reasons AI apps work locally but fail in production.
En fil, ett ställe. CORS-konfigurationen borde leva på ett ställe i hela ditt projekt — inte utspridd över varje endpoint och varje funktion. Skapa en cors.js (eller cors.ts) fil och importera den överallt där den behövs.
Samtidigt, lås fast JSON-svarsformatet — varje endpoint borde returnera data i samma format. Håll din ingångsfil liten — den borde bara importera middleware och starta servern. All affärslogik går i separata filer.
På så sätt, när du behöver ändra tillåtna origins eller lägga till en ny header, gör du det på ett ställe, och ändringen fungerar överallt. Brist på centralisering är en av huvudorsakerna till att AI-appar fungerar lokalt men misslyckas i produktion.
Én fil, ett sted. CORS-konfigurasjon bør leve på ett sted i hele prosjektet — ikke spredd over hvert endpoint og hver funksjon. Opprett en cors.js (eller cors.ts) fil og importer den overalt der den trengs.
Samtidig, lås fast JSON-svarsformatet — hvert endpoint bør returnere data i samme format. Hold inngangsfilen liten — den bør bare importere middleware og starte serveren. All forretningslogikk går i separate filer.
På denne måten, når du trenger å endre tillatte origins eller legge til en ny header, gjør du det på ett sted, og endringen fungerer overalt. Mangel på sentralisering er en av hovedgrunnene til at AI-apper fungerer lokalt men feiler i produksjon.
Czasami wszystko wygląda poprawnie, a CORS i tak nie działa. Oto najczęstsze pułapki:
https://mojaapka.com to nie to samo co https://www.mojaapka.com. Uważaj też na trailing slash — przeglądarka wysyła nagłówek Origin bez końcowego ukośnika, więc jeśli Twoja lista dozwolonych zawiera https://mojaapka.com/, porównanie stringów nie zadziała.no-cors w fetch: Jeśli ktoś (lub AI) dodał mode: 'no-cors' do zapytania fetch, przeglądarka nie wyrzuci błędu — ale odpowiedź będzie «opaque». Nie można odczytać statusu, nagłówków ani body. To nie jest naprawa — to zamiatanie pod dywan.http:// i https:// to różne originy. Jeśli Twój frontend jest na HTTPS, a backend na HTTP, CORS zablokuje zapytanie, a na dodatek przeglądarka może zablokować mixed content.Sometimes everything looks correct and CORS still doesn't work. Here are the most common traps:
https://myapp.com is not the same as https://www.myapp.com. Watch out for trailing slashes — the browser sends the Origin header without a trailing slash, so if your allowlist includes https://myapp.com/, the string comparison will fail.no-cors mode in fetch: If someone (or AI) added mode: 'no-cors' to a fetch request, the browser won't throw an error — but the response will be "opaque." You can't read the status, headers, or body. This isn't a fix — it's sweeping the problem under the rug.http:// and https:// are different origins. If your frontend is on HTTPS and your backend on HTTP, CORS will block the request, and on top of that the browser may block mixed content.Ibland ser allt korrekt ut och CORS fungerar ändå inte. Här är de vanligaste fällorna:
https://minapp.com är inte samma sak som https://www.minapp.com. Se upp med avslutande snedstreck — webbläsaren skickar Origin-headern utan avslutande snedstreck, så om din tillåtna lista innehåller https://minapp.com/ kommer strängjämförelsen att misslyckas.no-cors-läge i fetch: Om någon (eller AI) lade till mode: 'no-cors' i en fetch-förfrågan kastar webbläsaren inget fel — men svaret blir «opaque». Du kan inte läsa status, headers eller body. Det här är ingen fix — det är att sopa problemet under mattan.http:// och https:// är olika origins. Om din frontend är på HTTPS och din backend på HTTP blockerar CORS förfrågan, och dessutom kan webbläsaren blockera blandat innehåll.Noen ganger ser alt korrekt ut og CORS fungerer fortsatt ikke. Her er de vanligste fellene:
https://minapp.com er ikke det samme som https://www.minapp.com. Pass på avsluttende skråstrek — nettleseren sender Origin-headeren uten avsluttende skråstrek, så hvis den tillatte listen din inneholder https://minapp.com/, vil strengsammenligningen feile.no-cors-modus i fetch: Hvis noen (eller AI) la til mode: 'no-cors' i en fetch-forespørsel, kaster ikke nettleseren en feil — men svaret blir «opaque». Du kan ikke lese status, headere eller body. Dette er ingen fiks — det er å feie problemet under teppet.http:// og https:// er ulike origins. Hvis frontend er på HTTPS og backend på HTTP, blokkerer CORS forespørselen, og i tillegg kan nettleseren blokkere blandet innhold.Narzędzia AI do kodowania — Cursor, Claude Code, Copilot i inne — są niezwykle skuteczne w generowaniu kodu. Ale CORS to jeden z obszarów, w których konsekwentnie zawodzą. Dlaczego? Bo CORS to problem konfiguracyjny i architektoniczny, nie problem logiki kodu. AI świetnie pisze logikę. Źle rozumie kontekst wdrożeniowy.
Oto powtarzające się wzorce, które widzę u klientów:
* w produkcji — co nie tylko jest niebezpieczne, ale uniemożliwia użycie credentials (ciasteczek, tokenów) w zapytaniach.OPTIONS — co oznacza, że zapytania POST, PUT i DELETE będą blokowane przez przeglądarkę, nawet jeśli nagłówki CORS są ustawione poprawnie na zwykłych odpowiedziach.credentials: 'include' w fetch, serwer musi zwrócić Access-Control-Allow-Credentials: true i nie może używać wildcard * jako origin. AI prawie nigdy nie rozumie tej zależności.Najlepsza strategia: nie proś AI o naprawę CORS. Zrozum problem sam, napisz konfigurację ręcznie (albo użyj kodu z tego artykułu) i powiedz AI, żeby nie ruszało plików konfiguracyjnych.
AI coding tools — Cursor, Claude Code, Copilot, and others — are incredibly effective at generating code. But CORS is one area where they consistently fail. Why? Because CORS is a configuration and architecture problem, not a code logic problem. AI excels at writing logic. It poorly understands deployment context.
Here are the recurring patterns I see with clients:
* in production — which is not only dangerous but makes it impossible to use credentials (cookies, tokens) in requests.OPTIONS requests — which means POST, PUT, and DELETE requests will be blocked by the browser, even if CORS headers are set correctly on regular responses.credentials: 'include' in fetch, the server must return Access-Control-Allow-Credentials: true and cannot use the wildcard * as origin. AI almost never understands this dependency.The best strategy: don't ask AI to fix CORS. Understand the problem yourself, write the configuration manually (or use the code from this article), and tell AI to stay away from configuration files.
AI-kodverktyg — Cursor, Claude Code, Copilot och andra — är otroligt effektiva på att generera kod. Men CORS är ett område där de konsekvent misslyckas. Varför? Därför att CORS är ett konfigurations- och arkitekturproblem, inte ett kodlogikproblem. AI är utmärkt på att skriva logik. Den förstår driftsättningskontext dåligt.
Här är de återkommande mönstren jag ser hos kunder:
* i produktion — vilket inte bara är farligt utan gör det omöjligt att använda credentials (cookies, tokens) i förfrågningar.OPTIONS-förfrågningar — vilket innebär att POST-, PUT- och DELETE-förfrågningar blockeras av webbläsaren, även om CORS-headers är korrekt inställda på vanliga svar.credentials: 'include' i fetch måste servern returnera Access-Control-Allow-Credentials: true och kan inte använda wildcard * som origin. AI förstår nästan aldrig detta beroende.Den bästa strategin: be inte AI fixa CORS. Förstå problemet själv, skriv konfigurationen manuellt (eller använd koden från den här artikeln) och säg till AI att hålla sig borta från konfigurationsfiler.
AI-kodeverktøy — Cursor, Claude Code, Copilot og andre — er utrolig effektive til å generere kode. Men CORS er et område der de konsekvent feiler. Hvorfor? Fordi CORS er et konfigurasjons- og arkitekturproblem, ikke et kodelogikkproblem. AI er utmerket til å skrive logikk. Den forstår driftsettingskontekst dårlig.
Her er de gjentakende mønstrene jeg ser hos kunder:
* i produksjon — som ikke bare er farlig, men gjør det umulig å bruke credentials (cookies, tokens) i forespørsler.OPTIONS-forespørsler — noe som betyr at POST-, PUT- og DELETE-forespørsler blokkeres av nettleseren, selv om CORS-headere er satt riktig på vanlige svar.credentials: 'include' i fetch, må serveren returnere Access-Control-Allow-Credentials: true og kan ikke bruke wildcard * som origin. AI forstår nesten aldri denne avhengigheten.Den beste strategien: ikke be AI fikse CORS. Forstå problemet selv, skriv konfigurasjonen manuelt (eller bruk koden fra denne artikkelen), og si til AI at den skal holde seg unna konfigurasjonsfiler.
Zanim wdrożysz swoją aplikację, przejdź przez te punkty. Każdy z nich to potencjalne źródło błędów CORS na produkcji. Jeśli jeden jest niespełniony, aplikacja może się wysypać w sposób, który jest trudny do zdiagnozowania.
* w produkcji. Wymień każdą domenę, z której Twój frontend może wysyłać zapytania.Access-Control-Allow-Credentials: true i nie możesz używać wildcard origin.Before you deploy your application, go through these points. Each one is a potential source of CORS errors in production. If one is unmet, your app may break in ways that are hard to diagnose.
* in production. List every domain your frontend can send requests from.Access-Control-Allow-Credentials: true and you cannot use a wildcard origin.Innan du driftsätter din applikation, gå igenom dessa punkter. Var och en är en potentiell källa till CORS-fel i produktion. Om en inte är uppfylld kan din app gå sönder på sätt som är svåra att diagnostisera.
* i produktion. Lista varje domän din frontend kan skicka förfrågningar från.Access-Control-Allow-Credentials: true och du kan inte använda wildcard origin.Før du ruller ut applikasjonen din, gå gjennom disse punktene. Hver av dem er en potensiell kilde til CORS-feil i produksjon. Hvis en ikke er oppfylt, kan appen din gå i stykker på måter som er vanskelige å diagnostisere.
* i produksjon. List opp hvert domene frontend kan sende forespørsler fra.Access-Control-Allow-Credentials: true og du kan ikke bruke wildcard origin.Na localhost frontend i backend zwykle działają pod tym samym adresem (np. http://localhost:3000), więc przeglądarka traktuje to jako same-origin i nie stosuje reguł CORS. Po wdrożeniu frontend i backend są na różnych domenach — to jest cross-origin i przeglądarka zaczyna sprawdzać nagłówki CORS. Dodatkowo, wiele frameworków używa proxy w trybie deweloperskim, który maskuje cross-origin — ten proxy nie istnieje na produkcji.
On localhost, your frontend and backend usually run at the same address (e.g., http://localhost:3000), so the browser treats this as same-origin and doesn't apply CORS rules. After deployment, frontend and backend are on different domains — that's cross-origin and the browser starts checking for CORS headers. Additionally, many frameworks use a dev proxy that masks cross-origin — that proxy doesn't exist in production.
På localhost kör frontend och backend vanligtvis på samma adress (t.ex. http://localhost:3000), så webbläsaren behandlar det som same-origin och tillämpar inte CORS-regler. Efter driftsättning är frontend och backend på olika domäner — det är cross-origin och webbläsaren börjar kontrollera CORS-headers. Dessutom använder många ramverk en dev-proxy som maskerar cross-origin — den proxyn finns inte i produktion.
På localhost kjører frontend og backend vanligvis på samme adresse (f.eks. http://localhost:3000), så nettleseren behandler det som same-origin og anvender ikke CORS-regler. Etter utrulling er frontend og backend på ulike domener — det er cross-origin og nettleseren begynner å sjekke CORS-headere. I tillegg bruker mange rammeverk en dev-proxy som maskerer cross-origin — den proxyen finnes ikke i produksjon.
Tylko dla w pełni publicznych API, które nie wymagają uwierzytelniania — np. publiczne dane pogodowe czy kursy walut. W każdym innym przypadku używaj listy konkretnych domen. Pamiętaj: wildcard * i Access-Control-Allow-Credentials: true nie mogą istnieć razem. Przeglądarka odrzuci odpowiedź. Jeśli Twoja aplikacja używa ciasteczek, tokenów JWT lub jakiejkolwiek formy sesji, wildcard nie jest opcją.
Only for fully public APIs that don't require authentication — e.g., public weather data or exchange rates. In every other case, use a list of specific domains. Remember: the wildcard * and Access-Control-Allow-Credentials: true cannot coexist. The browser will reject the response. If your application uses cookies, JWT tokens, or any form of session, the wildcard is not an option.
Bara för helt publika API:er som inte kräver autentisering — t.ex. publika väderdata eller växelkurser. I alla andra fall, använd en lista med specifika domäner. Kom ihåg: wildcard * och Access-Control-Allow-Credentials: true kan inte samexistera. Webbläsaren avvisar svaret. Om din applikation använder cookies, JWT-tokens eller någon form av session är wildcard inte ett alternativ.
Bare for helt offentlige API-er som ikke krever autentisering — f.eks. offentlige værdata eller valutakurser. I alle andre tilfeller, bruk en liste med spesifikke domener. Husk: wildcard * og Access-Control-Allow-Credentials: true kan ikke eksistere sammen. Nettleseren avviser svaret. Hvis applikasjonen din bruker cookies, JWT-tokens eller noen form for sesjon, er wildcard ikke et alternativ.
CORS to konfiguracja backendu, która jest wyzwalana przez frontend. Błąd pojawia się w przeglądarce (frontend), ale rozwiązanie leży na serwerze (backend). Serwer musi zwrócić właściwe nagłówki Access-Control-Allow-*, żeby przeglądarka pozwoliła na zapytanie. Nie da się «naprawić CORS» samymi zmianami w kodzie frontendu — jedyne, co można zrobić po stronie klienta, to ukryć problem (np. mode: 'no-cors'), co jest gorszą opcją.
CORS is a backend configuration triggered by the frontend. The error appears in the browser (frontend), but the fix is on the server (backend). The server must return proper Access-Control-Allow-* headers for the browser to allow the request. You cannot "fix CORS" with frontend code changes alone — the only thing you can do on the client side is hide the problem (e.g., mode: 'no-cors'), which is worse.
CORS är en backendkonfiguration som utlöses av frontend. Felet dyker upp i webbläsaren (frontend), men lösningen finns på servern (backend). Servern måste returnera korrekta Access-Control-Allow-*-headers för att webbläsaren ska tillåta förfrågan. Du kan inte «fixa CORS» enbart med ändringar i frontendkoden — det enda du kan göra på klientsidan är att dölja problemet (t.ex. mode: 'no-cors'), vilket är värre.
CORS er en backendkonfigurasjon som utløses av frontend. Feilen vises i nettleseren (frontend), men løsningen ligger på serveren (backend). Serveren må returnere riktige Access-Control-Allow-*-headere for at nettleseren skal tillate forespørselen. Du kan ikke «fikse CORS» med bare frontendkodeendringer — det eneste du kan gjøre på klientsiden er å skjule problemet (f.eks. mode: 'no-cors'), noe som er verre.
Postman nie jest przeglądarką. Przeglądarki wymuszają CORS — klienty API tego nie robią. Postman, curl, Insomnia, requesty z serwera — żadne z nich nie wysyła zapytań preflight ani nie sprawdza nagłówków Access-Control-Allow-Origin. To czysty mechanizm przeglądarkowy. Jeżeli Twoje API działa w Postmanie, ale nie w przeglądarce, to 100% problem z konfiguracją CORS na serwerze — nie z samym API.
Postman is not a browser. Browsers enforce CORS — API clients don't. Postman, curl, Insomnia, server-to-server requests — none of them send preflight requests or check Access-Control-Allow-Origin headers. It's a pure browser mechanism. If your API works in Postman but not in the browser, it's 100% a CORS configuration issue on the server — not the API itself.
Postman är inte en webbläsare. Webbläsare tillämpar CORS — API-klienter gör det inte. Postman, curl, Insomnia, server-till-server-förfrågningar — ingen av dem skickar preflight-förfrågningar eller kontrollerar Access-Control-Allow-Origin-headers. Det är en ren webbläsarmekanism. Om ditt API fungerar i Postman men inte i webbläsaren är det 100% ett CORS-konfigurationsproblem på servern — inte själva API:et.
Postman er ikke en nettleser. Nettlesere håndhever CORS — API-klienter gjør det ikke. Postman, curl, Insomnia, server-til-server-forespørsler — ingen av dem sender preflight-forespørsler eller sjekker Access-Control-Allow-Origin-headere. Det er en ren nettlesermekanisme. Hvis API-et ditt fungerer i Postman men ikke i nettleseren, er det 100% et CORS-konfigurasjonsproblem på serveren — ikke selve API-et.
To jest właśnie kaskada CORS. AI nie rozumie kontekstu Twojego projektu. Kiedy prosisz je o naprawę CORS, często modyfikuje pliki, które nie powinny być ruszone — zmienia importy, modyfikuje kształt odpowiedzi, przepisuje middleware. Każda kolejna poprawka pogarsza sytuację. Rozwiązanie: cofnij się do stanu sprzed «naprawy» AI (użyj git), zrozum problem CORS używając tego artykułu, i napisz konfigurację ręcznie. Nie pozwalaj AI edytować plików konfiguracyjnych CORS.
This is the CORS cascade. AI doesn't understand your project's context. When you ask it to fix CORS, it often modifies files that shouldn't be touched — changes imports, modifies response shapes, rewrites middleware. Each successive fix makes things worse. The solution: roll back to the state before AI's "fix" (use git), understand the CORS problem using this article, and write the configuration manually. Don't let AI edit CORS configuration files.
Det här är CORS-kaskaden. AI förstår inte ditt projekts kontext. När du ber den fixa CORS ändrar den ofta filer som inte borde röras — ändrar importer, modifierar svarsformat, skriver om middleware. Varje ny fix gör saken värre. Lösningen: rulla tillbaka till tillståndet före AI:s «fix» (använd git), förstå CORS-problemet med hjälp av den här artikeln, och skriv konfigurationen manuellt. Låt inte AI redigera CORS-konfigurationsfiler.
Dette er CORS-kaskaden. AI forstår ikke prosjektets kontekst. Når du ber den fikse CORS, endrer den ofte filer som ikke bør røres — endrer importer, modifiserer svarsformater, skriver om middleware. Hver nye fiks gjør ting verre. Løsningen: rull tilbake til tilstanden før AI-ens «fiks» (bruk git), forstå CORS-problemet ved hjelp av denne artikkelen, og skriv konfigurasjonen manuelt. Ikke la AI redigere CORS-konfigurasjonsfiler.
Błędy CORS to często tylko wierzchołek góry lodowej. Jeśli Twoja aplikacja AI ma problemy po wdrożeniu, porozmawiajmy — pomożemy Ci przejść od prototypu do produkcji. CORS errors are often just the tip of the iceberg. If your AI app has issues after deployment, let's talk — we'll help you get from prototype to production. CORS-fel är ofta bara toppen av isberget. Om din AI-app har problem efter driftsättning, låt oss prata — vi hjälper dig från prototyp till produktion. CORS-feil er ofte bare toppen av isfjellet. Hvis AI-appen din har problemer etter utrulling, la oss snakke — vi hjelper deg fra prototype til produksjon.
Zarezerwuj bezpłatną rozmowę → Book a free call → Boka ett gratis samtal → Bestill en gratis samtale →