एक्सेस-कंट्रोल-अनुमति-उत्पत्ति गुम हेडर सीओआरएस त्रुटि को कैसे ठीक करें

त्रुटिअनुरोधित संसाधन पर कोई ‘एक्सेस-कंट्रोल-अनुमति-उत्पत्ति’ हेडर मौजूद नहीं है सबसे आम CORS त्रुटि है. इसका मतलब है कि ब्राउज़र ने आपके क्रॉस-ओरिजिन अनुरोध को अवरुद्ध कर दिया है क्योंकि सर्वर ने यह नहीं कहा कि इसकी अनुमति है। यहां बताया गया है कि इसे ठीक से कैसे ठीक किया जाए।

ऐसा क्यों होता है

ब्राउज़र सुरक्षा के लिए समान-उत्पत्ति नीति लागू करते हैं –app.example.comपर एक पृष्ठ api.other.comके लिए स्वतंत्र रूप से अनुरोध नहीं कर सकते . क्रॉस-ऑरिजिन अनुरोधों के लिए, सर्वर मेंAccess-Control-Allow-Originशामिल होना चाहिए शीर्षलेख बताता है कि किन मूलों की अनुमति है। यदि यह अनुपलब्ध है, तो ब्राउज़र प्रतिक्रिया को अवरुद्ध कर देता है और यह त्रुटि दिखाता है।

मुख्य बिंदु: इसे ब्राउज़र द्वारा लागू किया जाता है और सर्वर पर ठीक किया जाता है। क्लाइंट इस हेडर को नहीं जोड़ सकता – सर्वर को इसे भेजना होगा।

फिक्स 1: कॉर्स पैकेज के साथ एक्सप्रेस

npm install cors

const cors = require('cors');

// Allow all origins (development only)
app.use(cors());

// ✅ Production: allow specific origin
app.use(cors({
  origin: 'https://app.example.com',
}));

// ✅ Multiple allowed origins
const allowed = ['https://app.example.com', 'https://admin.example.com'];
app.use(cors({
  origin: (origin, callback) => {
    if (!origin || allowed.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error('Not allowed by CORS'));
    }
  },
}));

फिक्स 2: एक्सप्रेस मैनुअल हेडर

app.use((req, res, next) => {
  res.header('Access-Control-Allow-Origin', 'https://app.example.com');
  res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
  res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization');

  // Handle preflight OPTIONS requests
  if (req.method === 'OPTIONS') {
    return res.sendStatus(204);
  }
  next();
});

समाधान 3: Nginx

location /api/ {
    add_header 'Access-Control-Allow-Origin' 'https://app.example.com' always;
    add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
    add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization' always;

    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' 'https://app.example.com';
        add_header 'Access-Control-Max-Age' 86400;
        return 204;
    }

    proxy_pass http://localhost:3000;
}

समाधान 4: क्रेडेंशियल्स (कुकीज़/प्रामाणिक) के साथ

// When sending cookies or auth headers cross-origin:

// Server: exact origin (NOT wildcard) + allow credentials
app.use(cors({
  origin: 'https://app.example.com',   // must be exact, not '*'
  credentials: true,
}));

// Client: include credentials
fetch('https://api.example.com/data', {
  credentials: 'include',
});

// ❌ This combination FAILS:
// origin: '*' with credentials: true
// The browser rejects wildcard origin when credentials are included

विकास प्रॉक्सी विकल्प

// Avoid CORS during development entirely with a dev proxy

// vite.config.ts
export default {
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:3000',
        changeOrigin: true,
      }
    }
  }
};
// Frontend calls /api/... which the dev server proxies to your backend -
// same origin, no CORS. (Production still needs proper CORS headers.)

सामान्य गलतियाँ

// 🐛 Setting CORS headers in BOTH nginx and Express
// Results in duplicate Access-Control-Allow-Origin headers,
// which the browser rejects. Set them in ONE place.

// 🐛 Wildcard with credentials
res.header('Access-Control-Allow-Origin', '*');   // fails with credentials

// 🐛 Forgetting to handle OPTIONS preflight
// PUT/DELETE/JSON requests send a preflight OPTIONS first -
// it must get a valid CORS response too

// 🐛 Trying to fix it in the frontend
// You CANNOT add Access-Control-Allow-Origin from client code -
// it must come from the server

डिबगिंग

# Check what headers the server actually returns
curl -I -H "Origin: https://app.example.com" https://api.example.com/data

# Look for:
# Access-Control-Allow-Origin: https://app.example.com  ← should be present

# If it's missing, the server isn't configured correctly.
# If it's the wrong origin, fix the server's allowed origins.

अक्सर पूछे जाने वाले प्रश्न

