Ako opraviť CORS chyby (a prečo vznikajú)

CORS chyba znamená, že vaša webová stránka sa pokúsila čítať odpoveď z iného pôvodu (inej domény, portu alebo protokolu) a ten server neposlal hlavičky, ktoré hovoria, že je to povolené. Prehliadače odpoveď zablokujú, aby chránili používateľov. Opravíte to na serveri: vrátite hlavičku Access-Control-Allow-Origin pre pôvod vašej stránky a spracujete OPTIONS preflight požiadavky, alebo sa tomu vyhnete tak, že požiadavku pošlete cez vlastný backend na rovnakom pôvode.

Je to jedna z najmätúcejších chýb vo webovom vývoji, lebo požiadavka na server zvyčajne dorazí v poriadku. Tento návod vysvetľuje, čo sa deje, a ako opraviť každú variantu.

Čo znamená „pôvod“

Pôvod je kombinácia protokolu, domény a portu:

Prehliadače dodržiavajú politiku rovnakého pôvodu: JavaScript na stránke môže voľne čítať odpovede zo svojho vlastného pôvodu, ale nie z iných. CORS (Cross-Origin Resource Sharing) je systém, ktorý umožňuje serveru vysloviť súhlas: „odpovede odo mňa môžu čítať stránky z týchto pôvodov.“

Dva dôsledky prekvapia väčšinu ľudí:

• Požiadavka na server často dorazí. CORS zvyčajne blokuje, aby váš kód čítal odpoveď, nie to, aby server dostal požiadavku. POST mohol byť uložený, aj keď ste videli chybu.
• Vynucujú ho len prehliadače. curl, Postman a kód na strane servera CORS úplne ignorujú. Preto „funguje to v Postman“ o CORS nič nehovorí.

Krok 1: Prečítajte si presnú chybu

Otvorte vývojárske nástroje (pravý klik → Preskúmať), prejdite na Konzolu a prečítajte si celú správu. Znenie v Chrome vám povie, s akým problémom máte do činenia:

Potom otvorte kartu Sieť, nájdite zlyhanú požiadavku (a každú OPTIONS požiadavku pred ňou) a pozrite sa na jej stavový kód a hlavičky odpovede.

Najprv skontrolujte stavový kód. Mnohé „CORS chyby“ sú v skutočnosti chyba servera v preoblečení. Ak server spadne alebo vráti 404, jeho chybová odpoveď často neobsahuje CORS hlavičky, takže prehliadač nahlási CORS namiesto skutočného problému. Opravte 500 alebo 404 a CORS chyba môže zmiznúť.

Krok 2: Rozhodnite, či by mal prehliadač toto API vôbec volať

Skôr než pridáte hlavičky, sa opýtajte: má prehliadač volať toto API priamo?

• API tretej strany, ktoré potrebuje tajný kľúč (OpenAI, tajný kľúč Stripe, väčšina e-mailových služieb), by sa nikdy nemalo volať z prehliadača. Kľúč by bol viditeľný každému návštevníkovi. Volajte ho z vášho backendu a CORS problém zmizne, lebo požiadavky medzi servermi nepodliehajú CORS. Pozri ako udržať API kľúče v bezpečí.
• API tretej strany, ktoré neovládate a ktoré neposiela CORS hlavičky, nemôžete opraviť zo svojej strany. Volajte ho z backendu.
• Vaše vlastné API môžete opraviť správnou konfiguráciou. Pokračujte nižšie.

Krok 3: Opravte to na serveri

Server musí pridať správne hlavičky do svojich odpovedí vrátane chybových odpovedí.

Pre samotnú požiadavku pošlite:

• Access-Control-Allow-Origin: https://myapp.com (presný pôvod vášho frontendu, bez koncového lomítka)
• Vary: Origin, ak hodnota závisí od toho, ktorý pôvod sa pýta

Pre preflight OPTIONS požiadavku odpovedajte úspešným stavom (200 alebo 204) a:

• Access-Control-Allow-Origin: https://myapp.com
• Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE
• Access-Control-Allow-Headers: Content-Type, Authorization (každú vlastnú hlavičku, ktorú posielate)
• Voliteľne Access-Control-Max-Age: 600, aby si prehliadač preflight nejaký čas ukladal do cache

Väčšina frameworkov má balík alebo nastavenie, ktoré to robí. V Expresse balík cors; vo FastAPI CORSMiddleware; v ASP.NET Core AddCors; v Springu @CrossOrigin alebo konfiguráciu CORS. Typické nastavenie v Expresse:

import cors from "cors";

app.use(cors({
  origin: ["https://myapp.com", "http://localhost:5173"],
  credentials: true,
}));

Zaraďte spracovanie CORS pred vaše trasy a autentifikáciu, aby preflight požiadavky (ktoré nemajú prihlásenie) neboli odmietnuté s 401.

