CORS एरर कैसे ठीक करें (और ये क्यों आती है)

CORS एरर का मतलब है कि आपके वेब पेज ने किसी दूसरे origin (दूसरा domain, port या protocol) से जवाब पढ़ने की कोशिश की, और उस सर्वर ने ऐसे headers नहीं भेजे जो बताएं कि यह अनुमति है। ब्राउज़र उपयोगकर्ताओं की सुरक्षा के लिए उस जवाब को रोक देता है। इसे आप सर्वर पर ठीक करते हैं, अपनी साइट के origin के लिए Access-Control-Allow-Origin header लौटाकर और OPTIONS preflight requests को संभालकर, या अपने ही backend के जरिए same origin पर request भेजकर इससे बच सकते हैं।

यह वेब डेवलपमेंट की सबसे उलझाने वाली एररों में से एक है, क्योंकि request अक्सर सर्वर तक ठीक पहुंच जाती है। यह गाइड बताती है कि क्या हो रहा है और हर तरह की एरर कैसे ठीक करें।

"origin" का मतलब क्या है

origin protocol, domain और port का संयोजन है:

ब्राउज़र same-origin policy का पालन करते हैं: पेज का JavaScript अपने origin से आने वाले जवाब आराम से पढ़ सकता है, लेकिन दूसरे origin से नहीं। CORS (Cross-Origin Resource Sharing) वह व्यवस्था है जिसमें सर्वर खुद अनुमति देता है: "मेरे जवाब इन origins के पेज पढ़ सकते हैं।"

दो बातें लोगों को अक्सर चौंकाती हैं:

• request अक्सर सर्वर तक पहुंच जाती है। CORS आमतौर पर आपके कोड को जवाब पढ़ने से रोकता है, सर्वर को request मिलने से नहीं रोकता। POST सेव भी हो सकता है, भले ही आपको एरर दिखे।
• इसे सिर्फ़ browsers लागू करते हैं। curl, Postman और server-side कोड CORS को बिल्कुल नज़रअंदाज़ करते हैं। इसीलिए "Postman में काम करता है" से CORS के बारे में कुछ पता नहीं चलता।

चरण 1: सटीक एरर पढ़ें

Developer tools खोलें (right-click → Inspect), Console पर जाएं और पूरा मैसेज पढ़ें। Chrome के शब्द बताते हैं कि समस्या कौन सी है:

फिर Network tab खोलें, फेल होने वाली request (और उससे पहले की कोई OPTIONS request) ढूंढें, और उसका status code और response headers देखें।

पहले status code देखें। कई "CORS एरर" असल में छुपी हुई सर्वर एरर होती हैं। अगर सर्वर क्रैश होता है या 404 लौटाता है, तो उसके जवाब में अक्सर CORS headers नहीं होते, इसलिए ब्राउज़र असली समस्या की जगह CORS की शिकायत करता है। 500 या 404 ठीक करें, और CORS एरर भी गायब हो सकती है।

चरण 2: तय करें कि क्या browser से उस API को कॉल करना चाहिए

Headers जोड़ने से पहले पूछें: क्या browser को इस API को सीधे कॉल करना चाहिए?

• Secret key वाली तीसरे पक्ष की API (OpenAI, Stripe की secret key, ज्यादातर email services) को कभी browser से कॉल नहीं करना चाहिए। Key हर visitor को दिख जाएगी। इसे अपने backend से कॉल करें, तब CORS की समस्या खत्म हो जाती है, क्योंकि server-to-server requests पर CORS लागू नहीं होता। देखें API keys सुरक्षित कैसे रखें।
• तीसरे पक्ष की API जो आपके नियंत्रण में नहीं है और CORS headers नहीं भेजती, उसे आपकी तरफ़ से ठीक नहीं किया जा सकता। उसे अपने backend से कॉल करें।
• आपकी अपनी API को सही तरह से कॉन्फ़िगर करके ठीक किया जा सकता है। आगे पढ़ें।

चरण 3: अपने सर्वर पर ठीक करें

सर्वर को अपने हर जवाब में सही headers जोड़ने होंगे, error जवाबों में भी।

असली request के लिए भेजें:

• Access-Control-Allow-Origin: https://myapp.com (आपके frontend का सटीक origin, आखिर में slash के बिना)
• Vary: Origin, अगर मान इस पर निर्भर करता है कि origin कौन सा है