प्रश्न: मैं इसे अपने फ्रंटएंड कोड में ठीक क्यों नहीं कर सकता?
उत्तर: CORS ब्राउज़र द्वारा लागू किया जाता है और सर्वर द्वारा नियंत्रित किया जाता है।Access-Control-Allow-Origin हेडर अनुरोध का जवाब देने वाले सर्वर से आना चाहिए। कोई भी फ्रंटएंड कोड इसे नहीं जोड़ सकता – आपको सर्वर को कॉन्फ़िगर करना होगा (या प्रॉक्सी का उपयोग करना होगा)।

प्रश्न: यह पोस्टमैन में क्यों काम करता है लेकिन ब्राउज़र में नहीं?
उत्तर: CORS केवल ब्राउज़रों द्वारा लागू किया जाता है। पोस्टमैन और कर्ल ब्राउज़र की CORS जांच के बिना सीधे अनुरोध करते हैं। यह पुष्टि करता है कि आपका सर्वर काम करता है – आपको बस ब्राउज़र क्लाइंट के लिए CORS हेडर जोड़ने की आवश्यकता है।

प्रश्न: क्या मुझे केवल Access-Control-Allow-Origin: * का उपयोग करना चाहिए?
उत्तर: केवल बिना किसी क्रेडेंशियल वाले वास्तव में सार्वजनिक एपीआई के लिए। प्रमाणीकरण या कुकीज़ वाली किसी भी चीज़ के लिए, आपको सटीक उत्पत्ति निर्दिष्ट करनी होगी (वाइल्डकार्ड क्रेडेंशियल्स के साथ विफल रहता है)। सटीक उत्पत्ति निर्दिष्ट करना भी अधिक सुरक्षित है –*का उपयोग न करें प्रमाणित एपीआई के लिए उत्पादन में।

प्रश्न: मुझे CORS हेडर कहां सेट करना चाहिए – nginx या ऐप?
उत्तर: केवल एक स्थान। यदि आप उन्हें nginx और अपने ऐप दोनों में सेट करते हैं, तो आपको डुप्लिकेट हेडर मिलते हैं, जिन्हें ब्राउज़र अस्वीकार कर देते हैं। एक परत चुनें (आमतौर पर लचीलेपन के लिए ऐप, या यदि आपके पास रिवर्स प्रॉक्सी है तो nginx) और वहां CORS कॉन्फ़िगर करें।

प्रश्न: मेरा POST काम क्यों करता है लेकिन PUT विफल रहता है?
उत्तर: JSON बॉडी या कस्टम हेडर के साथ PUT/DELETE और अनुरोध प्रीफ़्लाइट विकल्प अनुरोध को ट्रिगर करते हैं। आपके सर्वर को मान्य CORS हेडर के साथ OPTIONS का भी जवाब देना होगा। सुनिश्चित करें कि आपका CORS कॉन्फिगरेशन विकल्प विधि को संभालता है, न कि केवल GET/POST को।

निष्कर्ष

“कोई ‘एक्सेस-कंट्रोल-अनुमति-उत्पत्ति’ हेडर मौजूद नहीं है” इसका मतलब है कि सर्वर ने ब्राउज़र को यह नहीं बताया कि आपके क्रॉस-ऑरिजिन अनुरोध की अनुमति है। फिक्स हमेशा सर्वर पर होता है: जोड़ें कॉर्स पैकेज (एक्सप्रेस), मैनुअल हेडर, या nginx कॉन्फिगरेशनAccess-Control-Allow-Originके माध्यम से हेडर , सटीक उत्पत्ति निर्दिष्ट करना (क्रेडेंशियल्स का उपयोग करते समय आवश्यक)। विकल्प प्रीफ़्लाइट अनुरोधों को संभालें, डुप्लिकेट से बचने के लिए CORS को केवल एक परत में सेट करें, और याद रखें कि आप इसे फ्रंटएंड कोड से ठीक नहीं कर सकते। विकास के लिए, एक डेव-सर्वर प्रॉक्सी पूरी तरह से CORS से बचता है – लेकिन उत्पादन के लिए हमेशा उचित सर्वर-साइड CORS हेडर की आवश्यकता होती है।के माध्यम से हेडर , सटीक उत्पत्ति निर्दिष्ट करना (क्रेडेंशियल्स का उपयोग करते समय आवश्यक)। विकल्प प्रीफ़्लाइट अनुरोधों को संभालें, डुप्लिकेट से बचने के लिए CORS को केवल एक परत में सेट करें, और याद रखें कि आप इसे फ्रंटएंड कोड से ठीक नहीं कर सकते। विकास के लिए, एक डेव-सर्वर प्रॉक्सी पूरी तरह से CORS से बचता है – लेकिन उत्पादन के लिए हमेशा उचित सर्वर-साइड CORS हेडर की आवश्यकता होती है।