Slik fikser du manglende CORS-header Access-Control-Allow-Origin i Express.js

Hvis en nettleser sier CORS header 'Access-Control-Allow-Origin' missing, er den viktige ledetråden ikke at Express.js mislyktes i å motta forespørselen. Nettleseren forteller deg at svaret ikke inkluderte en CORS-header som autoriserte sidens opprinnelse til å lese det svaret. Fiksen hører derfor hjemme på serveren eller en proxy du kontrollerer, ikke i en tilfeldig klientinnstilling.

Illustrerende eksempel brukt gjennom hele denne veiledningen: forestill deg et oppgavedashboard som kjører på http://localhost:5173 som kaller et Express API på http://localhost:3000/api/tasks. Nettleseren blokkerer JavaScript fra å lese API-svaret fordi API-et ikke returnerer Access-Control-Allow-Origin. Dette er et hypotetisk undervisningseksempel, ikke en påstand om en reell test, et produkt eller en utrulling.

Som sjekket den 11. september 2026, lister den offisielle Express CORS-middleware-dokumentasjonen cors versjon 2.8.6 og beskriver den som middleware som setter CORS-svarheaders. Den gjeldende Express-pakkelisten er i 5.x-generasjonen, så denne veiledningen foretrekker applikasjonsnivå-middleware i stedet for å stole på eldre wildcard-rutemønstre.

Hva feilen faktisk betyr

En nettside har en opprinnelse (origin) dannet av dens skjema, vert og port. I eksemplet er http://localhost:5173 og http://localhost:3000 ulike opprinnelser fordi portene deres er ulike. Nettleserens policy for samme opprinnelse forhindrer normalt JavaScript på én opprinnelse fra å lese ressurser fra en annen med mindre målserveren returnerer passende Cross-Origin Resource Sharing (CORS)-headers.

MDNs dokumentasjon for denne nøyaktige feilen forklarer at svaret mangler den påkrevde Access-Control-Allow-Origin-headeren. Hvis du kontrollerer serveren, bør du konfigurere den forespørrende sidens opprinnelse som en tillatt opprinnelse. For offentlige, ikke-kredensierte API-er kan * være passende; for private eller kredensierte API-er, bruk spesifikke tillitte opprinnelser i stedet. Se MDNs forklaring av manglende Access-Control-Allow-Origin-feil.

Steg 1: Bekreft at CORS er problemet og identifiser den nøyaktige opprinnelsen

Åpne nettleserens utviklerverktøy og sjekk både Konsoll- og Nettverk-panelene. Registrer frontend-opprinnelsen nøyaktig slik nettleseren sender den. I vårt illustrerende tilfelle er det http://localhost:5173.

Reduser ikke en opprinnelse til bare et vertsnavn. Dette er ulike opprinnelser: http://localhost:5173, http://localhost:3000, http://127.0.0.1:5173 og https://localhost:5173. En produksjonstillatelsesliste må også skille mellom https://app.example.com og andre skjemaer, verter, porter eller underdomener med mindre du bevisst tillater dem.

Hvis API-svaret er en 404, 500, omdirigering, autentiseringsfeil eller en proxy-generert feilside, inspiser også det svaret. CORS-headers må være til stede på svaret nettleseren faktisk mottar. Å fikse en applikasjonsrute vil ikke hjelpe hvis en omvendt proxy, CDN, lastbalanser eller feilhåndterer returnerer et annet svar uten headeren.

Steg 2: Installer og last den offisielle Express CORS-middleware

For de fleste Express-applikasjoner er den minst feilutsatte løsningen cors-middlewareen vedlikeholdt av Express-prosjektet. Den offisielle Express-middleware-siden lister den blant middleware vedlikeholdt av Express.js-teamet. Installer den i API-prosjektet ditt:

npm install cors

Last den deretter inn ved siden av Express:

const express = require('express');
const cors = require('cors');

const app = express();

Den offisielle dokumentasjonen er tilgjengelig på Express.js cors middleware-dokumentasjon. Express dokumenterer også hvordan applikasjonsnivå-middleware kjører i forespørselsrekkefølge på Express.js: Bruk av middleware.

