CORS-fel JavaScript: så förstår och löser du det

CORS-fel JavaScript betyder att webbläsaren har blockerat ett svar från en annan domän, port eller protokoll än den sida som gjorde anropet. Felet kommer från webbläsaren, inte från servern. Servern svarar ofta korrekt, men webbläsaren släpper inte igenom svaret till din kod om inte servern uttryckligen tillåter det. Den här guiden visar vad felet betyder, varför det uppstår och hur du löser det på rätt ställe.

Vad betyder CORS?

CORS står för Cross-Origin Resource Sharing. En origin består av protokoll, domän och port. Adresserna https://webide.se och https://api.webide.se är därför två olika origins, eftersom domänen skiljer sig. Även http://localhost:3000 och http://localhost:5000 är olika origins, eftersom porten skiljer sig.

Webbläsaren tillämpar en grundregel som kallas same-origin policy. Den hindrar en sida från att läsa svar från en annan origin. CORS är mekanismen som låter servern säga att vissa andra origins får läsa dess svar. Utan den tillståndsgivningen blockerar webbläsaren anropet.

En blockerad förfrågan betyder inte alltid att servern är nere. Ofta har anropet nått servern och svaret har kommit tillbaka, men webbläsaren har vägrat att ge det till din JavaScript-kod.

Så ser felet ut i konsolen

I webbläsarens utvecklarverktyg, oftast under fliken Console, ser du ett meddelande som liknar detta: Access to fetch at 'https://api.exempel.se/data' from origin 'http://localhost:3000' has been blocked by CORS policy. Meddelandet nämner origin, alltså sidan som gjorde anropet, och URL:en som blockerades. Exakt formulering varierar mellan webbläsare.

Ett try/catch fångar ofta bara ett allmänt TypeError med texten Failed to fetch, eftersom webbläsaren inte ger ut detaljerna till koden. Titta därför alltid i konsolen när du felsöker.

Varför uppstår felet?

Det vanligaste skälet är att du utvecklar frontend på en port och backend på en annan. En React-app på localhost:5173 som anropar en Express-server på localhost:3000 är ett klassiskt exempel. Samma sak gäller när en statisk sida ligger på en domän och API:t på en annan.

Andra vanliga orsaker är att servern inte skickar rubriken Access-Control-Allow-Origin, att rubriken innehåller fel origin, eller att anropet använder metoder eller egna headers som kräver en preflight-förfrågan som servern inte svarar på. En preflight är en OPTIONS-förfrågan som webbläsaren skickar först när anropet till exempel använder metoden PUT eller en header som Authorization.

Lösning 1: Tillåt origin på servern

Den rätta lösningen är nästan alltid att servern skickar rätt rubriker. Här är ett exempel i Express med npm-paketet cors, ett vanligt paket för just detta:

const cors = require('cors'); const app = express(); app.use(cors({ origin: 'http://localhost:5173' }));

Med ett explicit origin släpper du bara in den frontend du faktiskt använder. Det är säkrare än att tillåta alla origins. Om du behöver skicka cookies eller Authorization-headers måste servern sätta credentials till true, och då får origin inte vara en jokertecken.

Om du inte använder Express kan du sätta rubriken direkt. Servern ska svara med Access-Control-Allow-Origin, och vid preflight även Access-Control-Allow-Methods och Access-Control-Allow-Headers. Kontrollera svaret i fliken Network i utvecklarverktygen för att se exakt vilka rubriker som skickas.

Lösning 2: Använd en proxy i utvecklingsmiljön

Om problemet bara finns lokalt och du inte kontrollerar API:t kan en proxy lösa det under utveckling. Verktyg som Vite och Create React App har inbyggda proxyinställningar. Frontend anropar då en relativ sökväg, till exempel /api/data, och utvecklingsservern skickar vidare förfrågan till API:t. Webbläsaren ser samma origin och CORS blir inte aktuellt.

En proxy är en lösning för utveckling, inte för produktion. I produktion bör du antingen servera frontend och API under samma domän, eller sätta korrekta CORS-rubriker.

Lösning 3: Undvik att lösa det med no-cors

Det går att skicka fetch med mode: 'no-cors'. Felet försvinner då från konsolen, men du får ett opaque-svar som din kod inte kan läsa. Det är nästan aldrig det du vill ha. Använd inte no-cors när du behöver datan i din JavaScript-kod.

Felsökning av CORS-fel JavaScript steg för steg

Gå igenom detta i ordning när du stöter på ett CORS-fel:

1. Kontrollera att origin i felmeddelandet är exakt den du tror, inklusive port och http eller https.
2. Öppna fliken Network, klicka på den blockerade förfrågan och titta på svarets rubriker.
3. Kontrollera att Access-Control-Allow-Origin matchar din origin exakt.
4. Om förfrågan är en OPTIONS-förfrågan, kontrollera att servern svarar med status 200 eller 204 och tillåter metoden och headers.
5. Testa anropet med curl. Om curl fungerar men webbläsaren inte gör det, är felet nästan säkert CORS.

Vanliga misstag

Det vanligaste misstaget är att sätta Access-Control-Allow-Origin till en jokertecken, *, och samtidigt skicka cookies. Webbläsaren avvisar då kombinationen. Ett annat misstag är att lägga CORS-middleware efter routes. Då når inte rubrikerna svaren från de routes som kommer före i kedjan. I Express ska cors-middleware ligga tidigt, före dina routes.

Ett tredje misstag är att försöka lösa felet i frontend genom att ändra headers i fetch. Headers i anropet påverkar inte om servern tillåter origin. Felet måste lösas i svaret från servern.

Sammanfattning: CORS-fel JavaScript i praktiken

CORS-fel JavaScript uppstår när webbläsaren blockerar ett svar från en annan origin. Lösningen ligger nästan alltid i servern, där du sätter rätt Access-Control-Allow-Origin och hanterar preflight. I utveckling kan en proxy vara en snabb väg vidare. Undvik no-cors om du behöver läsa svaret. Börja alltid med att läsa felmeddelandet och svarets rubriker i fliken Network.