Så fixar du CORS-fel i AI-genererade appar

CORS (Cross-Origin Resource Sharing) är en säkerhetsmekanism i webbläsaren, inte ett serverfel. Så här fungerar det: varje gång din applikation försöker skicka en HTTP-förfrågan till en annan origin (en annan domän, port eller protokoll) frågar webbläsaren först målservern om det är tillåtet.

På localhost kör din frontend och backend vanligtvis på samma adress — till exempel http://localhost:3000. Det är same-origin — samma domän, samma port, samma protokoll. Webbläsaren ser inget problem eftersom förfrågan går till samma host. Det är därför allt fungerar under utveckling.

Efter driftsättning ligger din frontend på https://minapp.com och din backend på https://api.minapp.com eller en helt annan domän. Det är cross-origin. Och det är här webbläsaren kliver in.

Innan webbläsaren skickar din faktiska förfrågan (POST, PUT, DELETE) skickar den först en så kallad preflight-förfrågan — en OPTIONS-förfrågan till samma URL. Den frågar i princip: “Hej server, får frontend från domän X skicka POST-förfrågningar med de här headerna?” Om servern inte svarar med rätt CORS-headers blockerar webbläsaren förfrågan innan den ens skickas.

Det viktigaste att förstå: CORS är en webbläsarmekanism. Postman, curl, server-till-server-förfrågningar — ingen av dem tillämpar CORS. Därför kan ditt API fungera perfekt i Postman medan det kastar fel i webbläsaren. Det är inte en API-bugg — det är webbläsaren som gör sitt jobb.

Steg 1: Kontrollera det verkliga felet

De flesta tittar på CORS-felet i webbläsarens konsol och antar att det är ett CORS-problem. Men ofta är det verkliga felet någon annanstans. Öppna fliken Network i DevTools, inte Console.

Hitta den misslyckade förfrågan. Klicka på den och kontrollera svarskoden. Om du ser 500 Internal Server Error kraschade din server — och eftersom den kraschade lade den inte till CORS-headers i svaret. Webbläsaren ser den saknade Access-Control-Allow-Origin-headern och visar ett CORS-fel, men det verkliga problemet är ett serverfel.

Om endpointen ger fel (500) läggs Access-Control-Allow-Origin vanligtvis inte till. Fixa serverfelet, så försvinner “CORS-felet” av sig självt.

Steg 2: Rätt sätt att konfigurera CORS (Express.js)

Här är hur ett CORS-middleware borde se ut på en Express.js-server. Notera att vi anger specifika domäner istället för wildcards, hanterar OPTIONS-förfrågan och ställer in credentials:

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: Vad AI genererar (fel)

Och här är vad AI:n vanligtvis genererar när du ber den “fixa CORS”. Det ser enkelt ut, men är fullt av problem:

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

Skillnaderna är kritiska: wildcard * innebär att vilken webbplats som helst i världen kan skicka förfrågningar till ditt API. Ingen OPTIONS-hantering innebär att preflight-förfrågningar inte fungerar. Ingen Allow-Credentials innebär att cookies och tokens inte skickas. Det här är inte “fixat” — det är ett öppet säkerhetshål.

Steg 4: CORS i Supabase Edge Functions

Om du använder Supabase Edge Functions (Deno) måste CORS hanteras manuellt i varje funktion — eller, ännu bättre, centraliseras i en enda hjälpfil. Här är det korrekta mönstret:

const corsHeaders = {
  'Access-Control-Allow-Origin': 'https://yourapp.com',
  'Access-Control-Allow-Methods': 'POST, OPTIONS',
  'Access-Control-Allow-Headers':
    'Content-Type, Authorization',
};

Deno.serve(async (req) => {
  if (req.method === 'OPTIONS')
    return new Response(null, {
      status: 204,
      headers: corsHeaders
    });

  // Your logic here
  const data = { message: 'Hello' };

  return new Response(
    JSON.stringify(data),
    {
      headers: {
        ...corsHeaders,
        'Content-Type': 'application/json'
      }
    }
  );
});

Steg 5: Centralisera CORS-konfigurationen

En fil, ett ställe. CORS-konfigurationen borde ligga på ett enda ställe i hela ditt projekt — inte spridas ut över varje endpoint och varje funktion. Skapa en fil cors.js (eller cors.ts) och importera den överallt där den behövs.

Lås samtidigt fast JSON-svarsformatet — varje endpoint borde returnera data i samma format. Håll din startfil liten — den borde bara importera middleware och starta servern. All affärslogik hör hemma i separata filer.

På så sätt, när du behöver ändra tillåtna origins eller lägga till en ny header, gör du det på ett ställe, och ändringen fungerar överallt. Brist på centralisering är en av huvudorsakerna till att AI-appar fungerar lokalt men misslyckas i produktion.

Steg 6: Felsök knepiga fall

Ibland ser allt korrekt ut och CORS fungerar ändå inte. Här är de vanligaste fällorna:

• URL:er som inte matchar: https://minapp.com är inte samma sak som https://www.minapp.com. Se upp med avslutande snedstreck — webbläsaren skickar Origin-headern utan avslutande snedstreck, så om din lista över tillåtna origins innehåller https://minapp.com/ kommer strängjämförelsen att misslyckas.
• no-cors-läge i fetch: Om någon (eller AI) lade till mode: 'no-cors' i en fetch-förfrågan kastar webbläsaren inget fel — men svaret blir “opaque”. Du kan inte läsa status, headers eller body. Det här är ingen fix — det är att sopa problemet under mattan.
• Blandning av HTTP och HTTPS: http:// och https:// är olika origins. Om din frontend är på HTTPS och din backend på HTTP blockerar CORS förfrågan, och dessutom kan webbläsaren blockera blandat innehåll.
• Dev-proxy vs. produktion: Många ramverk (React, Vue, Next.js) använder en proxy i utvecklingsläge som maskerar cross-origin-förfrågningar. I produktion finns inte den proxyn — och plötsligt smäller CORS till. Därför dyker CORS-fel bara upp efter driftsättning.

Innan du driftsätter din applikation, gå igenom dessa punkter. Var och en är en potentiell källa till CORS-fel i produktion. Om en inte är uppfylld kan din app gå sönder på sätt som är svåra att diagnostisera.