preflight OPTIONS request के लिए सफलता का status (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 (हर custom header जो आप भेजते हैं)
• वैकल्पिक: Access-Control-Max-Age: 600, ताकि ब्राउज़र preflight को कुछ समय के लिए cache कर ले

ज्यादातर frameworks में इसके लिए package या setting होती है। Express में cors package; FastAPI में CORSMiddleware; ASP.NET Core में AddCors; Spring में @CrossOrigin या CORS configuration। एक सामान्य Express setup:

import cors from "cors";

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

CORS हैंडलिंग को अपने routes और authentication से पहले रखें, ताकि preflight requests (जिनमें login नहीं होता) 401 से रद्द न हों।

AI builder के साथ setup को सटीक रूप से समझाएं:

https://myapp.com पर चल रहा frontend https://api.myapp.com पर API को कॉल करता है और "Response to preflight request doesn't pass access control check" एरर आती है। API पर CORS ऐसे कॉन्फ़िगर करें कि वह ठीक https://myapp.com और preview origin को अनुमति दे, GET, POST, PATCH, DELETE के साथ Content-Type और Authorization headers की अनुमति दे, auth से पहले OPTIONS संभाले, और error जवाबों में भी CORS headers शामिल करे।

चरण 4: cookies और credentials संभालें

अगर आपका frontend किसी दूसरे origin पर cookies (जैसे login session) भेजता है, तो दोनों तरफ़ की सेटिंग मेल खानी चाहिए:

• Frontend fetch पर credentials: "include" सेट करे, या axios में withCredentials: true।
• सर्वर Access-Control-Allow-Credentials: true भेजे।
• सर्वर का Access-Control-Allow-Origin सटीक origin हो, * नहीं।

Cross-site cookies पर SameSite=None; Secure भी लगाना होगा, और कुछ ब्राउज़र third-party cookies पर और सख्ती करते हैं। यह एक और कारण है कि चरण 5 वाला तरीका बेहतर है।

चरण 5: same-origin सेटअप से CORS से बचें

अक्सर सबसे साफ़ हल यह है कि cross-origin requests बनाएं ही नहीं। API को उसी origin से चलाएं जहां पेज है, जैसे https://myapp.com/api/... पर:

• Development में, ज्यादातर dev servers proxy कर सकते हैं। Vite की server.proxy सेटिंग /api को दूसरे port पर चल रहे backend की ओर भेज सकती है, ताकि ब्राउज़र सिर्फ़ एक ही origin से बात करे।
• Production में, host की rewrite या proxy सेटिंग से /api को backend की ओर route करें, या frontend और API को एक ही server से दें।

तब frontend fetch("/api/orders") जैसा relative path कॉल करता है। कोई cross-origin request नहीं, origins के बीच कोई preflight नहीं, और cookies की परेशानी नहीं। इसका एक और फ़ायदा यह है कि आपको API का domain हार्ड-कोड नहीं करना पड़ता, जो preview और production में अलग होता है।

Frontend को पूरे URL की बजाय relative /api paths से backend को कॉल करने दें, और dev proxy सेट करें ताकि /api API server पर फ़ॉरवर्ड हो। फिर वे सारी CORS सेटिंग्स हटा दें जिनकी अब ज़रूरत नहीं है।

क्या न करें

• fetch में mode: "no-cors"। यह कुछ भी बाईपास नहीं करता; यह आपके कोड को एक खाली, न पढ़ी जा सकने वाली response देता है।
• Browser extensions जो CORS बंद करते हैं। ये सिर्फ़ आपके ब्राउज़र को बदलते हैं। हर visitor को अब भी एरर दिखेगी।
• Real apps के लिए सार्वजनिक "CORS proxy" services। वे उनसे गुजरने वाले हर डेटा को पढ़ और बदल सकती हैं, और वे कभी भी बंद हो सकती हैं।
• लॉगिन वाली API पर Access-Control-Allow-Origin: *। इसके साथ credentials वैसे भी काम नहीं करतीं, और निजी डेटा के लिए यह गलत डिफ़ॉल्ट है।
• credentials की अनुमति के साथ किसी भी Origin header को वापस लौटाना। इससे कोई भी वेबसाइट आपके उपयोगकर्ताओं की ओर से logged-in requests भेज सकती है। अनुमति की सूची (allowlist) इस्तेमाल करें।

AI-built apps में आम कारण

Mythex में CORS

जब किसी Mythex project में website और API server हों, तो दोनों उसी project में services के रूप में चलते हैं, और आप preview में उनके बीच बदल सकते हैं। एजेंट से कहें कि frontend backend को relative /api path से कॉल करे, जिसे development में proxy किया गया हो। इससे ज्यादातर CORS समस्याएं नहीं आतीं। अगर सच में cross-origin calls चाहिए, तो एजेंट को console की सटीक एरर और शामिल origins बताएं। Published app पर भी नतीजा जांचें, क्योंकि उसका पता preview से अलग होता है। डॉक्स में Multi-service apps और API backends देखें, और हमारी गाइड AI से बने app को debug कैसे करें और frontend बनाम backend भी।

CORS चेकलिस्ट

• पूरी console एरर और फेल होने वाली request का status code पढ़ा
• छुपी हुई 404 या 500 को खारिज किया
• Secret-key वाली APIs browser से नहीं, backend से कॉल होती हैं
• सर्वर सटीक allowed origins के साथ Access-Control-Allow-Origin भेजता है
• OPTIONS preflight allowed methods और headers के साथ, auth से पहले जवाब देता है
• Error जवाबों में भी CORS headers हैं
• Credentials: सटीक origin, Allow-Credentials: true, और सही cookie सेटिंग्स
• Preview, published और custom-domain origins सब शामिल हैं, या relative /api paths इस्तेमाल हो रहे हैं
• no-cors, public proxies, या किसी भी origin को लौटाने वाले shortcuts नहीं हैं

सवाल