Sådan løser du manglende CORS-header Access-Control-Allow-Origin i Express.js

Hvis en browser viser CORS header 'Access-Control-Allow-Origin' missing, er den vigtige ledetråd ikke, at Express.js ikke modtog anmodningen. Browseren fortæller dig, at svaret ikke indeholdt en CORS-header, der godkender sidens oprindelse til at læse svaret. Løsningen hører derfor til på serveren eller en proxy, du kontrollerer, ikke i en tilfældig klient-side-indstilling.

Illustrerende eksempel brugt gennem hele denne guide: forestil dig et opgavedashboard, der kører på http://localhost:5173, som kalder et Express-API på http://localhost:3000/api/tasks. Browseren blokerer JavaScript fra at læse API-svaret, fordi API'en ikke returnerer Access-Control-Allow-Origin. Dette er et hypotetisk undervisningseksempel, ikke en påstand om en reel test, et produkt eller en implementering.

Som tjekket den 11. september 2026, lister den officielle Express CORS-middleware-dokumentation cors version 2.8.6 og beskriver den som middleware, der indstiller CORS-svarheaders. Den nuværende Express-pakkeliste er i 5.x-generationen, så denne guide foretrækker applikationsniveau-middleware i stedet for at stole på ældre wildcard-rutemønstre.

Hvad fejlen faktisk betyder

En webside har en oprindelse (origin) dannet af dens skema, host og port. I eksemplet er http://localhost:5173 og http://localhost:3000 forskellige oprindelser, fordi deres porte er forskellige. Browserens same-origin-politik forhindrer normalt JavaScript på én oprindelse i at læse ressourcer fra en anden, medmindre målserveren returnerer passende Cross-Origin Resource Sharing (CORS)-headers.

MDN's dokumentation for denne præcise fejl forklarer, at svaret mangler den påkrævede Access-Control-Allow-Origin-header. Hvis du kontrollerer serveren, skal du konfigurere den anmodende sides oprindelse som en tilladt oprindelse. For offentlige, ikke-credentialed API'er kan * være passende; for private eller credentialed API'er skal du bruge specifikke betroede oprindelser i stedet. Se MDN's forklaring af den manglende Access-Control-Allow-Origin-fejl.

Trin 1: Bekræft at CORS er problemet, og identificer den præcise oprindelse

Åbn browserens udviklerværktøjer og tjek både Konsol- og Netværkspanelerne. Registrér frontend-oprindelsen præcist, som browseren sender den. I vores illustrerende tilfælde er det http://localhost:5173.

Reducer ikke en oprindelse til kun et værtsnavn. Disse er forskellige oprindelser: http://localhost:5173, http://localhost:3000, http://127.0.0.1:5173 og https://localhost:5173. En produktions-allowlist skal ligeledes skelne mellem https://app.example.com og andre skemaer, værter, porte eller underdomæner, medmindre du bevidst tillader dem.

Hvis API-svaret er en 404, 500, omdirigering, godkendelsesfejl eller en proxy-genereret fejlside, skal du også inspicere dette svar. CORS-headers skal være til stede på det svar, browseren faktisk modtager. Det hjælper ikke at fikse en applikationsrute, hvis en reverse proxy, CDN, load balancer eller fejlhåndterer returnerer et andet svar uden headeren.

Trin 2: Installer og indlæs den officielle Express CORS-middleware

For de fleste Express-applikationer er den mindst fejlbehæftede løsning cors-middlewareen vedligeholdt af Express-projektet. Den officielle Express-middleware-side lister den blandt middleware vedligeholdt af Express.js-teamet. Installer den i dit API-projekt:

npm install cors

Indlæs den derefter ved siden af Express:

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

const app = express();

Den officielle dokumentation er tilgængelig på Express.js cors middleware-dokumentation. Express dokumenterer også, hvordan applikationsniveau-middleware kører i anmodningsrækkefølge på Express.js: Brug af middleware.

Trin 3: Tillad frontend-oprindelsen bevidst

Konfigurer den præcise udviklingsoprindelse før de ruter, der har brug for CORS, for det hypotetiske dashboard:

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: ['Learn Express', 'Build API'] });
});

app.listen(3000);

Det er vigtigt at placere app.use(cors(corsOptions)) før API-ruterne, fordi Express behandler middleware i rækkefølge. Middlewareen skal have en chance for at tilføje svar-headers, før en rute eller tidligere middleware afslutter anmodningen.

For et virkelig offentligt API, der ikke bruger credentials, bruger app.use(cors()) middlewareens standard adfærd for permissive origin. Det er praktisk, men det bør ikke være dit automatiske produktionsvalg. MDN anbefaler at begrænse Access-Control-Allow-Origin til de mindst nødvendige oprindelser og ressourcer. Se MDN's CORS-sikkerhedsvejledning.

Tillad flere kendte oprindelser uden at tillade alle

En almindelig produktionsopsætning har en lokal frontend, en staging-frontend og en produktions-frontend. Brug en allowlist og valider den indkommende oprindelse:

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 tillader klienter, der ikke sender en Origin-header, såsom mange server-til-server-anmodninger og kommandolinjeværktøjer. Om du ønsker denne adfærd, er et applikationspolitikvalg; CORS er i sig selv ikke godkendelse.

Trin 4: Verificér den simple anmodning og eventuel preflight

