क्या API subdomain credential boundaries वास्तव में लागू होती हैं?

Hostname स्वामित्व का संकेत नहीं होता। वह destination identity का हिस्सा है और तय करता है कि API credential कहां जाएगा। यदि client के पास एक bearer token है और वह api.example.com, files.example.com, api.eu.example.com और customer.example.com को केवल इसलिए समान मानता है कि उनका suffix एक जैसा है, तो खतरनाक फैसला पहले ही हो चुका है।

यह गलती अक्सर सुविधाजनक architecture के पीछे छिपी रहती है। कंपनी parent domain के नीचे आने वाले सभी नामों की मालिक हो सकती है। DNS कई नामों को एक ही load balancer तक भेज सकता है। Certificates भी सभी नामों को cover कर सकते हैं। इनमें से कोई बात यह साबित नहीं करती कि एक API के लिए जारी credential दूसरे hostname तक पहुंचना चाहिए। Credentials के लिए स्पष्ट destination rule चाहिए, और ऐसे tests चाहिए जो बाद में कोई उस rule को ढीला करे तो विफल हो जाएं।

Hostnames parent domain से trust विरासत में नहीं लेते

api.example.com और admin.example.com एक ही registrable domain साझा कर सकते हैं, लेकिन वे अलग origins हैं। Origin में scheme, host और port शामिल होते हैं। https://api.example.com और https://api.example.com:8443 भी अलग origins हैं। यह अंतर महत्वपूर्ण है, क्योंकि client network destination को authority के आधार पर चुनता है, services के marketing संबंध के आधार पर नहीं।

RFC 9110 HTTP authentication protection space को origin और, यदि मौजूद हो, realm से परिभाषित करता है। यह चेतावनी भी देता है कि केवल realms पर निर्भर रहने से उसी origin के दूसरे resources तक credentials पहुंच सकते हैं। जहां अलग पक्षों को अलग रखना हो, वहां अलग hostnames या ports की सलाह दी जाती है। यह उपयोगी चेतावनी है, लेकिन इसका अर्थ यह नहीं कि एक suffix के नीचे आने वाले सभी नाम एक ही protection space हैं।

Engineers अक्सर तीन अलग बातों को मिला देते हैं:

• Parent domain DNS namespace का नाम देता है।
• Site कुछ browser security rules के लिए संबंधित web origins को समूहित करता है।
• Origin HTTP destination के लिए एक scheme, host और port की पहचान करता है।

केवल पहली दो बातें subdomains को संबंधित दिखाती हैं। आपका API credential dispatcher तीसरी बात का उपयोग करे।

यह तब भी महत्वपूर्ण है जब credential issuer token में व्यापक aud claim रखता हो। Broad audience claim receiving service को बताता है कि वह क्या स्वीकार कर सकती है। वह आपके client को हर ऐसे endpoint पर token भेजने का निर्देश नहीं देता जो उसे स्वीकार कर सकता हो। Distribution को सीमित रखना sender की जिम्मेदारी है।

व्यावहारिक समाधान सरल है: configuration और code review में host binding स्पष्ट रखें। ऐसा credential selector जो केवल credential name स्वीकार करता है, उसके input का आधा हिस्सा गायब है।

चार hostname shapes अलग-अलग तरह से विफल होते हैं

Sibling, vanity, regional और customer-specific domains के लिए अलग test cases रखें। allowed_domains नाम के एक broad field या wildcard पर निर्भर रहने से कम से कम एक गलती छूट जाएगी।

Sibling host intended host के बगल में होता है, जैसे metrics.example.com। वहां shared ingress, पुरानी service या ऐसा internal tool हो सकता है जिसे production credentials नहीं मिलने चाहिए। Generic proxy यदि headers को जस का तस आगे भेजता है, तो जोखिम बढ़ जाता है।

