Why does my app work on localhost but get CORS errors in production?

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.

Should I use Access-Control-Allow-Origin: * ?

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.

Is CORS a frontend or backend problem?

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.

Why does Postman work but my browser doesn't?

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.

My AI fixed CORS but now other things are broken

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.

Slik fikser du CORS-feil i AI-genererte apper

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.

Hva CORS egentlig er

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

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.

CORS-kaskaden: slik gjør AI det verre

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:

Legger til Access-Control-Allow-Origin: * overalt — et wildcard i stedet for spesifikke domener. Farlig i produksjon.
Håndterer ikke OPTIONS-forespørsler — preflight-forespørselen forblir ubesvart, så nettleseren blokkerer alt.
Legger til 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.
Endrer fungerende kode mens den prøver å fikse noe den ikke forstår — det er kaskaden.

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.

CORS-kaskaden

Å 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.

Steg-for-steg-fiks

Steg 1: Sjekk den virkelige feilen

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.

Steg 2: Riktig måte å konfigurere CORS på (Express.js)

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:

✓ Korrekt CORS-konfigurasjon

cors-middleware.js

const allowedOrigins = ['https://yourapp.com', 'https://app.yourapp.com'];

function corsMiddleware(req, res, next) {
  const origin = req.headers.origin;
  if (allowedOrigins.includes(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
    res.setHeader('Access-Control-Allow-Methods',
      'GET, POST, PUT, DELETE, OPTIONS');
    res.setHeader('Access-Control-Allow-Headers',
      'Content-Type, Authorization');
    res.setHeader('Access-Control-Allow-Credentials',
      'true');
  }
  if (req.method === 'OPTIONS')
    return res.status(204).end();
  next();
}

Steg 3: Hva AI genererer (feil)

Og her er hva AI vanligvis genererer når du ber den «fikse CORS». Det ser enkelt ut, men er fullt av problemer:

✗ Hva AI genererer

server.js

app.use((req, res, next) => {
res.header('Access-Control-Allow-Origin', '*');
next();
});
// No OPTIONS handling
// Wildcard in production
// No credentials support
// No Allow-Methods or Allow-Headers

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.

Steg 4: CORS i Supabase Edge Functions

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:

✓ Supabase Edge Function med CORS

supabase/functions/my-function/index.ts

Steg 5: Sentraliser CORS-konfigurasjonen

É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.

Steg 6: Feilsøk vanskelige tilfeller

Noen ganger ser alt korrekt ut og CORS fungerer fortsatt ikke. Her er de vanligste fellene:

URL-avvik: 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.
Blanding av HTTP og HTTPS: 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.
Dev-proxy vs. produksjon: Mange rammeverk (React, Vue, Next.js) bruker en proxy i utviklingsmodus som maskerer cross-origin-forespørsler. I produksjon finnes ikke den proxyen — og plutselig eksploderer CORS. Det er derfor CORS-feil bare dukker opp etter utrulling.

Hva AI-verktøy gjør feil med CORS

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:

AI redigerer serverkode når den bare bør røre frontend — og omvendt. Den forstår ikke hvilken kode som kjører hvor. Den foreslår ofte endringer på begge sider, noe som skaper inkonsekvenser.
AI bruker wildcard * i produksjon — som ikke bare er farlig, men gjør det umulig å bruke credentials (cookies, tokens) i forespørsler.
AI håndterer ikke preflight 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.
AI vet ikke om credentials-modus — når du bruker 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.
Folk fortsetter å prompte i stedet for å fikse strukturen — når CORS ikke fungerer, er den naturlige refleksen «fiks dette». Men hver nye prompt uten forståelse for problemet genererer mer kode som maskerer i stedet for å løse problemet. Det er kaskaden jeg beskrev over.

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.

Produksjonsklar CORS-sjekkliste

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.

✓Spesifikke tillatte origins. Bruk aldri * i produksjon. List opp hvert domene frontend kan sende forespørsler fra.
✓Håndter OPTIONS-preflight eksplisitt. Hvert endpoint må svare på preflight med status 204 og riktige CORS-headere. Uten dette går POST/PUT/DELETE ikke gjennom.
✓Sett Allow-Methods og Allow-Headers. Nettleseren sjekker om metoden og headerne du bruker er tillatt. Hvis du ikke lister dem, blokkeres forespørselen.
✓Håndter credentials riktig. Hvis du bruker cookies eller tokens, må du sette Access-Control-Allow-Credentials: true og du kan ikke bruke wildcard origin.
✓Sentraliser CORS i en hjelpefil. En endring, ett sted. Ikke spre konfigurasjon over filer.
✓Test med utrullet frontend, ikke bare localhost. CORS oppfører seg annerledes på localhost. Test fra det virkelige domenet etter hver utrulling.
✓5xx-feil returnerer også CORS-headere. Hvis feilhåndleren din ikke legger til CORS-headere, vil hver serverfeil se ut som en CORS-feil i nettleseren.
✓Ingen URL-avvik. Sjekk avsluttende skråstrek, www vs. ikke-www, http vs. https. Hvert avvik er en annen origin.
✓Strukturert logging for CORS-feil. Logg avviste forespørsler med origin, metode og headere. Uten det er feilsøking i produksjon gjetting.
✓Selvtest etter hver utrulling. Et enkelt skript som sender en cross-origin-forespørsel til API-et ditt og verifiserer at svaret inneholder riktige CORS-headere.

Ofte stilte spørsmål

Hvorfor fungerer appen min på localhost, men får CORS-feil i produksjon?

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.

Bør jeg bruke Access-Control-Allow-Origin: * ?

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.

Er CORS et frontend- eller backendproblem?

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.

Hvorfor fungerer Postman, men ikke nettleseren min?

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.

AI-en min fikset CORS, men nå er andre ting ødelagt

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.