Genindlæs frontend og inspicer Netværkspanelet. Succesbetingelsen er ikke blot en 200-status. Tjek svar-headers. I vores illustrerende tilfælde skal API-svaret indeholde en oprindelsesværdi svarende til:

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

Nogle cross-origin-anmodninger udløser en preflight: browseren sender en OPTIONS-anmodning før den reelle anmodning for at tjekke, om metoden og headers er tilladt. Anmodninger, der bruger metoder som PUT eller DELETE, eller visse brugerdefinerede/anmodnings-headers, kræver ofte preflight. Når cors er installeret som applikationsniveau-middleware med app.use(cors(...)), siger den officielle Express-dokumentation, at preflight-anmodninger håndteres for alle ruter.

Du kan også inspicere headers uden for browseren uden at påstå, at kommandolinjeklienten håndhæver CORS:

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

Dette er nyttigt for at se, hvad serveren returnerer, men en vellykket curl- eller API-klientanmodning beviser ikke, at browser-CORS er konfigureret korrekt. Express' CORS-dokumentation bemærker eksplicit, at CORS håndhæves af browsere; ikke-browserklienter anvender ikke den samme læsebegrænsning.

Credentialed anmodninger: kombiner ikke credentials med en wildcard-oprindelse

Hvis frontend skal sende cookies eller HTTP-godkendelse cross-origin, skal begge sider have kompatible indstillinger. På Express-siden skal du konfigurere en specifik betroet oprindelse og aktivere credentials:

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

På browsersiden bruger en fetch-anmodning, der har brug for cookies, typisk credentials: 'include'. Skift ikke serveropprindelsen til * for en credentialed anmodning. Browsere accepterer ikke en wildcard Access-Control-Allow-Origin sammen med credentialed CORS på den måde, udviklere ofte forventer, og en ubegrænset oprindelse ville også være en dårlig sikkerhedsgrænse.

Hvorfor almindelige “løsninger” fejler

Når Express-koden ser korrekt ud, men fejlen vedvarer

Hvis de fire ovenstående trin ikke løser fejlen, så spor hele anmodningsstien i stedet for blindt at tilføje flere headers.

• Tjek middleware-rækkefølgen. CORS-middleware skal køre før ruter eller håndterere, der afslutter svaret.
• Tjek omdirigeringer. Browseren modtager måske et svar fra en anden URL eller oprindelse efter en omdirigering.
• Tjek proxy/CDN-adfærd. Nginx, en gateway, en serverløs platform eller en CDN kan tilføje, fjerne, duplikere eller erstatte headers.
• Tjek fejl-svar. Et normalt 200-svar kan indeholde CORS-headers, mens et 401-, 404- eller 500-svar ikke gør.
• Tjek den bogstavelige oprindelse. Skema, værtsnavn og port betyder alle noget; localhost og 127.0.0.1 er ikke udskiftelige for CORS-matching.
• Tjek for duplikerede headers. MDN dokumenterer, at flere Access-Control-Allow-Origin-headers ikke er tilladt. Se MDN om flere Access-Control-Allow-Origin-headers.

Manuelle headers versus cors-middleware

Du kan indstille CORS-headers manuelt med Express-svar-API'er, men det er let at overse preflight-adfærd, credential-regler, dynamisk oprindelsesmatching, Vary: Origin eller fejl-stier. Den officielle cors-middleware eksponerer allerede muligheder for origin, metoder, tilladte headers, eksponerede headers, credentials, preflight-adfærd og max age. For de fleste Express-projekter holder brugen af den middleware politikken eksplicit og lettere at gennemgå.

Hvis du implementerer dynamisk oprindelseslogik selv, skal du aldrig automatisk reflektere hver indkommende Origin-værdi, bare fordi den er til stede. Valider den mod et betroet sæt. MDN advarer om, at ubegrænsede cross-origin-læsninger kan eksponere data, især når credentials er involveret.

En praktisk produktions-tjekliste

• List de præcise frontend-oprindelser, der skal kunne læse API'en.
• Brug HTTPS-oprindelser i produktion og hold udviklingsoprindelser separate.
• Installer CORS-middleware før beskyttede API-ruter, der har brug for det.
• Brug specifikke oprindelser for private eller credentialed endpoints.
• Verificér både normale svar og preflight OPTIONS-svar i browseren.
• Verificér fejl-stier som 401-, 404- og 500-svar, hvis de kan returneres cross-origin.
• Behandl CORS som en browser-læsepolitik, ikke som godkendelse eller autorisation.

I det illustrerende opgavedashboard-scenarie er den holdbare løsning ligetil: identificér frontendens præcise oprindelse, konfigurer Express til at returnere den matchende CORS-header, lad applikationsniveau-middleware håndtere preflight, og verificér headers på det svar, browseren faktisk modtager. Hvis headeren stadig mangler efter det, er den næste mistænkte normalt middleware-rækkefølgen eller infrastrukturen mellem browseren og Express, ikke selve frontend fetch-kaldet.

Officielle referencer

• Express.js cors middleware-dokumentation — konfigurationsmuligheder, dynamiske oprindelser, credentials og preflight-adfærd.
• Express.js middleware-guide — applikationsmiddleware og anmodningsbehandlingsrækkefølge.
• MDN: CORS header Access-Control-Allow-Origin mangler — betydningen af denne specifikke browserfejl.
• MDN CORS-sikkerhedskonfigurationsguide — vejledning i at begrænse tilladte oprindelser og håndtere credentialed adgang.