Steg 3: Tillat frontend-opprinnelsen bevisst

For det hypotetiske dashboardet, konfigurer den nøyaktige utviklingsopprinnelsen før rutene som trenger CORS:

const express = require('express');
const cors = require('cors');

const app = express();

const corsOptions = {
  origin: 'http://localhost:5173'
};

app.use(cors(corsOptions));
app.use(express.json());

app.get('/api/tasks', (req, res) => {
  res.json({ tasks: ['Lær Express', 'Bygg API'] });
});

app.listen(3000);

Å sette app.use(cors(corsOptions)) før API-rutene er viktig fordi Express behandler middleware i rekkefølge. Middlewareen trenger en sjanse til å legge til svar-headers før en rute eller tidligere middleware avslutter forespørselen.

For et virkelig offentlig API som ikke bruker legitimasjon, bruker app.use(cors()) middlewareens standard tillatelige opprinnelsesatferd. Det er praktisk, men det bør ikke være ditt automatiske produksjonsvalg. MDN anbefaler å begrense Access-Control-Allow-Origin til de minste opprinnelsene og ressursene som trengs. Se MDNs CORS-sikkerhetsveiledning.

Tillat flere kjente opprinnelser uten å tillate alle

En vanlig produksjonsoppsett har en lokal frontend, en staging-frontend og en produksjonsfrontend. Bruk en tillatelsesliste og valider den innkommende opprinnelsen:

const allowedOrigins = new Set([
  'http://localhost:5173',
  'https://staging.example.com',
  'https://app.example.com'
]);

const corsOptions = {
  origin(origin, callback) {
    if (!origin || allowedOrigins.has(origin)) {
      callback(null, true);
      return;
    }
    callback(new Error('Origin not allowed by CORS'));
  }
};

app.use(cors(corsOptions));

!origin-grenen tillater klienter som ikke sender en Origin-header, som mange server-til-server-forespørsler og kommandolinjeverktøy. Om du ønsker den atferden er et applikasjonspolitikkvalg; CORS i seg selv er ikke autentisering.

Steg 4: Verifiser den enkle forespørselen og eventuell preflight

Last inn frontenden på nytt og inspiser Nettverk-panelet. Suksessbetingelsen er ikke bare en 200-status. Sjekk svar-headerne. I vårt illustrerende tilfelle bør API-svaret inkludere en opprinnelsesverdi tilsvarende:

Access-Control-Allow-Origin: http://localhost:5173

Noen kryssopprinnelsesforespørsler utløser en preflight: nettleseren sender en OPTIONS-forespørsel før den virkelige forespørselen for å sjekke om metoden og headerne er tillatt. Forespørsler som bruker metoder som PUT eller DELETE, eller visse egendefinerte/forespørselsheaders, trenger vanligvis preflight. Når cors er installert som applikasjonsnivå-middleware med app.use(cors(...)), sier den offisielle Express-dokumentasjonen at preflight-forespørsler håndteres for alle ruter.

Du kan også inspisere headers utenfor nettleseren uten å påstå at kommandolinjeklienten håndhever CORS:

curl -i   -H "Origin: http://localhost:5173"   http://localhost:3000/api/tasks

Dette er nyttig for å se hva serveren returnerer, men en vellykket curl- eller API-klientforespørsel beviser ikke at nettleser-CORS er konfigurert riktig. Express' CORS-dokumentasjon merker eksplisitt at CORS håndheves av nettlesere; ikke-nettleserklienter anvender ikke den samme lesebegrensningen.

Kredensierte forespørsler: ikke kombiner legitimasjon med en wildcard-opprinnelse

Hvis frontenden må sende informasjonskapsler eller HTTP-autentisering på tvers av opprinnelser, trenger begge sider kompatible innstillinger. På Express-siden, konfigurer en spesifikk tillitt opprinnelse og aktiver legitimasjon:

app.use(cors({
  origin: 'https://app.example.com',
  credentials: true
}));