Vanity host api.brand.example या developer.example.com जैसा friendly alias होता है। Rename, acquisition या migration के दौरान ऐसे नाम बनाए जाते हैं। Alias किसी अलग edge पर terminate हो सकता है, अलग telemetry इस्तेमाल कर सकता है या canonical host पर redirect कर सकता है। Browser में एक बार redirect देखकर उसे credential access न दें।

Regional host location और service ownership दोनों बदल सकता है, जैसे api.us.example.com, api.eu.example.com या api.ap-southeast.example.com। Authentication विफल होने से पहले request business data लेकर गलत region तक पहुंच सकती है। 401 response यह साबित नहीं करता कि credential और body वहां भेजना स्वीकार्य था।

Customer-specific host multi-tenant गलती को और गंभीर बना देता है। acme.vendor.example और northwind.vendor.example एक infrastructure से resolve हो सकते हैं, फिर भी हर hostname tenant boundary है। दोनों पर काम करने वाला token central control plane के लिए जानबूझकर बनाया गया हो सकता है, लेकिन tenant-directed requests के लिए वह default credential नहीं बनना चाहिए।

हर category को inventory में लिखें। इन्हें allowed_domains जैसे एक field में न समेटें। Wildcard कठिन निर्णय को हटाता नहीं, केवल नजरों से दूर कर देता है।

Credential selection को पूरी authority से बांधें

सुरक्षित client request authority को एक credential record से map करता है और match न मिलने पर request रोक देता है। Complete authority में scheme, normalized hostname और effective port शामिल होते हैं। सामान्य HTTPS API के लिए configuration सरल रह सकती है, लेकिन unexpected port को token दोबारा इस्तेमाल करके चुपचाप स्वीकार न करें।

credentials:
  billing-production:
    allowed:
      - https://api.billing.example.com:443
    header: Authorization
    scheme: Bearer

  telemetry-eu:
    allowed:
      - https://ingest.eu.example.net:443
    header: X-Write-Key

बात YAML की नहीं है। Token name अकेला पर्याप्त नहीं है। billing-production का एक स्पष्ट destination है और telemetry-eu केवल hostname string बदलने से U.S. endpoint तक leak नहीं हो सकता।

इस pattern से बचें:

const headers = {
  Authorization: `Bearer ${process.env.PRODUCTION_API_TOKEN}`
};

await fetch(userSuppliedUrl, { headers });

यह code unrestricted destination को high-privilege credential से जोड़ देता है। Trusted configuration file पर भी भरोसा पर्याप्त नहीं है। Deployment tooling, environment overrides, pull requests, feature flags और compromised build job उसे बदल सकते हैं।

ऐसा request builder इस्तेमाल करें जो normalized destination match होने तक authenticated request बनाए ही नहीं। URL को real parser से parse करें, https: अनिवार्य करें, hostname को parser के जरिए lowercase और canonicalize करें, फिर scheme, host और port की exact approved authorities से तुलना करें। Match सफल होने के बाद ही authentication header जोड़ें।

host.endsWith("example.com") न लिखें। यह notexample.com को भी स्वीकार करता है। endsWith(".example.com") भी पूरा समाधान नहीं है। इससे हर वर्तमान और भविष्य का subdomain token पा सकता है, जिसमें customer, vendor या भूला हुआ development environment भी शामिल है।

Destination authorization और credential authorization अलग controls हैं। Receiving API out-of-scope token को अस्वीकार कर सकती है, लेकिन sender को token वहां जाने से पहले ही रोकना चाहिए। पहला exposure सीमित करता है, दूसरा access तय करता है। दोनों जरूरी हैं।

Redirect नया destination है

पहला host approved हो सकता है और फिर Location header में vanity name, regional endpoint, object storage या attacker-controlled host भेज सकता है। Client यदि अपने-आप redirect follow करता है, तो हर redirect पर credential या request body भेजने से पहले destination authorization फिर चलनी चाहिए।

libcurl यह अंतर स्पष्ट करता है। Default रूप से वह redirect के दौरान internally generated authentication या explicitly set cookie headers दूसरे host को नहीं भेजता। CURLOPT_UNRESTRICTED_AUTH इस व्यवहार को बदल सकता है। Custom headers के लिए अलग सावधानी चाहिए, क्योंकि library यह नहीं जान सकती कि arbitrary headers में कौन-से secrets हैं।

यहीं अनुभवी teams भी चूकती हैं। वे Basic authentication को standard client से test करती हैं और cross-host redirect सुरक्षित दिखता है। फिर production integration X-Api-Key, Authorization: Bearer या X-Signature जैसे generic headers का उपयोग करती है। Library वह header बनाए रख सकती है, जब तक application उसे हटाए नहीं। एक authentication mechanism का passing test दूसरे के बारे में कुछ नहीं बताता।

Request class के आधार पर redirects संभालें:

• Write operations में redirects अस्वीकार करें, जब तक API contract उन्हें जरूरी न बनाए।
• Read operations में हर redirect target जांचें और target के approved credential record से headers फिर बनाएं।
• Signed requests में final destination अधिकृत होने के बाद signature फिर बनाएं। पहले host की signature कभी forward न करें।
• Uploads में original authorization header pre-signed storage URL को न भेजें। Query signature या form fields पहले से सीमित authority देते हैं।

Redirect test को दूसरे server तक पहुंचने वाले request की जांच करनी चाहिए। केवल final status code देखना पर्याप्त नहीं है। Harmless receiver से आया 200 response यह छिपा सकता है कि उसे production header मिल चुका था। Retries में भी यही अनुशासन रखें। यदि retry नई authority पर जाता है, cached header map हटाकर credential selector फिर चलाएं।

Allowlist पर भरोसा करने से पहले negative test rig बनाएं

महत्वपूर्ण test negative है: credential intended host पर दिखना चाहिए और हर plausible wrong host पर नहीं। दो local HTTPS test servers पर्याप्त हैं। Receiver को केवल sensitive headers की मौजूदगी और नाम दर्ज करने चाहिए, असली values नहीं।

host=api.test.example
path=/v1/ping
authorization=present
x-api-key=absent

Sibling receiver का परिणाम ऐसा होना चाहिए:

host=metrics.test.example
path=/v1/ping
authorization=absent
x-api-key=absent

Actual HTTP client wrapper को test करें, साफ-सुथरे अलग implementation को नहीं। Approved authority और हर गलत authority के साथ normal request() function चलाएं और assert करें कि connection खुलने से पहले error उठे।

इस test के लिए external request-bin service न इस्तेमाल करें। Local receiver सरल है और evidence आपके नियंत्रण में रहता है। Matrix को continuous integration में रखें। isAllowedHost() का unit test उपयोगी है, लेकिन integration test उस regression को पकड़ता है जिसमें host check के बाद किसी lower HTTP layer में default header जोड़ दिया जाता है।

Browser rules agent rules नहीं हैं

Browser terminology agent और backend code में गलत assumptions पैदा करती है। “Same site” में subdomains शामिल हो सकते हैं, जबकि “same origin” में नहीं। Fetch का default credentials: "same-origin" browser fetch को cross-origin requests पर credentials अपने-आप जोड़ने से रोकता है। इससे यह निष्कर्ष नहीं निकलता कि server-side code bearer token को दूसरे subdomain तक नहीं भेज सकता। Backend wrapper, CLI या autonomous agent कोई भी header जोड़ सकता है।

CORS इसे ठीक नहीं करता। CORS मुख्यतः यह नियंत्रित करता है कि browser JavaScript response पढ़ सकती है या नहीं। कभी browser credential भेज देता है और केवल response script को नहीं दिखाता। यह data-loss prevention control नहीं है। Cookies की domain और SameSite rules अलग हैं। Bearer headers में वैसी built-in domain scope नहीं होती। Authorization जोड़ना उस request के लिए explicit निर्णय है।

Customer domains को issuer boundary चाहिए

