CORS ભૂલો કેવી રીતે ઠીક કરવી (અને તે કેમ થાય છે)

CORS ભૂલનો અર્થ થાય છે કે તમારા વેબ પેજે બીજા ઓરિજિન (બીજું ડોમેન, પોર્ટ કે પ્રોટોકોલ) પરથી પ્રતિસાદ વાંચવાનો પ્રયાસ કર્યો, અને તે સર્વરે એમ કહેતા હેડર મોકલ્યા નથી કે તે મંજૂર છે. બ્રાઉઝર વપરાશકર્તાઓને બચાવવા પ્રતિસાદ અવરોધે છે. તમે તેને સર્વર પર ઠીક કરો છો, તમારી સાઇટના ઓરિજિન માટે Access-Control-Allow-Origin હેડર પાછું આપીને અને OPTIONS પ્રીફ્લાઇટ વિનંતીઓ સંભાળીને, અથવા તે જ ઓરિજિન પર તમારા પોતાના બૅકએન્ડ દ્વારા વિનંતી મોકલીને તેને ટાળો છો.

વેબ ડેવલપમેન્ટમાં તે સૌથી ગૂંચવણભરી ભૂલોમાંની એક છે, કારણ કે વિનંતી ઘણીવાર સર્વર સુધી બરાબર પહોંચે છે. આ માર્ગદર્શિકા સમજાવે છે કે શું થઈ રહ્યું છે અને દરેક પ્રકાર કેવી રીતે ઠીક કરવો.

“ઓરિજિન” નો અર્થ

ઓરિજિન એટલે પ્રોટોકોલ, ડોમેન અને પોર્ટનું સંયોજન:

URL	ઓરિજિન
`https://myapp.com/dashboard`	`https://myapp.com`
`https://api.myapp.com/users`	`https://api.myapp.com` (અલગ સબડોમેન, એટલે અલગ ઓરિજિન)
`http://localhost:5173`	`http://localhost:5173`
`http://localhost:3000`	`http://localhost:3000` (અલગ પોર્ટ, એટલે અલગ ઓરિજિન)

બ્રાઉઝર સમાન-ઓરિજિન નીતિ અનુસરે છે: પેજ પરનું JavaScript પોતાના ઓરિજિનના પ્રતિસાદ મુક્તપણે વાંચી શકે છે, પણ બીજાના નહીં. CORS (Cross-Origin Resource Sharing) એ વ્યવસ્થા છે જે સર્વરને ઑપ્ટ-ઇન કરવા દે છે: “મારા પ્રતિસાદ આ ઓરિજિનના પેજ વાંચી શકે છે.”

બે પરિણામો લોકોને આશ્ચર્યચકિત કરે છે:

વિનંતી ઘણીવાર સર્વર સુધી પહોંચે છે. CORS સામાન્ય રીતે તમારા કોડને પ્રતિસાદ વાંચતા અટકાવે છે, સર્વરને વિનંતી મળતી નથી એવું નહીં. ભૂલ દેખાઈ હોવા છતાં POST સાચવાઈ ગયું હોઈ શકે છે.
ફક્ત બ્રાઉઝર તેને લાગુ કરે છે. curl, Postman અને સર્વર-સાઇડ કોડ CORS ને સંપૂર્ણપણે અવગણે છે. એટલે “Postman માં ચાલે છે” એ CORS વિશે કશું કહેતું નથી.

પગલું 1: ચોક્કસ ભૂલ વાંચો

ડેવલપર ટૂલ્સ ખોલો (રાઇટ-ક્લિક → Inspect), Console પર જાઓ, અને સંપૂર્ણ સંદેશ વાંચો. Chrome ની ભાષા કહે છે કે તમારી સમસ્યા કઈ છે:

સંદેશમાં શામેલ	શું ખોટું છે
`No 'Access-Control-Allow-Origin' header is present`	સર્વરે હેડર બિલકુલ મોકલ્યું નથી, અથવા તમારા CORS કોડ સુધી પહોંચતા પહેલાં વિનંતી નિષ્ફળ ગઈ (જેમ કે 404 અથવા 500)
`The 'Access-Control-Allow-Origin' header has a value '...' that is not equal to the supplied origin`	સર્વર તમારા સિવાયના બીજા ઓરિજિનને મંજૂરી આપે છે
`Response to preflight request doesn't pass access control check`	`OPTIONS` પ્રીફ્લાઇટ નિષ્ફળ ગઈ
`...must not be the wildcard '*' when the request's credentials mode is 'include'`	તમે કૂકી મોકલો છો, અને સર્વરે `*` સાથે જવાબ આપ્યો
`Request header field authorization is not allowed`	સર્વરે `Access-Control-Allow-Headers` માં તે હેડર યાદીમાં મૂક્યું નથી

પછી Network ટૅબ ખોલો, નિષ્ફળ વિનંતી (અને તેની પહેલાંની કોઈ પણ OPTIONS વિનંતી) શોધો, અને તેનો સ્ટેટસ કોડ અને પ્રતિસાદ હેડર જુઓ.

પહેલાં સ્ટેટસ કોડ તપાસો. ઘણી “CORS ભૂલો” ખરેખર છૂપાવેલી સર્વર ભૂલ હોય છે. જો સર્વર ક્રેશ થાય કે 404 આપે, તો તેના ભૂલ પ્રતિસાદમાં ઘણીવાર CORS હેડર હોતા નથી, એટલે બ્રાઉઝર સાચી સમસ્યાને બદલે CORS જણાવે છે. 500 કે 404 ઠીક કરો, અને CORS ભૂલ કદાચ ગાયબ થઈ જશે.

પગલું 2: નક્કી કરો કે તમારે બ્રાઉઝરથી તે API કૉલ કરવો જોઈએ કે નહીં

હેડર ઉમેરતા પહેલાં પૂછો: શું બ્રાઉઝરે આ API સીધું કૉલ કરવો જોઈએ?

સિક્રેટ કી જોઈતી ત્રીજા પક્ષની API (OpenAI, Stripe સિક્રેટ કી, મોટા ભાગની ઇમેઇલ સેવાઓ) ક્યારેય બ્રાઉઝરથી કૉલ ન થવી જોઈએ. કી દરેક મુલાકાતીને દેખાશે. તેના બદલે તમારા બૅકએન્ડથી કૉલ કરો, અને CORS સમસ્યા ગાયબ થઈ જશે, કારણ કે સર્વર-થી-સર્વર વિનંતીઓ CORS ને આધીન નથી. જુઓ API કી સુરક્ષિત કેવી રીતે રાખવી.
ત્રીજા પક્ષની API જે તમે નિયંત્રિત કરતા નથી અને CORS હેડર મોકલતી નથી, તે તમારી બાજુથી ઠીક થઈ શકતી નથી. તેને તમારા બૅકએન્ડથી કૉલ કરો.
તમારી પોતાની API યોગ્ય રીતે ગોઠવીને ઠીક થઈ શકે છે. નીચે ચાલુ રાખો.

પગલું 3: તમારા સર્વર પર ઠીક કરો

સર્વરે તેના પ્રતિસાદોમાં, ભૂલ પ્રતિસાદો સહિત, યોગ્ય હેડર ઉમેરવા જોઈએ.

વાસ્તવિક વિનંતી માટે, મોકલો:

Access-Control-Allow-Origin: https://myapp.com (તમારા ફ્રન્ટએન્ડનું બરાબર ઓરિજિન, અંતે સ્લૅશ વિના)
Vary: Origin, જો કિંમત કયા ઓરિજિને પૂછ્યું તેના પર આધાર રાખે

પ્રીફ્લાઇટ OPTIONS વિનંતી માટે, સફળતા સ્ટેટસ (200 અથવા 204) અને આ સાથે જવાબ આપો:

Access-Control-Allow-Origin: https://myapp.com
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization (તમે મોકલો તે દરેક કસ્ટમ હેડર)
વૈકલ્પિક રીતે Access-Control-Max-Age: 600, જેથી બ્રાઉઝર પ્રીફ્લાઇટને થોડા સમય માટે કેશ કરે

મોટા ભાગના ફ્રેમવર્કમાં આ કરવા માટે પેકેજ કે સેટિંગ હોય છે. Express માં cors પેકેજ; FastAPI માં CORSMiddleware; ASP.NET Core માં AddCors; Spring માં @CrossOrigin અથવા CORS કન્ફિગરેશન. Express નું એક સામાન્ય સેટઅપ:

import cors from "cors";

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

CORS હેન્ડલિંગ તમારા રૂટ અને ઑથેન્ટિકેશન પહેલાં મૂકો, જેથી પ્રીફ્લાઇટ વિનંતીઓ (જેમાં લૉગિન હોતું નથી) 401 સાથે નકારાય નહીં.

AI બિલ્ડર સાથે, સેટઅપ ચોક્કસ રીતે વર્ણવો:

https://myapp.com પરનું ફ્રન્ટએન્ડ https://api.myapp.com પરની API કૉલ કરે છે અને “Response to preflight request doesn't pass access control check” મળે છે. API પર CORS એવી રીતે ગોઠવો કે બરાબર https://myapp.com અને પ્રિવ્યૂ ઓરિજિનને મંજૂરી મળે, Content-Type અને Authorization હેડર સાથે GET, POST, PATCH, DELETE મંજૂર કરો, auth પહેલાં OPTIONS સંભાળો, અને ભૂલ પ્રતિસાદોમાં પણ CORS હેડર સામેલ કરો.

પગલું 4: કૂકી અને ક્રેડેન્શિયલ સંભાળો

જો તમારું ફ્રન્ટએન્ડ બીજા ઓરિજિનને કૂકી (જેમ કે લૉગિન સેશન) મોકલે, તો બંને બાજુએ સંમત થવું જોઈએ:

ફ્રન્ટએન્ડ fetch પર credentials: "include" સેટ કરે, અથવા axios માં withCredentials: true.
સર્વર Access-Control-Allow-Credentials: true મોકલે.
સર્વરનું Access-Control-Allow-Origin બરાબર ઓરિજિન હોવું જોઈએ, * નહીં.

ક્રોસ-સાઇટ કૂકીને કૂકી પર SameSite=None; Secure પણ જોઈએ, અને કેટલાક બ્રાઉઝર ત્રીજા પક્ષની કૂકી વધુ મર્યાદિત કરે છે. પગલું 5 ની રીત પસંદ કરવાનું વધુ એક કારણ એ છે.

પગલું 5: સમાન-ઓરિજિન સેટઅપથી CORS ટાળો

ઘણીવાર સૌથી સ્વચ્છ ઉકેલ એ છે કે બિલકુલ ક્રોસ-ઓરિજિન વિનંતીઓ ન કરવી. API ને પેજના જ ઓરિજિન પરથી પીરસો, જેમ કે https://myapp.com/api/... પર:

ડેવલપમેન્ટમાં, મોટા ભાગના ડેવ સર્વર પ્રોક્સી કરી શકે છે. Vite નું server.proxy સેટિંગ /api ને બીજા પોર્ટ પરના તમારા બૅકએન્ડ પર મોકલી શકે છે, એટલે બ્રાઉઝર ફક્ત એક જ ઓરિજિન સાથે વાત કરે છે.
પ્રોડક્શનમાં, તમારા હોસ્ટના rewrite કે પ્રોક્સી સેટિંગ દ્વારા /api ને બૅકએન્ડ પર રૂટ કરો, અથવા ફ્રન્ટએન્ડ અને API ને એક જ સર્વર પરથી પીરસો.

પછી ફ્રન્ટએન્ડ fetch("/api/orders") જેવો સાપેક્ષ પાથ કૉલ કરે છે. ત્યાં કોઈ ક્રોસ-ઓરિજિન વિનંતી નથી, ઓરિજિનો વચ્ચે પ્રીફ્લાઇટ નથી, અને કૂકીની કોઈ ઝંઝટ નથી. તેનો અર્થ એ પણ છે કે તમે પ્રિવ્યૂ અને પ્રોડક્શન વચ્ચે જુદું પડતું API ડોમેન હાર્ડ-કોડ કરતા નથી.

ફ્રન્ટએન્ડને પૂર્ણ URL ને બદલે સાપેક્ષ /api પાથ વડે બૅકએન્ડ કૉલ કરવા બદલો, અને ડેવ પ્રોક્સી સેટ કરો જેથી /api API સર્વર પર ફૉરવર્ડ થાય. પછી હવે જરૂરી ન હોય તેવી કોઈ પણ CORS સેટિંગ દૂર કરો.