S nástrojom na tvorbu s AI opíšte nastavenie presne:

Frontend na https://myapp.com volá API na https://api.myapp.com a dostáva „Response to preflight request doesn't pass access control check“. Nastav CORS na API tak, aby povoľoval presne https://myapp.com a pôvod náhľadu, povoľ GET, POST, PATCH, DELETE s hlavičkami Content-Type a Authorization, spracuj OPTIONS pred autentifikáciou a zahrň CORS hlavičky aj do chybových odpovedí.

Krok 4: Cookies a poverovacie údaje

Ak váš frontend posiela cookies (napríklad reláciu prihlásenia) inému pôvodu, obe strany sa musia zhodnúť:

• Frontend nastaví credentials: "include" vo fetch, alebo withCredentials: true v axios.
• Server pošle Access-Control-Allow-Credentials: true.
• Access-Control-Allow-Origin servera musí byť presný pôvod, nie *.

Cross-site cookies navyše potrebujú SameSite=None; Secure a niektoré prehliadače obmedzujú cookies tretích strán ešte viac. Je to ďalší dôvod uprednostniť prístup z kroku 5.

Krok 5: Vyhnite sa CORS cez nastavenie na rovnakom pôvode

Často je najčistejšia oprava vôbec neposielať cross-origin požiadavky. Obslúžte API z rovnakého pôvodu ako stránka, napríklad na https://myapp.com/api/...:

• Vo vývoji vedia väčšinou dev servery preposielať. Nastavenie server.proxy vo Vite vie preposlať /api na váš backend na inom porte, takže prehliadač komunikuje len s jedným pôvodom.
• V produkcii smerujte /api na backend cez prepisovacie alebo proxy nastavenia vášho hostingu, alebo obsluhujte frontend a API z jedného servera.

Frontend potom volá relatívnu cestu, napríklad fetch("/api/orders"). Nie je tu cross-origin požiadavka, žiadny preflight naprieč pôvodmi a žiadne problémy s cookies. Tiež to znamená, že nemusíte natvrdo zapisovať doménu API, ktorá sa líši medzi náhľadom a produkciou.

Zmeň frontend tak, aby volal backend cez relatívne cesty /api namiesto plnej URL, a nastav vývojový proxy, ktorý bude posielať /api na API server. Potom odstráň nastavenia CORS, ktoré už nepotrebujeme.

Čo nerobiť

• mode: "no-cors" vo fetch. Nič neobchádza; vášmu kódu dá prázdnu, nečitateľnú odpoveď.
• Rozšírenia prehliadača, ktoré vypínajú CORS. Menia len váš prehliadač. Každý návštevník stále uvidí chybu.
• Verejné „CORS proxy“ služby pre skutočné aplikácie. Môžu čítať a meniť všetko, čo nimi prechádza, a občas nefungujú.
• Access-Control-Allow-Origin: * na API, ktoré používa prihlásenie. Aj tak nefunguje s poverovacími údajmi a je to zlý predvolený stav pre súkromné dáta.
• Odrážanie ľubovoľnej hlavičky Origin späť s povolenými poverovacími údajmi. Tým môže ľubovoľná webová stránka robiť požiadavky v mene vašich prihlásených používateľov. Používajte zoznam povolených.

Časté príčiny v aplikáciách vytvorených s AI

CORS v Mythex

Keď má projekt v Mythex webovú stránku aj API server, obe bežia ako služby v tom istom projekte a medzi nimi môžete v náhľade prepínať. Ak požiadate agenta, aby frontend volal backend cez relatívnu cestu /api, preposlanú vo vývoji, vyriešite väčšinu CORS problémov. Ak naozaj potrebujete volania cez pôvody, dajte agentovi presnú chybu z konzoly a zoznam zúčastnených pôvodov. Výsledok skontrolujte aj na publikovanej aplikácii, lebo jej adresa sa líši od náhľadu. Pozrite si Viacservisové aplikácie a API backendy v dokumentácii a naše návody ako ladiť aplikáciu vytvorenú s AI a frontend vs. backend.

Kontrolný zoznam CORS

• Prečítaná celá chyba z konzoly a stavový kód neúspešnej požiadavky
• Vylúčené skryté 404 alebo 500
• API s tajnými kľúčmi volané z backendu, nie z prehliadača
• Server posiela Access-Control-Allow-Origin s presnými povolenými pôvodmi
• OPTIONS preflight odpovedá povolenými metódami a hlavičkami, pred autentifikáciou
• CORS hlavičky sú prítomné aj v chybových odpovediach
• Poverovacie údaje: presný pôvod, Allow-Credentials: true, správne nastavenia cookies
• Náhľad, publikovaný a vlastný pôvod pokryté, alebo použité relatívne cesty /api
• Žiadne no-cors, verejné proxy ani odrážanie ľubovoľného pôvodu

Otázky