Så åtgärdar du CORS-felet 'Access-Control-Allow-Origin' saknas i Express.js

Om en webbläsare visar CORS header 'Access-Control-Allow-Origin' missing är den viktiga ledtråden inte att Express.js misslyckades med att ta emot förfrågan. Webbläsaren meddelar att svaret inte innehöll en CORS-header som godkände sidans ursprung för att läsa det svaret. Åtgärden hör därför hemma på servern eller en proxy du kontrollerar, inte i en slumpmässig klientinställning.

Illustrativt exempel som används genom hela denna guide: föreställ dig en uppgiftspanel som körs på http://localhost:5173 och som anropar ett Express-API på http://localhost:3000/api/tasks. Webbläsaren blockerar JavaScript från att läsa API-svaret eftersom API:t inte returnerar Access-Control-Allow-Origin. Detta är ett hypotetiskt undervisningsexempel, inte ett påstående om ett verkligt test, produkt eller distribution.

Såsom kontrollerat den 11 september 2026 listar den officiella Express CORS-middleware-dokumentationen cors version 2.8.6 och beskriver den som middleware som ställer in CORS-svarshuvuden. Den nuvarande Express-paketlistan är i 5.x-generationen, så denna guide föredrar applikationsnivåmiddleware istället för att förlita sig på äldre wildcard-routmönster.

Vad felet egentligen betyder

En webbsida har ett ursprung (origin) bestående av dess schema, värd och port. I exemplet är http://localhost:5173 och http://localhost:3000 olika ursprung eftersom deras portar skiljer sig åt. Webbläsarens policy för samma ursprung (same-origin policy) förhindrar normalt att JavaScript på ett ursprung läser resurser från ett annat om inte målserversn returnerar lämpliga Cross-Origin Resource Sharing (CORS)-huvuden.

MDN:s dokumentation för just detta fel förklarar att svaret saknar den nödvändiga Access-Control-Allow-Origin-headern. Om du kontrollerar servern bör du konfigurera det begärande webbsidans ursprung som ett tillåtet ursprung. För offentliga API:er utan autentiseringsuppgifter kan * vara lämpligt; för privata eller autentiserade API:er, använd specifika betrodda ursprung istället. Se MDN:s förklaring av felet där Access-Control-Allow-Origin saknas.

Steg 1: Bekräfta att CORS är problemet och identifiera det exakta ursprunget

Öppna webbläsarens utvecklarverktyg och kontrollera både Konsol- och Nätverkspanelerna. Registrera frontend-ursprunget exakt som webbläsaren skickar det. I vårt illustrativa fall är det http://localhost:5173.

Reduktera inte ett ursprung till bara ett värdnamn. Dessa är olika ursprung: http://localhost:5173, http://localhost:3000, http://127.0.0.1:5173 och https://localhost:5173. En produktionsallowlista måste på samma sätt skilja på https://app.example.com från andra scheman, värdar, portar eller underdomäner om du inte avsiktligt tillåter dem.

Om API-svaret är ett 404-, 500-, omdirigerings-, autentiseringsfel eller en proxygenererad felsida, inspektera även det svaret. CORS-huvuden måste finnas på det svar webbläsaren faktiskt tar emot. Att fixa en applikationsrutt hjälper inte om en reverse proxy, CDN, lastbalanserare eller felhanterare returnerar ett annat svar utan headern.

Steg 2: Installera och ladda den officiella Express CORS-middlewaren

För de flesta Express-applikationer är den minst felbenägna lösningen cors-middlewaren som underhålls av Express-projektet. Den officiella Express-middleware-sidan listar den bland middleware som underhålls av Express.js-teamet. Installera den i ditt API-projekt:

npm install cors

Ladda den sedan bredvid Express:

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

const app = express();

Den officiella dokumentationen finns på Express.js cors middleware-dokumentation. Express dokumenterar också hur applikationsnivåmiddleware körs i förfrågningsordning på Express.js: Använda middleware.

Steg 3: Tillåt frontend-ursprunget medvetet

För den hypotetiska panelen, konfigurera det exakta utvecklingsursprunget före de rutter som behöver 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: ['Learn Express', 'Build API'] });
});

app.listen(3000);

Att placera app.use(cors(corsOptions)) före API-rutterna är viktigt eftersom Express bearbetar middleware i ordning. Middlewaren behöver en chans att lägga till svarshuvuden innan en rutt eller tidigare middleware avslutar förfrågan.

För ett riktigt offentligt API som inte använder autentiseringsuppgifter, använder app.use(cors()) middlewarens standardbeteende för tillåtande ursprung. Det är bekvämt, men det bör inte vara ditt automatiska produktionsval. MDN rekommenderar att begränsa Access-Control-Allow-Origin till de minsta ursprung och resurser som behövs. Se MDN:s CORS-säkerhetsvägledning.

Tillåt flera kända ursprung utan att tillåta alla

En vanlig produktionsinstallation har en lokal frontend, en staging-frontend och en produktionsfrontend. Använd en allowlista och validera det inkommande ursprunget:

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 tillåter klienter som inte skickar en Origin-header, såsom många server-till-server-förfrågningar och kommandoradsverktyg. Om du vill ha det beteendet är ett applikationspolicybeslut; CORS i sig är inte autentisering.

Steg 4: Verifiera den enkla förfrågan och eventuella preflight-förfrågningar

Ladda om frontend och inspektera Nätverkspanelen. Framgångsvillkoret är inte bara en 200-status. Kontrollera svarshuvudena. I vårt illustrativa fall bör API-svaret innehålla ett ursprungsvärde motsvarande:

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