På nettlesersiden bruker en fetch-forespørsel som trenger informasjonskapsler typisk credentials: 'include'. Bytt ikke serveropprinnelsen til * for en kredensiert forespørsel. Nettlesere aksepterer ikke en wildcard Access-Control-Allow-Origin sammen med kredensiert CORS på den måten utviklere ofte forventer, og en ubegrenset opprinnelse ville også være en dårlig sikkerhetsgrense.

Hvorfor vanlige “fikser” feiler

Når Express-koden ser riktig ut, men feilen vedvarer

Hvis de fire stegene ovenfor ikke løser feilen, spor hele forespørselsbanen i stedet for å legge til flere headers blindt.

• Sjekk middleware-rekkefølgen. CORS-middleware bør kjøre før ruter eller håndterere som avslutter svaret.
• Sjekk omdirigeringer. Nettleseren kan motta et svar fra en annen URL eller opprinnelse etter en omdirigering.
• Sjekk proxy/CDN-atferd. Nginx, en gateway, en serverløs plattform eller en CDN kan legge til, fjerne, duplisere eller erstatte headers.
• Sjekk feilsvar. Et normalt 200-svar kan inneholde CORS-headers mens et 401-, 404- eller 500-svar ikke gjør det.
• Sjekk den bokstavelige opprinnelsen. Skjema, vertsnavn og port betyr alle noe; localhost og 127.0.0.1 er ikke utbyttbare for CORS-matching.
• Sjekk for duplikate headers. MDN dokumenterer at flere Access-Control-Allow-Origin-headers ikke er tillatt. Se MDN om flere Access-Control-Allow-Origin-headers.

Manuelle headers versus cors-middleware

Du kan sette CORS-headers manuelt med Express-svar-API-er, men det er lett å gå glipp av preflight-atferd, legitimasjonsregler, dynamisk opprinnelsesmatching, Vary: Origin eller feilstier. Den offisielle cors-middlewareen eksponerer allerede alternativer for origin, metoder, tillatte headers, eksponerte headers, legitimasjon, preflight-atferd og maks alder. For de fleste Express-prosjekter holder bruk av den middlewareen policyen eksplisitt og lettere å gjennomgå.

Hvis du implementerer dynamisk opprinnelseslogikk selv, reflekter aldri hver innkommende Origin-verdi automatisk bare fordi den er til stede. Valider den mot et tillitt sett. MDN advarer om at ubegrensede kryssopprinnelseslesinger kan eksponere data, spesielt når legitimasjon er involvert.

En praktisk produksjonssjekkliste

• List de nøyaktige frontend-opprinnelsene som skal kunne lese API-et.
• Bruk HTTPS-opprinnelser i produksjon og hold utviklingsopprinnelser separate.
• Installer CORS-middleware før beskyttede API-ruter som trenger det.
• Bruk spesifikke opprinnelser for private eller kredensierte endepunkter.
• Verifiser både normale svar og preflight OPTIONS-svar i nettleseren.
• Verifiser feilstier som 401-, 404- og 500-svar hvis de kan returneres på tvers av opprinnelser.
• Behandle CORS som en nettleserlespolicy, ikke som autentisering eller autorisasjon.

I det illustrerende oppgavedashboard-scenariet er den varige fiksen enkel: identifiser frontends nøyaktige opprinnelse, konfigurer Express til å returnere den matchende CORS-headeren, la applikasjonsnivå-middleware håndtere preflight, og verifiser headerne på svaret nettleseren faktisk mottar. Hvis headeren fortsatt mangler etter det, er den neste mistenkte vanligvis middleware-rekkefølgen eller infrastrukturen mellom nettleseren og Express, ikke selve frontend fetch-kallet.

Offisielle referanser

• Express.js cors middleware-dokumentasjon — konfigurasjonsalternativer, dynamiske opprinnelser, legitimasjon og preflight-atferd.
• Express.js middleware-veiledning — applikasjonsmiddleware og forespørselsbehandlingsrekkefølge.
• MDN: CORS header Access-Control-Allow-Origin missing — betydningen av denne spesifikke nettleserfeilen.
• MDN CORS sikkerhetskonfigurasjonsveiledning — veiledning om å begrense tillatte opprinnelser og håndtere kredensiert tilgang.