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 ला परवानगी द्या, 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 हेडर परत प्रतिबिंबित करणे. त्यामुळे कोणतीही वेबसाइट तुमच्या वापरकर्त्यांच्या वतीने लॉग इन केलेल्या रिक्वेस्ट्स करू शकते. परवानगी-यादी वापरा.

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 प्रीफ्लाइटला परवानगी असलेल्या मेथड्स आणि हेडर्ससह, ऑथच्या आधी उत्तर दिले
त्रुटी प्रतिसादांवर 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 रिक्वेस्ट अयशस्वी झाली किंवा योग्य हेडर्स नसतील तर खरी रिक्वेस्ट कधीच पाठवली जात नाही.