🌐 Detecting your location…

2026 में CORS त्रुटि ‘कोई एक्सेस-कंट्रोल-अनुमति-उत्पत्ति नहीं’ हेडर को कैसे ठीक करें

⏱️2 min read  ·  227 words

आप अपने फ्रंटएंड से एक एपीआई के लिए अनुरोध करते हैं और ब्राउज़र इसे ब्लॉक कर देता है:Access to fetch at '...' from origin '...' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. यह वेब विकास में सबसे आम और गलत समझी जाने वाली त्रुटियों में से एक है। यहां बताया गया है कि वास्तव में इसका कारण क्या है और इसे सही तरीके से कैसे ठीक किया जाए।

CORS वास्तव में क्या है

CORS (क्रॉस-ओरिजिनल रिसोर्स शेयरिंग) एक ब्राउज़र सुरक्षा तंत्र है। जब आपका जावास्क्रिप्ट चालू होhttps://app.example.com makes a request to https://api.other.comसे अनुरोध करता है , ब्राउज़र इसे एक क्रॉस-ओरिजिन अनुरोध मानता है और सर्वर को प्रतिक्रिया हेडर के माध्यम से इसे स्पष्ट रूप से अनुमति देने की आवश्यकता होती है। यदि सर्वरAccess-Control-Allow-Originनहीं भेजता है हेडर जिसमें आपका मूल शामिल है, ब्राउज़र प्रतिक्रिया को ब्लॉक कर देता है – भले ही सर्वर ने अनुरोध को सफलतापूर्वक संसाधित किया हो।

मुख्य अंतर्दृष्टि:CORS को ब्राउज़र द्वारा लागू किया जाता है, और फिक्स सर्वर पर रहता है, आपके फ्रंटएंड कोड में नहीं। आप केवल अपना फ़ेच कॉल बदलकर CORS त्रुटि को ठीक नहीं कर सकते।

समाधान 1: हेडर भेजने के लिए सर्वर को कॉन्फ़िगर करें

सही समाधान एपीआई को सही सीओआरएस हेडर के साथ प्रतिक्रिया देना है। एक्सप्रेस में,corsका उपयोग करें मिडलवेयर:

const cors = require('cors');

app.use(cors({
  origin: 'https://app.example.com',
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization'],
  credentials: true
}));

सेटorigin आपके फ़्रंटएंड की सटीक उत्पत्ति के लिए। वाइल्डकार्ड का प्रयोग न करें* उत्पादन में यदि आप क्रेडेंशियल्स (कुकीज़ या ऑथ हेडर) भेजते हैं – ब्राउज़रAccess-Control-Allow-Origin: *के संयोजन को अस्वीकार कर देते हैं credentials: true.

के साथ फिक्स 2: प्रीफ़्लाइट (विकल्प) अनुरोधों को संभालें

किसी भी अनुरोध के लिए जो एक साधारण GET/POST नहीं है – उदाहरण के लिए जोContent-Type: application/jsonभेजता है या एकAuthorization हेडर – ब्राउज़र सबसे पहले एक प्रीफ़्लाइटOPTIONSभेजता है अनुमति मांगने का अनुरोध करें. आपके सर्वर को उचित हेडर के साथ इसका जवाब देना होगा।cors उपरोक्त मिडलवेयर इसे स्वचालित रूप से संभालता है, लेकिन यदि आप हेडर मैन्युअल रूप से सेट करते हैं, तो आपको विकल्पों को स्पष्ट रूप से संभालना होगा:

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');
  if (req.method === 'OPTIONS') {
    return res.sendStatus(204); // Respond to preflight, do not fall through
  }
  next();
});

एक सामान्य गलती विकल्प प्रीफ़्लाइट का जवाब देने में विफल होना है – ब्राउज़र इसे भेजता है, कोई वैध CORS प्रतिक्रिया नहीं मिलती है, और वास्तविक अनुरोध को किए जाने से पहले ही ब्लॉक कर देता है।

समाधान 3: मूल से सटीक मिलान करें

मूल बिल्कुल मेल खाना चाहिए – प्रोटोकॉल, डोमेन और पोर्ट सभी मायने रखते हैं। ये सभी ब्राउज़र के अलग-अलग मूल हैं:

उत्पत्ति यह भिन्न क्यों है
http://localhost:3000 https
से भिन्न प्रोटोकॉल https://localhost:3000 http
से भिन्न प्रोटोकॉल https://example.com :3000
से भिन्न पोर्ट https://www.example.com www उपडोमेन एपेक्स

से भिन्न है यदि आपकी अनुमत उत्पत्तिhttps://example.comहै लेकिन आपका ऐपhttps://www.example.comसे लोड होता है , CORS इसे ब्लॉक कर देता है। ऐप द्वारा वास्तव में उपयोग किए जाने वाले प्रत्येक मूल को अनुमति दें, या किसी एक को सामान्य करें।

समाधान 4: एकाधिक फ़्रंटएंड के लिए डायनामिक ओरिजिन का उपयोग करें

