SaaS CORS configuration: सुरक्षित origin allowlist guide
Explicit trusted origins, सीमित methods और headers, सुरक्षित credential नियम, सही preflight handling और authentication व CSRF से अलग tests के साथ Cross-Origin Resource Sharing configure करें।
इस मार्गदर्शिका में
SaaS API के लिए CORS सुरक्षित रूप से कैसे configure करें?
CORS browser mechanism है जिसमें server बताता है कि कौन-से web origins browser APIs के जरिए response पढ़ सकते हैं। असली frontend origins से शुरू करें, हर route के लिए जरूरी methods और headers ही allow करें, और credentials केवल सोचे-समझे trusted-origin flow में चालू करें। CORS API caller को authenticate नहीं करता, server-to-server endpoint को सुरक्षित नहीं करता और cookie-authenticated बदलावों के लिए CSRF सुरक्षा की जगह नहीं लेता।
केवल उन्हीं exact origins को allow करें जिन्हें product नियंत्रित करता है
Origin में scheme, host और port शामिल होते हैं; इसलिए production और development origins स्पष्ट entries हों। Incoming Origin header को बिना जाँच लौटाएँ नहीं और ऐसी ढीली suffix matching न रखें जो मिलते-जुलते attacker domain या कब्ज़ाए गए subdomain को स्वीकार कर ले। किसी endpoint के लिए cross-origin browser client समर्थित न हो तो वहाँ permissive CORS header न दें।
Credentials केवल स्पष्ट जरूरत और specific origin के साथ allow करें
Browser को cookies या credentials भेजने हों तो exact approved Access-Control-Allow-Origin और Access-Control-Allow-Credentials: true लौटाएँ। Credentialed browser access के साथ wildcard origin स्वीकार नहीं होता। Allowed request headers व methods को client flow तक सीमित रखें और response header तभी expose करें जब JavaScript को उसे पढ़ना हो।
Preflight, caching और route scope की योजना बनाएँ
Browser अनुमति पूछने के लिए OPTIONS preflight भेज सकता है। केवल जरूरी allow rules लौटाएँ, वास्तविक request पर सामान्य authentication और authorization बनाए रखें, तथा Origin के आधार पर response बदले तो Vary: Origin जोड़ें ताकि shared cache एक origin का response दूसरे को न दे। Policy को route या API group तक सीमित रखें।
| API route | अनुमत browser origin(s) | Methods और headers | Cookie या credentials जरूरी? | Preflight, Vary और auth test |
|---|---|---|---|---|
| Public read-only API | ||||
| Signed-in customer API | ||||
| Partner integration endpoint |
कौन-सी CORS settings अनावश्यक जोखिम बनाती हैं?
संवेदनशील routes पर wildcard और reflection shortcuts से बचें
Access-Control-Allow-Origin: * तभी ठीक है जब response जानबूझकर हर browser origin के लिए सार्वजनिक हो और credentials पर निर्भर न हो। किसी भी मिले हुए origin को echo करना उसे eligible response पढ़ने की अनुमति दे सकता है। Explicit allowlist रखें और origins को informal string matching के बजाय जाँचे हुए URL parser से normalize करें।
CORS को server-side access control से अलग रखें
Non-browser script, mobile app, command-line tool या attacker-controlled server browser CORS policy से नहीं रुकता। Endpoint पर सामान्य authentication, object-level authorization और request validation जरूरी है। Cookie-authenticated state changes पर CORS के बावजूद CSRF token या समकक्ष सुरक्षा रखें।
Local development और preview origins को नियंत्रित रखें
नामित development origins उपयोग करें और अस्थायी preview खत्म होने पर उन्हें हटा दें। ऐसे व्यापक patterns से बचें जो हर tenant subdomain को भरोसेमंद मान लें जबकि users या third parties subdomain बना या कब्ज़ा सकते हों। Production allowlist में origin जोड़ने का अधिकार और review प्रक्रिया लिखें।
Team CORS policy की जाँच और निगरानी कैसे करे?
असल browser में अनुमत और निषिद्ध origins जाँचें
स्वीकृत production frontend, unapproved origin, अलग scheme या port वाला origin और malformed lookalike test करें। देखें कि browser केवल अपेक्षित response पढ़ सकता है, जबकि API खुद identity और permission जाँचता है। Credentialed requests और anonymous public resources को अलग-अलग जाँचें।
Preflight और वास्तविक request दोनों का व्यवहार जाँचें
OPTIONS के बाद intended method व headers चलाएँ, फिर unsupported method या custom header भी आजमाएँ। सफल preflight वास्तविक state-changing request पर checks bypass न करे। जहाँ allowlist से origin लौटाया जाता है, वहाँ Vary header और caching का व्यवहार जाँचें।
हर deployment layer पर प्रभावी headers जाँचें
CDN, gateway और application के बाद response देखें; कई layers विरोधी Access-Control headers जोड़ सकती हैं। Error response और redirects भी जाँचें। संवेदनशील payload log किए बिना policy changes और denied origin patterns दर्ज करें। Domains, partners या customer integrations बदलें तो allowlist फिर देखें।
SaaS CORS के सवाल
क्या CORS किसी को curl से API call करने से रोकता है?
नहीं। CORS तब browser लागू करता है जब web page cross-origin response पढ़ना चाहता है। हर API request पर उचित authentication, authorization और validation फिर भी चाहिए।
क्या cookies के साथ Access-Control-Allow-Origin: * उपयोग कर सकते हैं?
Credentialed CORS response में browser wildcard origin स्वीकार नहीं करता। Cookie वाले cross-origin flow के लिए specific trusted origin allow करें और जरूरत होने पर ही credentials चालू रखें।
क्या exact CORS allowlist CSRF token की जगह लेती है?
नहीं। CORS response पढ़ने की browser अनुमति और कुछ preflighted requests को नियंत्रित करता है। Cookie-authenticated बदलावों के लिए CSRF सुरक्षा रखें और हर request को server पर authorize करें।
क्या हर API route को CORS headers लौटाने चाहिए?
केवल उन routes को जहाँ समर्थित cross-origin browser client है। Policy को जरूरी routes और origins तक सीमित रखें; उपयोग न होने वाले routes पर permissive header exposure बढ़ाता है।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .