Jak naprawić błędy CORS w aplikacjach generowanych przez AI

CORS (Cross-Origin Resource Sharing) to mechanizm bezpieczeństwa przeglądarki, a nie błąd serwera. Działa tak: za każdym razem, gdy Twoja aplikacja próbuje wysłać zapytanie HTTP do innego originu (innej domeny, portu lub protokołu), przeglądarka najpierw pyta serwer docelowy, czy jest to dozwolone.

Na localhost Twój frontend i backend zwykle działają pod tym samym adresem — na przykład http://localhost:3000. To jest same-origin — ta sama domena, ten sam port, ten sam protokół. Przeglądarka nie widzi problemu, bo zapytanie idzie do tego samego hosta. Dlatego właśnie na etapie developmentu wszystko działa.

Po wdrożeniu Twój frontend zaczyna żyć na https://mojaapka.com, a backend na https://api.mojaapka.com albo na zupełnie innej domenie. To jest już cross-origin. I tu przeglądarka wchodzi do gry.

Zanim przeglądarka wyśle Twoje prawdziwe zapytanie (POST, PUT, DELETE), najpierw wysyła tak zwane zapytanie preflight — zapytanie OPTIONS do tego samego URL-a. To w gruncie rzeczy pytanie: «Hej serwerze, czy frontend z domeny X może wysyłać Ci zapytania POST z takimi nagłówkami?» Jeśli serwer nie odpowie właściwymi nagłówkami CORS, przeglądarka zablokuje zapytanie zanim je w ogóle wyśle.

Kluczowa sprawa: CORS to mechanizm przeglądarki. Postman, curl, zapytania z serwera — żadne z nich nie stosuje CORS. Dlatego Twoje API może działać doskonale w Postmanie, a w przeglądarce wyrzucać błędy. To nie jest błąd API — to przeglądarka robi swoją robotę.

Krok 1: Sprawdź prawdziwy błąd

Większość ludzi patrzy na błąd CORS w konsoli przeglądarki i myśli, że to problem z CORS. Ale często prawdziwy błąd jest gdzieś indziej. Otwórz w DevTools zakładkę Network, a nie Console.

Znajdź zapytanie, które nie przeszło. Kliknij na nie i sprawdź kod odpowiedzi. Jeśli widzisz 500 Internal Server Error, to znaczy, że Twój serwer się wysypał — a skoro się wysypał, nie dodał nagłówków CORS do odpowiedzi. Przeglądarka widzi brak nagłówka Access-Control-Allow-Origin i pokazuje błąd CORS, ale prawdziwy problem to błąd serwera.

Jeśli endpoint zwraca błąd (500), nagłówek Access-Control-Allow-Origin zwykle nie zostanie dodany. Napraw błąd serwera, a «błąd CORS» zniknie sam.

Krok 2: Prawidłowa konfiguracja CORS (Express.js)

Oto jak powinien wyglądać middleware CORS na serwerze Express.js. Zauważ, że ustawiamy konkretne domeny, a nie wildcard, obsługujemy zapytanie OPTIONS i ustawiamy 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();
}

Krok 3: Jak AI to pisze (źle)

A oto co zazwyczaj generuje AI, kiedy prosisz o «naprawienie CORS». Wygląda prosto, ale jest pełne problemów:

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

Różnice są kluczowe: wildcard * oznacza, że każda strona na świecie może wysyłać zapytania do Twojego API. Brak obsługi OPTIONS oznacza, że zapytania preflight nie będą działać. Brak Allow-Credentials oznacza, że ciasteczka i tokeny nie będą przesyłane. To nie jest «naprawione» — to jest otwarta furtka bezpieczeństwa.

Krok 4: CORS w Supabase Edge Functions

Jeśli używasz Supabase Edge Functions (Deno), CORS musi być obsłużony ręcznie w każdej funkcji — lub, jeszcze lepiej, scentralizowany w jednym pliku pomocniczym. Oto poprawny wzorzec:

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'
      }
    }
  );
});

Krok 5: Scentralizuj konfigurację CORS

Jeden plik, jedno miejsce. Konfiguracja CORS powinna żyć w jednym miejscu w całym projekcie — nie rozproszona po każdym endpoincie i każdej funkcji. Stwórz plik cors.js (lub cors.ts) i importuj go wszędzie, gdzie jest potrzebny.

Przy okazji ustandaryzuj format odpowiedzi JSON — każdy endpoint powinien zwracać dane w tym samym kształcie. Plik wejściowy (entry file) trzymaj jak najkrótszy — powinien tylko importować middleware i uruchamiać serwer. Cała logika biznesowa trafia do oddzielnych plików.

Dzięki temu, kiedy musisz zmienić dozwolone originy albo dodać nowy nagłówek, robisz to w jednym miejscu, a zmiana działa wszędzie. Brak centralizacji to jeden z głównych powodów, dla których aplikacje AI działają lokalnie, a padają na produkcji.

Krok 6: Debugowanie trudnych przypadków

Czasami wszystko wygląda poprawnie, a CORS i tak nie działa. Oto najczęstsze pułapki:

• Niezgodność URL-i: https://mojaapka.com to nie to samo co https://www.mojaapka.com. Uważaj też na trailing slash — przeglądarka wysyła nagłówek Origin bez końcowego ukośnika, więc jeśli Twoja lista dozwolonych zawiera https://mojaapka.com/, porównanie stringów nie zadziała.
• Tryb no-cors w fetch: Jeśli ktoś (lub AI) dodał mode: 'no-cors' do zapytania fetch, przeglądarka nie wyrzuci błędu — ale odpowiedź będzie «opaque». Nie można odczytać statusu, nagłówków ani body. To nie jest naprawa — to zamiatanie pod dywan.
• Mieszanie HTTP i HTTPS: http:// i https:// to różne originy. Jeśli Twój frontend jest na HTTPS, a backend na HTTP, CORS zablokuje zapytanie, a na dodatek przeglądarka może zablokować mixed content.
• Proxy w development vs. produkcja: Wiele frameworków (React, Vue, Next.js) używa proxy w trybie deweloperskim, który maskuje cross-origin. Na produkcji tego proxy nie ma — i nagle CORS wybucha. Dlatego błędy CORS pojawiają się dopiero po wdrożeniu.

Zanim wdrożysz swoją aplikację, przejdź przez te punkty. Każdy z nich to potencjalne źródło błędów CORS na produkcji. Jeśli choć jeden zostanie pominięty, aplikacja może się wysypać w sposób trudny do zdiagnozowania.