Vissa korsursprungs-förfrågningar utlöser en preflight: webbläsaren skickar en OPTIONS-förfrågan innan den verkliga förfrågan för att kontrollera om metoden och huvudena är tillåtna. Förfrågningar som använder metoder som PUT eller DELETE, eller vissa anpassade/förfrågningshuvuden, behöver vanligtvis preflight. När cors är installerad som applikationsnivåmiddleware med app.use(cors(...)), säger den officiella Express-dokumentationen att preflight-förfrågningar hanteras för alla rutter.

Du kan också inspektera huvuden utanför webbläsaren utan att påstå att kommandoradsklienten verkställer CORS:

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

Detta är användbart för att se vad servern returnerar, men en lyckad curl- eller API-klientförfrågan bevisar inte att webbläsarens CORS är korrekt konfigurerat. Express CORS-dokumentation noterar uttryckligen att CORS verkställs av webbläsare; icke-webbläsarklienter tillämpar inte samma läsrestriktion.

Autentiserade förfrågningar: kombinera inte autentiseringsuppgifter med ett wildcard-ursprung

Om frontend måste skicka cookies eller HTTP-autentisering över ursprung, behöver båda sidor kompatibla inställningar. På Express-sidan, konfigurera ett specifikt betrodda ursprung och aktivera autentiseringsuppgifter:

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

På webbläsarsidan använder en fetch-förfrågan som behöver cookies vanligtvis credentials: 'include'. Byt inte serverursprunget till * för en autentiserad förfrågan. Webbläsare accepterar inte ett wildcard Access-Control-Allow-Origin tillsammans med autentiserad CORS på det sätt utvecklare ofta förväntar sig, och ett obegränsat ursprung skulle också vara en dålig säkerhetsgräns.

Varför vanliga "fixar" misslyckas

När Express-koden ser korrekt ut men felet kvarstår

Om de fyra stegen ovan inte löser felet, spåra hela förfrågningsvägen istället för att blindt lägga till fler huvuden.

• Kontrollera middleware-ordningen. CORS-middleware bör köras före rutter eller hanterare som avslutar svaret.
• Kontrollera omdirigeringar. Webbläsaren kan ta emot ett svar från en annan URL eller ett annat ursprung efter en omdirigering.
• Kontrollera proxy/CDN-beteende. Nginx, en gateway, en serverlös plattform eller en CDN kan lägga till, ta bort, duplicera eller ersätta huvuden.
• Kontrollera felsvar. Ett normalt 200-svar kan innehålla CORS-huvuden medan ett 401-, 404- eller 500-svar inte gör det.
• Kontrollera det bokstavliga ursprunget. Schema, värdnamn och port spelar alla roll; localhost och 127.0.0.1 är inte utbytbara för CORS-matchning.
• Kontrollera efter duplicerade huvuden. MDN dokumenterar att flera Access-Control-Allow-Origin-huvuden inte är tillåtna. Se MDN om flera Access-Control-Allow-Origin-huvuden.

Manuella huvuden jämfört med cors-middlewaren

Du kan ställa in CORS-huvuden manuellt med Express-svars-API:er, men det är lätt att missa preflight-beteende, autentiseringsregler, dynamisk ursprungsmatchning, Vary: Origin eller felsökvägar. Den officiella cors-middlewaren exponerar redan alternativ för origin, metoder, tillåtna huvuden, exponerade huvuden, autentiseringsuppgifter, preflight-beteende och max age. För de flesta Express-projekt håller användningen av den middlewaren policyn explicit och lättare att granska.

Om du implementerar dynamisk ursprungslogik själv, reflektera aldrig varje inkommande Origin-värde automatiskt bara för att det finns. Validera det mot en betrodd uppsättning. MDN varnar för att obegränsade korsursprungs-läsningar kan exponera data, särskilt när autentiseringsuppgifter är inblandade.

En praktisk produktionschecklista

• Lista de exakta frontend-ursprung som ska kunna läsa API:t.
• Använd HTTPS-ursprung i produktion och håll utvecklingsursprung separata.
• Installera CORS-middleware före skyddade API-rutter som behöver den.
• Använd specifika ursprung för privata eller autentiserade slutpunkter.
• Verifiera både normala svar och preflight OPTIONS-svar i webbläsaren.
• Verifiera felsökvägar som 401-, 404- och 500-svar om de kan returneras över ursprung.
• Behandla CORS som en webbläsarläspolicy, inte som autentisering eller auktorisering.

I det illustrativa uppgiftspanel-scenariot är den hållbara fixen enkel: identifiera frontendens exakta ursprung, konfigurera Express för att returnera det matchande CORS-huvudet, låt applikationsnivåmiddleware hantera preflight och verifiera huvudena på svaret webbläsaren faktiskt tar emot. Om headern fortfarande saknas efter det är den nästa misstänkte vanligtvis middleware-ordningen eller infrastrukturen mellan webbläsaren och Express, inte själva frontend fetch-anropet.

Officiella referenser

• Express.js cors middleware-dokumentation — konfigurationsalternativ, dynamiska ursprung, autentiseringsuppgifter och preflight-beteende.
• Express.js middleware-guide — applikationsmiddleware och förfrågningsbearbetningsordning.
• MDN: CORS header Access-Control-Allow-Origin missing — betydelsen av detta specifika webbläsarfel.
• MDN CORS-säkerhetskonfigurationsguide — vägledning om att begränsa tillåtna ursprung och hantera autentiserad åtkomst.