Central API कई customer endpoints को call कर सकती है, लेकिन credentials में यह स्पष्ट होना चाहिए कि tenant boundary पार करने की अनुमति क्यों है। सबसे सुरक्षित व्यवस्था में हर customer host का अलग narrow credential record होता है। दूसरा विकल्प short-lived token है जिसमें audience और tenant claims हों, जिन्हें destination verify करे, साथ में client allowlist हर permissible host को नाम से दर्ज करे।

Global broad-role token onboarding को आसान बनाता है, लेकिन typo, malicious configuration change या confused agent को दूसरे customer तक पहुंचने देता है। *.customers.example.com को approved pattern बनाकर समस्या हल नहीं होती। देखें कि names कौन बना सकता है, DNS कौन delegate कर सकता है, कौन-से hosts preview environments तक route होते हैं और offboarding के बाद names रहते हैं या नहीं।

Controlled wildcard कुछ मामलों में ठीक हो सकता है, जब per-tenant tokens, enforced tenant claim और authoritative internal tenant registry मौजूद हो। तब wildcard authorization rule नहीं, registry के पीछे की सुविधा है। यदि आप उस registry और उसके failure behavior को नाम से नहीं बता सकते, exact entries इस्तेमाल करें। Private DNS के लिए भी यही बात लागू होती है। payments.prod.internal और payments.dev.internal अलग destinations हैं।

Host checks discovery और normalization के सही क्रम में करें

Service discovery, custom routing और proxy configuration allowlist को चुपचाप bypass कर सकते हैं। Parsed URL authority को policy input बनाएं, उसी authority के लिए TLS connection स्थापित करें और certificate verification बंद न करें। Client peer को authenticate नहीं कर सकता तो यह नहीं जान सकता कि वह intended server तक पहुंचा है।

Forward proxy transport choice है, नया credential destination नहीं, यदि client उसके जरिए approved origin तक TLS स्थापित करता है। TLS terminate करने वाला reverse proxy service boundary का हिस्सा है और API जितनी ही जांच मांगता है। Plaintext authorization headers पाने वाला HTTP proxy credentials तक पहुंच रखता है। इसे केवल infrastructure न कहें।

Internationalized hostnames को standards-compliant URL implementation से normalize करें। https://[email protected]/ जैसे userinfo URLs अस्वीकार करें, क्योंकि credentials logs और histories में leak होते हैं। Fragments अस्वीकार करें और तय करें कि query strings में pre-signed credentials स्वीकार्य हैं या नहीं। सही क्रम है: parse, normalize, destination authorize, credential select, headers बनाएं, connect। बाद में authority बदले तो destination authorization से फिर शुरू करें।

Secret नहीं, decision का audit करें

Audit record में यह दिखना चाहिए कि client ने कौन-सा destination माना और कौन-सा credential rule चुना, लेकिन secret दर्ज नहीं होना चाहिए। Request ID, time, normalized authority, credential record ID, authorization outcome, redirect source और target तथा outcome code रखें। Customer identifiers वाले paths को hash या redact करें। Authorization, custom key headers, signature वाले query strings या पूरी request bodies log न करें।

request_id=01J...
authority=https://api.billing.example.com:443
credential=billing-production
destination_check=allowed
redirect_count=0
result=201

Rejected sibling request में credential=none और destination_check=denied दिखना चाहिए। इससे साबित होता है कि client ने secret चुनने से पहले ही मना कर दिया। Sallyport secret को encrypted vault में रखता है और agent को credential material दिए बिना action का मूल्यांकन करता है। Activity journal और Sessions journal action path की जांच और गलत host-bound request के बाद running agent session revoke करने में मदद करते हैं।

सबसे पहले inventory बनाएं। हर credential के लिए एक intended authority लिखें और एक sibling, vanity या migration name, regional name तथा customer-specific name भी लिखें जिसे credential नहीं मिलना चाहिए। यदि आपका client आज ये negative assertions नहीं कर सकता, तो उसके पास credential boundary नहीं है, केवल एक आशावादी convention है।