Paano Ayusin ang CORS Errors (at Bakit Ito Nangyayari)

Ang CORS error ay nangangahulugang sinubukan ng web page mo na magbasa ng response mula sa ibang origin (ibang domain, port o protocol), at walang header ang server na nagsasabing pinapayagan ito. Hinaharangan ng browser ang response para protektahan ang users. Inaayos ito sa server, sa pamamagitan ng pagbabalik ng Access-Control-Allow-Origin header para sa origin ng site mo at pagtanggap sa OPTIONS preflight requests, o iniiwasan sa pamamagitan ng pagpapadala ng request sa sarili mong backend sa parehong origin.

Isa ito sa pinakanakakalitong error sa web development dahil madalas na naaabot ng request ang server nang maayos. Ipinapaliwanag ng gabay na ito kung ano ang nangyayari at paano ayusin ang bawat variant.

Ano ang ibig sabihin ng "origin"

Ang origin ay kombinasyon ng protocol, domain at port:

Sinusunod ng mga browser ang same-origin policy: malayang nababasa ng JavaScript sa isang page ang response mula sa sarili nitong origin, pero hindi mula sa iba. Ang CORS (Cross-Origin Resource Sharing) ang sistemang nagpapahintulot sa server na mag-opt in: "puwedeng basahin ng mga page mula sa mga origin na ito ang mga response ko."

Dalawang bagay ang nakakagulat sa mga tao:

• Kadalasang naaabot ng request ang server. Karaniwang hinaharangan ng CORS ang code mo sa pagbasa ng response, hindi ang server sa pagtanggap ng request. Maaaring na-save ang isang POST kahit may nakita kang error.
• Browser lang ang nagpapatupad nito. Binabalewala ng curl, Postman at server-side code ang CORS nang buo. Kaya walang kahulugan ang "gumagana sa Postman" pagdating sa CORS.

Hakbang 1: Basahin ang eksaktong error

Buksan ang developer tools (right-click → Inspect), pumunta sa Console, at basahin ang buong mensahe. Ipinapakita ng pananalita ng Chrome kung aling problema ang mayroon ka:

Pagkatapos, buksan ang Network tab, hanapin ang pumalpak na request (at anumang OPTIONS request bago nito), at tingnan ang status code at response headers nito.

Tingnan muna ang status code. Maraming "CORS error" ay totoong server error na nagkukunwari. Kapag nag-crash ang server o nagbalik ng 404, madalas na walang CORS headers ang error response nito, kaya iniuulat ng browser ang CORS sa halip na ang totoong problema. Ayusin ang 500 o 404, at maaaring mawala na ang CORS error.

Hakbang 2: Pagpasyahan kung dapat bang tawagin ng browser ang API na iyon

Bago magdagdag ng headers, itanong: dapat ba talagang tawagin ng browser ang API na ito?

• Third-party API na nangangailangan ng secret key (OpenAI, Stripe secret key, karamihan ng email services) ay hindi dapat tawagin mula sa browser. Makikita ng bawat bisita ang key. Tawagin ito mula sa backend mo, at mawawala ang CORS problema, dahil hindi sakop ng CORS ang server-to-server requests. Tingnan ang paano panatilihing ligtas ang API keys.
• Third-party API na hindi mo kontrolado na walang CORS headers ay hindi maaayos mula sa panig mo. Tawagin ito mula sa backend mo.
• Sariling API mo ay maaayos sa pamamagitan ng tamang configuration. Magpatuloy sa ibaba.

Hakbang 3: Ayusin ito sa server mo

Dapat magdagdag ang server ng tamang headers sa mga response nito, kasama ang mga error response.

Para sa aktwal na request, magpadala ng:

• Access-Control-Allow-Origin: https://myapp.com (eksaktong origin ng frontend mo, walang trailing slash)
• Vary: Origin, kung nakadepende ang halaga sa kung aling origin ang nagtanong

Para sa preflight na OPTIONS request, tumugon ng matagumpay na status (200 o 204) at:

• Access-Control-Allow-Origin: https://myapp.com
• Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE
• Access-Control-Allow-Headers: Content-Type, Authorization (bawat custom header na ipinapadala mo)
• Opsyonal na Access-Control-Max-Age: 600, para ma-cache ng browser ang preflight nang ilang sandali

Karamihan ng framework ay may package o setting na gumagawa nito. Sa Express, ang cors package; sa FastAPI, ang CORSMiddleware; sa ASP.NET Core, ang AddCors; sa Spring, ang @CrossOrigin o CORS configuration. Isang karaniwang setup sa Express:

import cors from "cors";

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

Ilagay ang CORS handling bago ang mga route at authentication, para hindi tanggihan ng 401 ang mga preflight request (na walang dalang login).

Kapag gumagamit ng AI builder, ilarawan nang tiyak ang setup:

Tumatawag ang frontend sa https://myapp.com sa API sa https://api.myapp.com at nakakakuha ng "Response to preflight request doesn't pass access control check". I-configure ang CORS sa API para payagan nang eksakto ang https://myapp.com at ang preview origin, payagan ang GET, POST, PATCH, DELETE na may Content-Type at Authorization headers, pangasiwaan ang OPTIONS bago ang auth, at isama ang CORS headers sa mga error response din.

Hakbang 4: Pangasiwaan ang cookies at credentials

Kung nagpapadala ang frontend mo ng cookies (halimbawa, login session) sa ibang origin, dapat magkasundo ang dalawang panig:

• Itinatakda ng frontend ang credentials: "include" sa fetch, o withCredentials: true sa axios.
• Nagpapadala ang server ng Access-Control-Allow-Credentials: true.
• Dapat eksaktong origin ang Access-Control-Allow-Origin ng server, hindi *.

Kailangan ng cross-site cookies ang SameSite=None; Secure, at may ilang browser na mas mahigpit pang naglilimita sa third-party cookies. Isa pang dahilan para piliin ang paraan sa Hakbang 5.

Hakbang 5: Iwasan ang CORS gamit ang same-origin setup

Madalas, ang pinakamalinis na ayos ay huwag nang gumawa ng cross-origin requests. Ihain ang API mula sa parehong origin ng page, halimbawa sa https://myapp.com/api/...:

• Sa development, kayang mag-proxy ng karamihan ng dev server. Maipapasa ng server.proxy setting ng Vite ang /api sa backend mo sa ibang port, kaya iisang origin lang ang kinakausap ng browser.
• Sa production, i-route ang /api papunta sa backend sa pamamagitan ng rewrite o proxy settings ng host mo, o ihain ang frontend at API mula sa iisang server.

Pagkatapos, tatawag ang frontend sa relative na path gaya ng fetch("/api/orders"). Walang cross-origin request, walang cross-origin preflight, at walang problema sa cookies. Hindi mo rin kailangang i-hard-code ang API domain na nagkakaiba sa pagitan ng preview at production.

Palitan ang frontend para tumawag sa backend gamit ang relative na /api paths sa halip na buong URL, at mag-set up ng dev proxy para ipasa ang /api sa API server. Pagkatapos, alisin ang anumang CORS settings na hindi na kailangan.

Ang hindi dapat gawin

• mode: "no-cors" sa fetch. Hindi ito nagla-laktaw ng anuman; nagbibigay ito sa code mo ng walang laman at hindi mababasang response.
• Mga browser extension na nagpapatay ng CORS. Binabago lang nila ang browser mo. Makikita pa rin ng bawat bisita ang error.
• Mga pampublikong "CORS proxy" services para sa totoong app. Nababasa at nababago nila ang lahat ng dumadaan sa kanila, at bumababagsak sila.
• Access-Control-Allow-Origin: * sa API na gumagamit ng login. Hindi ito gumagana kasama ng credentials, at maling default ito para sa pribadong datos.
• Pagbabalik ng anumang Origin header na may credentials na pinapayagan. Pinapayagan nito ang anumang website na gumawa ng naka-log-in na request sa ngalan ng users mo. Gumamit ng allowlist.

Mga karaniwang sanhi sa mga app na ginawa ng AI

CORS sa Mythex

Kapag may website at API server ang isang Mythex project, parehong tumatakbo ang mga ito bilang services sa iisang project, at maaari kang lumipat sa pagitan nila sa preview. Ang paghingi sa agent na tumawag ang frontend sa backend sa pamamagitan ng relative na /api path, na nagpo-proxy sa development, ay umiiwas sa karamihan ng CORS problema. Kung kailangan mo talaga ng cross-origin calls, ibigay sa agent ang eksaktong error mula sa console at ang mga origin na kasangkot. Suriin ang resulta sa na-publish na app din, dahil iba ang address nito sa preview. Tingnan ang Multi-service apps at API backends sa docs, at ang aming mga gabay sa pag-debug ng app na ginawa ng AI at frontend vs backend.

Checklist ng CORS

• Nabasa ang buong console error at ang status code ng pumalpak na request
• Naalis ang posibilidad ng nakatagong 404 o 500
• Ang mga API na may secret key ay tinatawag mula sa backend, hindi sa browser
• Nagpapadala ang server ng Access-Control-Allow-Origin na may eksaktong pinapayagang origin
• Nasasagot ang OPTIONS preflight na may pinapayagang method at header, bago ang auth
• Nasa mga error response din ang CORS headers
• Credentials: eksaktong origin, Allow-Credentials: true, at tamang cookie settings
• Sakop ang preview, na-publish, at custom-domain na origin, o gumagamit ng relative na /api paths
• Walang no-cors, pampublikong proxy, o shortcut na nagre-reflect ng anumang origin

Mga tanong