શું ન કરવું

fetch માં mode: "no-cors". તે કંઈ બાયપાસ કરતું નથી; તે તમારા કોડને ખાલી, ન વાંચી શકાય તેવો પ્રતિસાદ આપે છે.
CORS બંધ કરતા બ્રાઉઝર એક્સ્ટેન્શન. તે ફક્ત તમારું બ્રાઉઝર બદલે છે. દરેક મુલાકાતીને હજી ભૂલ દેખાય છે.
વાસ્તવિક એપ માટે જાહેર “CORS પ્રોક્સી” સેવાઓ. તેમની મારફતે પસાર થતું બધું તે વાંચી અને બદલી શકે છે, અને તે બંધ પણ પડે છે.
લૉગિન વાપરતી API પર Access-Control-Allow-Origin: *. ક્રેડેન્શિયલ સાથે તે કોઈ પણ રીતે કામ કરતું નથી, અને ખાનગી ડેટા માટે તે ખોટો ડિફૉલ્ટ છે.
ક્રેડેન્શિયલ મંજૂર હોય ત્યારે કોઈ પણ Origin હેડર પાછું પ્રતિબિંબિત કરવું. તે કોઈ પણ વેબસાઇટને તમારા વપરાશકર્તાઓ વતી લૉગ-ઇન થયેલી વિનંતીઓ કરવા દે છે. મંજૂર યાદી (allowlist) વાપરો.

AI વડે બનેલી એપમાં સામાન્ય કારણો

પરિસ્થિતિ	ઉકેલ
ફ્રન્ટએન્ડ સિક્રેટ કી સાથે ત્રીજા પક્ષની API કૉલ કરે છે	કૉલને બૅકએન્ડ પર ખસેડો
પ્રિવ્યૂમાં ચાલે, પ્રકાશિત ડોમેન પર નિષ્ફળ	પ્રકાશિત અને કસ્ટમ-ડોમેન ઓરિજિન મંજૂર યાદીમાં ઉમેરો, અથવા સાપેક્ષ `/api` પાથ વાપરો
ફક્ત POST, PUT કે DELETE પર ભૂલ	પ્રીફ્લાઇટ સંભાળાઈ નથી; `OPTIONS` હેન્ડલિંગ અને મંજૂર હેડર ઉમેરો
લૉગિન ઉમેર્યા પછી ભૂલ દેખાઈ	ક્રેડેન્શિયલને બરાબર ઓરિજિન અને `Allow-Credentials` જોઈએ
“CORS ભૂલ” પણ Network ટૅબ 500 બતાવે	પહેલાં સર્વર ભૂલ ઠીક કરો
API URL `localhost` પર હાર્ડ-કોડ	સાપેક્ષ પાથ અથવા દરેક એન્વાયર્નમેન્ટ માટે સેટિંગ વાપરો

Mythex માં CORS

જ્યારે Mythex પ્રોજેક્ટમાં વેબસાઇટ અને API સર્વર હોય, ત્યારે બંને એક જ પ્રોજેક્ટમાં સેવાઓ તરીકે ચાલે છે, અને તમે પ્રિવ્યૂમાં બંને વચ્ચે સ્વિચ કરી શકો છો. એજન્ટને ફ્રન્ટએન્ડ બૅકએન્ડને સાપેક્ષ /api પાથ દ્વારા કૉલ કરે, જે ડેવલપમેન્ટમાં પ્રોક્સી થાય, એવું કરવા કહેવાથી મોટા ભાગની CORS સમસ્યાઓ ટળે છે. જો તમને ખરેખર ક્રોસ-ઓરિજિન કૉલ જોઈએ, તો એજન્ટને કન્સોલમાંથી ચોક્કસ ભૂલ અને સામેલ ઓરિજિન આપો. પરિણામ પ્રકાશિત એપ પર પણ તપાસો, કારણ કે તેનું સરનામું પ્રિવ્યૂથી અલગ છે. ડૉક્સમાં Multi-service apps અને API backends જુઓ, અને અમારી માર્ગદર્શિકાઓ AI વડે બનેલી એપ ડિબગ કરવી અને ફ્રન્ટએન્ડ વિરુદ્ધ બૅકએન્ડ.