यदि कई मूलों को एक्सेस (स्टेजिंग, प्रोडक्शन, लोकलहोस्ट) की आवश्यकता है, तो किसी एक को हार्डकोड करने के बजाय एक अनुमति सूची के विरुद्ध मान्य करें:

const allowed = [
  'https://app.example.com',
  'https://staging.example.com',
  'http://localhost:3000'
];

app.use(cors({
  origin: (origin, callback) => {
    if (!origin || allowed.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error('Not allowed by CORS'));
    }
  },
  credentials: true
}));

समाधान 5: स्थानीय विकास के लिए, प्रॉक्सी का उपयोग करें

विकास के दौरान, आप अपने डेव सर्वर के माध्यम से एपीआई अनुरोधों को प्रॉक्सी करके सीओआरएस को दरकिनार कर सकते हैं ताकि वे समान मूल के दिखाई दें। विटे में:

// vite.config.js
export default {
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:5000',
        changeOrigin: true
      }
    }
  }
};

अब आपका फ्रंटएंड कॉल करता है/api/... अपने स्वयं के मूल पर और डेव सर्वर इसे अग्रेषित करता है। यह एक विकास सुविधा है, उत्पादन समाधान नहीं – उत्पादन को अभी भी एपीआई पर उचित सीओआरएस हेडर की आवश्यकता है।

क्या नहीं करना चाहिए

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

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

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

प्रश्न: क्या मैं फ्रंटएंड से सीओआरएस को ठीक कर सकता हूं?
उत्तर: नहीं, CORS हेडर अनुरोध का जवाब देने वाले सर्वर से आने चाहिए। एकमात्र फ्रंटएंड-साइड वर्कअराउंड एक डेव प्रॉक्सी है, जो विकास के दौरान अनुरोधों को समान-मूल बनाता है।

प्रश्न: मेरा प्रीफ़्लाइट विकल्प अनुरोध विफल क्यों हो जाता है?
उ: सर्वर सही CORS हेडर और 2xx स्थिति के साथ OPTIONS पर प्रतिक्रिया नहीं दे रहा है। सुनिश्चित करें कि आपका CORS मिडलवेयर आपके रूट से पहले चलता है, या OPTIONS को स्पष्ट रूप से संभालें और 204 लौटाएँ।

प्रश्न: क्रेडेंशियल्स: ट्रू मूल ‘*’ से क्यों टूट जाता है?
उ: जब अनुमत मूल वाइल्डकार्ड हो तो ब्राउज़र क्रेडेंशियल (कुकीज़, ऑथ) भेजने से मना करते हैं*. जब आपको क्रेडेंशियल्स की आवश्यकता हो तो सटीक मूल निर्दिष्ट करें।

प्रश्न: हेडर वहां है लेकिन यह अभी भी विफल है। क्यों?
ए: जांचें कि मूल बिल्कुल मेल खाता है (प्रोटोकॉल, डोमेन, पोर्ट), कि विकल्प प्रीफ्लाइट को संभाला जाता है, और सामने एक प्रॉक्सी या सीडीएन हेडर को अलग नहीं कर रहा है। नेटवर्क टैब में वास्तविक प्रतिक्रिया हेडर का निरीक्षण करें।

निष्कर्ष

“कोई एक्सेस-कंट्रोल-अनुमति-उत्पत्ति हेडर मौजूद नहीं है” त्रुटि का अर्थ है कि ब्राउज़र ने क्रॉस-ओरिजिन प्रतिक्रिया को अवरुद्ध कर दिया है क्योंकिसर्वर ने आपकी उत्पत्ति की अनुमति नहीं दी. फिक्स हमेशा सर्वर पर होता है:सही भेजेंAccess-Control-Allow-Origin हेडर, विकल्प प्रीफ़्लाइट को संभालें, मूल से बिल्कुल मेल करें, और कभी भी क्रेडेंशियल्स वाले वाइल्डकार्ड का उपयोग न करें. स्थानीय विकास के लिए, एक डेव प्रॉक्सी समस्या को साफ़-साफ़ टाल देता है। एक बार जब सर्वर आपके सटीक मूल के लिए सही हेडर लौटाता है और प्रीफ़्लाइट अनुरोधों का जवाब देता है, तो त्रुटि गायब हो जाती है और आपके अनुरोध पूरे हो जाते हैं।

MD Rafikul Islam

Written by

MD Rafikul Islam is a software developer and the editor of TechPulse. He writes about developer tooling, hardware, and the practical decisions that come up in day-to-day engineering work — which laptop to buy, which framework to commit to, why a build broke at 2am. He tests the tools he writes about and says plainly when something is not worth the money. Corrections and corrections requests are welcome at rony.yf25@gmail.com.

✍️ Leave a Comment

Your email address will not be published. Required fields are marked *

🌐 Read in:🇬🇧 English🇩🇪 Deutsch🇧🇷 Português🇸🇦 العربية🇮🇳 हिन्दी🇧🇩 বাংলা