CORS ચેકલિસ્ટ

સંપૂર્ણ કન્સોલ ભૂલ અને નિષ્ફળ વિનંતીનો સ્ટેટસ કોડ વાંચ્યો
છુપાયેલી 404 કે 500 નકારી
સિક્રેટ-કી API બ્રાઉઝરને બદલે બૅકએન્ડથી કૉલ થાય છે
સર્વર બરાબર મંજૂર ઓરિજિન સાથે Access-Control-Allow-Origin મોકલે છે
OPTIONS પ્રીફ્લાઇટ મંજૂર પદ્ધતિઓ અને હેડર સાથે, auth પહેલાં જવાબ અપાય છે
ભૂલ પ્રતિસાદોમાં CORS હેડર હાજર
ક્રેડેન્શિયલ: બરાબર ઓરિજિન, Allow-Credentials: true, યોગ્ય કૂકી સેટિંગ
પ્રિવ્યૂ, પ્રકાશિત અને કસ્ટમ-ડોમેન ઓરિજિન બધા આવરી લીધા, અથવા સાપેક્ષ /api પાથ વાપર્યા
no-cors, જાહેર પ્રોક્સી, કે કોઈ પણ ઓરિજિન પ્રતિબિંબિત કરવાના શૉર્ટકટ નથી

પ્રશ્નો

CORS ભૂલનો અર્થ શું છે?

તમારા પેજે, જે એક ઓરિજિન પરથી લોડ થયું, બીજા ઓરિજિનનો પ્રતિસાદ વાંચવાનો પ્રયાસ કર્યો, અને તે સર્વરના પ્રતિસાદમાં તેને મંજૂરી આપતા હેડર નહોતા. બ્રાઉઝર તમારા કોડને પ્રતિસાદ વાંચતા અટકાવે છે. ઉકેલ સર્વર પર છે, અથવા વિનંતી કેવી રીતે રૂટ થાય છે તેમાં, ફ્રન્ટએન્ડ કોડમાં નહીં.

શું ફ્રન્ટએન્ડમાંથી CORS ભૂલ ઠીક કરી શકાય?

યોગ્ય રીતે નહીં. mode: 'no-cors' જેવી સેટિંગ ફક્ત પ્રતિસાદને તમારા કોડથી છુપાવે છે. તમે સર્વરને યોગ્ય Access-Control-Allow-Origin હેડર મોકલવા બનાવીને, અથવા તમારા પોતાના બૅકએન્ડ કે સમાન-ઓરિજિન પ્રોક્સી પરથી API કૉલ કરીને તેને ઠીક કરો છો.

શું Access-Control-Allow-Origin: * સુરક્ષિત છે?

કોઈ પણ વાંચી શકે તેવા જાહેર ડેટા માટે ઠીક છે, જેમ કે લૉગિન વિના જાહેર API. તે કૂકી કે અન્ય ક્રેડેન્શિયલ સાથે વાપરી શકાતું નથી, અને ખાનગી API માટે તમારે મંજૂર ઓરિજિનની ચોક્કસ યાદી આપવી જોઈએ.

મારી વિનંતી Postman કે curl માં કેમ ચાલે છે પણ બ્રાઉઝરમાં નહીં?

CORS ફક્ત બ્રાઉઝર દ્વારા લાગુ થાય છે. Postman અને curl જેવા ટૂલ તેને લાગુ કરતા નથી, એટલે વિનંતી ત્યાં સફળ થઈ શકે અને પેજનું JavaScript તેને કરે ત્યારે હજી અવરોધાઈ શકે.

પ્રીફ્લાઇટ વિનંતી શું છે?

સાદી ન હોય તેવી વિનંતીઓ માટે, જેમ કે JSON POST અથવા Authorization હેડરવાળી વિનંતી, બ્રાઉઝર પહેલાં OPTIONS વિનંતી મોકલે છે અને સર્વરને પૂછે છે કે કઈ પદ્ધતિઓ અને હેડર મંજૂર છે. જો એ OPTIONS વિનંતી નિષ્ફળ જાય અથવા યોગ્ય હેડર ન હોય, તો વાસ્તવિક વિનંતી ક્યારેય મોકલાતી નથી.