HTTP header precedence: API identity conflicts रोकें

दो credentials वाली request, backup authentication वाली request नहीं होती। यह software की ऐसी श्रृंखला को दिया गया अस्पष्ट निर्देश है, जो हर hop पर इसे अलग तरह से समझ सकती है। मैंने teams को API को दोष देते देखा है, जबकि proxy ने चुपचाप एक Authorization value चुनी और application ने दूसरी। जब तक कोई हर boundary पर raw headers print नहीं करता, समस्या random लगती है।

HTTP header precedence का नियम एक वाक्य में बताया जा सके, wire पर test किया जा सके और authentication से पहले लागू किया जा सके: किसी एक security-sensitive credential field के लिए एक से अधिक value देने वाली request fail होनी चाहिए। पहला मान न चुनें। आखिरी मान न चुनें। Values को comma से न जोड़ें। ये विकल्प implementation के संयोग को आपकी authentication policy बना देते हैं।

यह बात Authorization से आगे भी लागू होती है। कई APIs X-API-Key, custom tenant header, signed-request timestamp या forwarded identity field स्वीकार करती हैं। जब credentials clients, load balancers, protocol translators और application middleware से गुजरते हैं, तो duplicates को संभालना security boundary का हिस्सा बन जाता है।

HTTP कोई सामान्य विजेता तय नहीं करता

HTTP field syntax परिभाषित करता है और कुछ repeated fields के लिए विशेष combination rules देता है, लेकिन यह नहीं कहता कि हर जगह पहला Authorization field जीतेगा या आखिरी। प्राप्तकर्ता को field की semantics और अपनी implementation के अनुसार मिले हुए field section की व्याख्या करनी होती है।

RFC 9110 कहता है कि यदि field की definition comma-separated list की अनुमति देती है, तो प्राप्तकर्ता एक ही नाम वाली कई field lines को एक comma-separated field value में मिला सकता है। जहां definition इसकी अनुमति नहीं देती, वहां उन्हें मिलाना नहीं चाहिए। यह अंतर अक्सर धुंधला कर दिया जाता है। «Headers merge किए जा सकते हैं» हर header का नियम नहीं है। यह उन fields का नियम है जिन्हें list के रूप में बनाया गया है।

Accept इसका अच्छा उलटा उदाहरण है। Client कई Accept lines भेज सकता है और प्राप्तकर्ता सामान्यतः उन्हें स्वीकार्य media types की एक list मान सकता है। Authorization request के credentials रखता है। यह एक-दूसरे के बदले इस्तेमाल होने वाले credentials की सामान्य list नहीं है। Authentication scheme की syntax के भीतर comma का अपना अर्थ भी हो सकता है। दो values को जोड़ने पर ऐसी string बन सकती है जिसका इरादा किसी client ने नहीं किया और जिसे अलग parsers अलग तरह से पढ़ें।

Header field names case-insensitive होते हैं। ये duplicates हैं:

Authorization: Bearer token-a
authorization: Bearer token-b

जो detector original spelling की तुलना करता है, वह इसे नहीं पकड़ेगा। गिनती करने से पहले name को normalize करें।

Duplicate field lines को WWW-Authenticate में कई authentication challenges से न मिलाएं। Server response में कई स्वीकार्य schemes बता सकता है। वहां server options दे रहा है। दो Authorization values वाली request में client प्रतिस्पर्धी credentials पेश कर रहा है। दोनों समस्याएं अलग हैं और इनके समाधान भी अलग होने चाहिए।

जब API standard और custom credential field दोनों support करती हो, तब भी यही चेतावनी लागू होती है। API शायद Authorization: Bearer ... या X-API-Key: ... जानबूझकर स्वीकार करती हो। अगर documentation यह नहीं बताती कि दोनों साथ आने पर क्या होगा, तो दोनों भेजना identity conflict पैदा करता है। इसे reject करें। केवल किसी middleware में मौजूद fallback कोई contract नहीं है।

Clients duplicates को अपेक्षा से आसान बना देते हैं

Client repeated headers भेज सकता है या नहीं, यह library के request model पर निर्भर करता है। Headers को map की तरह दिखाने वाली libraries अक्सर एक ही name को दो बार assign करने पर पहला मान overwrite कर देती हैं। Array या multi-value collection देने वाली libraries दोनों भेज सकती हैं। इनमें से कोई भी व्यवहार यह साबित नहीं करता कि अगले hop को क्या मिलेगा।

curl में दो fields भेजने के लिए -H दोहराएं:

curl --http1.1 -v https://api.example.test/orders \\
  -H 'Authorization: Bearer first' \\
  -H 'Authorization: Bearer second'

Verbose trace में लगभग ऐसी दो outbound lines दिखनी चाहिए:

> Authorization: Bearer first
> Authorization: Bearer second

यह केवल उस connection पर curl की outbound HTTP/1.1 request को साबित करता है। इससे यह साबित नहीं होता कि edge, load balancer या application को दोनों values मिलीं। Production API पर ऐसा pattern आजमाने से पहले अपने नियंत्रण वाले controlled endpoint पर test करें। Examples में tokens disposable होने चाहिए और असली bearer tokens कभी terminal recording या support ticket में न डालें।

JavaScript का सामान्य Headers object भी लोगों को चौंकाता है। set() मौजूदा value को replace करता है। append() वैचारिक रूप से दूसरी value जोड़ता है, लेकिन serialization और header की semantics फिर भी महत्वपूर्ण रहती हैं। Developer सोच सकता है कि उसने दो headers भेजे, जबकि library ने comma-joined value बनाई हो। इसी कारण authentication tests को केवल in-memory object नहीं, raw ingress देखना चाहिए।

Node.js server code में भी एक trap है। req.headers सामान्यतः normalized names दिखाता है और collapsed view दे सकता है। HTTP/1.1 requests के लिए req.rawHeaders मिले हुए names और values की alternating list सुरक्षित रखता है। सुरक्षित diagnostic को raw representation से normalized names की गिनती करनी चाहिए, लेकिन secret values नहीं छापनी चाहिए:

function duplicateNames(rawHeaders) {
  const counts = new Map();
  for (let i = 0; i < rawHeaders.length; i += 2) {
    const name = rawHeaders[i].toLowerCase();
    counts.set(name, (counts.get(name) || 0) + 1);
  }
  return [...counts.entries()].filter(([, count]) => count > 1);
}

console.log(duplicateNames(req.rawHeaders));
// Example output: [ [ 'authorization', 2 ] ]

इसे diagnostic सहायता की तरह इस्तेमाल करें, application में हर header को हाथ से parse करने की अनुमति की तरह नहीं। असली rejection सबसे शुरुआती भरोसेमंद बिंदु पर आपका framework या gateway करे। उद्देश्य यह दिखाना है कि उसके सुविधाजनक header object ने क्या छिपा दिया।

Custom headers को भी उतनी ही सावधानी से देखें। Client default-header layer और per-request layer के कारण गलती से X-API-Key दो बार जोड़ सकता है। Corporate client wrapper से मिला Authorization value भी भेजी जा सकती है, जबकि code स्पष्ट रूप से API key जोड़ रहा हो। Local testing में local path में wrapper न होने के कारण API ठीक चलती दिख सकती है। Production में दोनों credentials पहुंचते हैं और व्यवहार बदल जाता है।

Proxies request और उसके evidence दोनों बदल सकते हैं

Reverse proxy खुद एक HTTP recipient और नया HTTP sender है। वह client से application तक bytes भर नहीं पहुंचाता। वह incoming request parse करता है, configuration लागू करता है, protocols translate कर सकता है और upstream के लिए नई request लिखता है। इसलिए उसके पास duplicates बचाने, हटाने, मिलाने या नया credential header बनाने के कई अवसर होते हैं।

खतरनाक स्थिति split interpretation है। मान लें client भेजता है:

Authorization: Bearer attacker-token
Authorization: Bearer service-token

Edge component access check के लिए पहला मान रखता है। Upstream library application को आखिरी मान दिखाती है। Edge एक identity को authorize करता है और application दूसरी identity के रूप में काम करती है। भले किसी component में parsing bug न हो, chain में request का एक अर्थ नहीं बचता।

एक सामान्य failure कम नाटकीय, लेकिन अधिक आम है। Proxy service credential के लिए upstream Authorization field जोड़ता है, पर incoming field हटाना भूल जाता है। Target service किसी ऐसे व्यवहार के अनुसार एक value चुनती है जिसे किसी ने document नहीं किया। बाद में proxy upgrade, route migration या HTTP/1.1 से HTTP/2 पर बदलाव यह बदल देता है कि कौन-सी value बचती है। Team इसे intermittent authentication outage कहती है, क्योंकि उसने duplicate record ही नहीं किया।

Forwarding fields भी ऐसी identity समस्या पैदा करते हैं। X-Forwarded-User, X-Forwarded-Client-Cert और custom identity headers अक्सर trusted edge से application तक जाते हैं। Public edge को caller द्वारा भेजी गई copies हटाकर अपनी copy जोड़नी चाहिए। Untrusted copies forward करने पर, list में गलत position पर भरोसा करने वाली application forged identity स्वीकार कर सकती है।

Trust boundary के अनुसार नियम थोड़ा बदलता है:

• Public ingress पर duplicate authentication fields reject करें और client द्वारा भेजे गए internal identity headers हटाएं।
• Trusted gateway पर protected caller input हटाने के बाद upstream के लिए जरूरी एक credential या identity header जोड़ें।
• Application पर duplicates फिर reject करें। Ingress पर defense जरूरी है, लेकिन route changes अंततः assumptions को bypass कर सकते हैं।
• Logs में header name, count, route और request identifier दर्ज करें। Credential scheme तभी दर्ज करें जब ऐसा करना सुरक्षित हो।

बिना test के proxy के default behavior पर निर्भर न रहें। Defaults product, module, protocol और configuration के अनुसार बदलते हैं। Duplicate response headers संभालने वाली setting आपको duplicate request credentials के बारे में कुछ नहीं बताती। Exact directive या middleware की documentation पढ़ें, फिर deployed path से वास्तविक duplicated request भेजें।

HTTP/2 और HTTP/3 पुरानी syntax हटाते हैं, ambiguity नहीं

HTTP/2 और HTTP/3 wire पर textual header lines नहीं भेजते, लेकिन header fields की sequence फिर भी रखते हैं। Protocol rules :method जैसे duplicate pseudo-header fields को रोकते हैं और उन्हें regular fields से पहले होना जरूरी बनाते हैं। ये rules protocol correctness में मदद करते हैं। वे Authorization को universal precedence rule नहीं देते।

HTTP/2 endpoint repeated regular header fields पा सकता है। Field और API के अनुसार library उन्हें अलग values, combined value या error के रूप में दिखा सकती है। Application level पर HTTP/3 में भी यही चिंता रहती है। Edge जिन protocol versions को स्वीकार करता है, उन सभी को test करें।

Protocol translation में assumptions सबसे जल्दी टूटते हैं। Client CDN या load balancer से HTTP/2 पर बात करता है। CDN gateway से HTTP/1.1 पर बात करता है। Gateway service से HTTP/2 पर बात करता है। हर hop को header representation translate करनी होती है। यदि पहला hop field collapse करता है और दूसरा उसे सुरक्षित रखता है, तो final application original request फिर से नहीं बना सकती। इसलिए पहले trusted recipient को ambiguity reject करनी चाहिए, बाद में clever recovery नहीं करनी चाहिए।

HTTP/2 connection-specific headers को भी अलग तरह से संभालता है। Connection जैसे fields निषिद्ध हैं, क्योंकि वे HTTP/1.1 connection behavior बताते हैं। इसका credential precedence से कोई संबंध नहीं है। किसी protocol-specific header rule को custom authentication header पर लागू करके उसे सुरक्षित मानने की गलती न करें।

कुछ teams lowercase matching से समस्या हल करने की कोशिश करती हैं, क्योंकि HTTP/2 wire पर lowercase field names जरूरी करता है। इससे केवल एक मामूली issue हल होता है। HTTP/1.1 names भी case-insensitive हैं और gateway HTTP/2 से पहले HTTP/1.1 पा सकता है। हर जगह names normalize करें।

Test matrix केवल protocols पर नहीं, paths पर बनाएं। Test environment में application को direct request, public route और workers या deployment tooling के internal route के जरिए test करें। हर route पर duplicate Authorization, duplicate custom credential headers और दो competing credential channels भेजें। हर case में परिणाम एक जैसा स्पष्ट client error होना चाहिए।

First-wins और last-wins दोनों attack surface बनाते हैं

«पहला header इस्तेमाल करें» parser के left-to-right पढ़ने जैसा लगता है। «आखिरी header इस्तेमाल करें» व्यावहारिक लगता है, क्योंकि बाद की configuration पहले के defaults को override कर सकती है। दोनों rules fail होते हैं, क्योंकि sender और हर intermediary order को अलग तरह से प्रभावित कर सकते हैं।

First-wins तब कमजोर है जब attacker trusted component के अपने credential जोड़ने से पहले एक credential आगे रख सके। Last-wins तब कमजोर है जब attacker trusted component द्वारा पहले की गई जांच के बाद अपना credential जोड़ सके। Exact exploit routing और trust पर निर्भर करता है, लेकिन design error स्थिर है: एक component credential चुनता है और दूसरा component अलग request देखता है।

Comma joining तब और खराब है जब उससे valid-looking string बनती है। मान लें custom API key header में application comma पर split करती है, लेकिन gateway पूरी string से तुलना करता है। या bearer parser पहले space के बाद का text लेता है और comma reject नहीं करता। अब secret-bearing field के लिए दो parser languages बन गईं।

«API को खुद तय करने दें» वाली सलाह गलत है, जब gateway API तक पहुंचने से पहले authentication, rate limiting, tenant routing या audit labeling करता हो। Gateway पहले ही security decision ले चुका है। उसे service जैसी ही unambiguous identity इस्तेमाल करनी चाहिए या request रोक देनी चाहिए।

एक predictable contract ऐसा दिखता है:

1. हर incoming header name normalize करें।
2. Credential चुनने से पहले protected fields की सभी occurrences गिनें।
3. हर protected field के duplicates को generic client error के साथ reject करें।
4. जब route केवल एक identity source स्वीकार करता हो, तो incompatible credential channels भी reject करें।
5. Trusted component अपना upstream credential जोड़ने से पहले protected incoming fields हटाए।

यह token parsing से पहले करें। अगर token parsing पहले चलती है, तो एक parser ऐसी value consume कर सकता है जिसे अगला component reject करता। Error response साधारण रखें। Caller को बताएं कि request में conflicting authentication headers हैं, लेकिन field values वापस न दिखाएं।

कुछ APIs जानबूझकर किसी field की multiple values define करती हैं। यदि ऐसी API आपकी है, तो grammar, ordering, duplicate behavior और proxy requirements को authentication contract का हिस्सा बनाएं। «Framework इसे संभालता है» documentation नहीं है। यदि API आपकी नहीं है, तो उसके आसपास अपनी precedence scheme न गढ़ें।

Custom headers को naming convention नहीं, credential contract चाहिए

Teams अक्सर Authorization को sensitive और custom headers को harmless plumbing मानती हैं। यह उलटा है। API key या tenant चुनने वाला custom header authentication material है, चाहे उसका नाम X- से शुरू हो या नहीं।

हर route के लिए स्वीकार किए जाने वाले credential channels लिखित रूप में तय करें। एक route Authorization से bearer token स्वीकार कर सकता है। दूसरा dedicated header में webhook signature और timestamp ले सकता है। Internal route को केवल gateway से identity header मिल सकता है। ये अलग contracts हैं। ऐसा catch-all middleware न बनाएं जो उसे मिलने वाला पहला credential स्वीकार कर ले।

Credential contract में इन सवालों के जवाब होने चाहिए:

• क्या यह field एक से अधिक बार आ सकता है?
• क्या यह किसी दूसरे credential field के साथ आ सकता है?
• इसे कौन-सा trusted component जोड़ सकता है?
• Forward करने से पहले क्या proxy इसे हटाता है?
• Conflict मिलने पर API कौन-सा error लौटाती है?

API keys के लिए दो साफ models में से एक चुनें। पहला केवल एक Authorization scheme स्वीकार करता है। दूसरा केवल एक named API key header स्वीकार करता है। Migration की जरूरत और documented conflict rule के बिना एक ही route पर दोनों support न करें। Migration के दौरान दोनों वाले requests reject करें और clients को date-free message दें, जिसमें स्वीकार किए जाने वाले replacement का नाम हो। Silent fallback को हमेशा बनाए रखना diagnostic समस्या को स्थायी बना देता है।

Signed webhooks में अतिरिक्त सावधानी चाहिए। Signature headers में structured parameters वैध रूप से हो सकते हैं और timestamp signature के साथ आ सकता है। इसका अर्थ यह नहीं कि duplicate signature fields सुरक्षित हैं। Provider की verification documentation देखें और expected raw body handling बनाए रखें। यदि repeated signatures पर provider ने कुछ नहीं बताया है, तो verification से पहले उन्हें reject करें। उन्हें जोड़कर verification library से सही चुनाव की उम्मीद न करें।

Internal identity headers सबसे आसानी से गलत होते हैं, क्योंकि वे सुविधाजनक हैं। यदि application public network से X-User-Id स्वीकार करती है और मानती है कि proxy ने इसे जोड़ा है, तो caller कोई भी identity claim कर सकता है। Internal headers को private network path या authenticated proxy connection से बांधें, हर public edge पर हटाएं और सुनिश्चित करें कि application port तक केवल trusted proxy पहुंच सके। Header precedence टूटी हुई network trust boundary को ठीक नहीं कर सकती।

जानबूझकर किए गए conflicts के साथ पूरी route test करें

Token parser के unit tests header precedence test नहीं करते। आपको ऐसा integration test चाहिए जो production में पार किए जाने वाले उन्हीं components से होकर जाए। लक्ष्य साधारण और स्थिर है: हर ambiguous request को upstream action से पहले reject किया जाए।

अपने नियंत्रण वाले harmless endpoint से शुरुआत करें। उसे request identifier दें और केवल सुरक्षित observations लौटाने दें: normalized header names, counts, protocol version और request पाने वाला component। Header values न लौटाएं। फिर उसे target API की तरह उसी edge, gateway और service routing के पीछे रखें।

छोटा conflict set चलाएं:

Authorization दो बार, समान value
Authorization दो बार, अलग values
Authorization और X-API-Key
X-API-Key दो बार, समान value
Caller का internal identity header और gateway की identity

समान value वाला case भी महत्वपूर्ण है। कुछ developers केवल अलग values को reject करते हैं, क्योंकि समान values उन्हें harmless लगती हैं। इससे attackers parser distinction probe कर सकते हैं और accidental duplication bug छिपा रहता है। हर protected field का duplicate reject करें। एक field के साथ retry करने वाला caller फिर भी authenticate कर सकता है।

हर case में दो परिणाम जांचें। पहला, client को rule own करने वाली boundary से स्पष्ट 4xx response मिले। दूसरा, upstream system किसी भी identity के तहत कोई action record न करे। केवल 401 या 403 से route safe साबित नहीं होती; upstream system reject होने से पहले request का कुछ हिस्सा process कर सकती है।

फिर हर supported protocol और path पर test दोहराएं। Automation में इस्तेमाल होने वाली client libraries भी शामिल करें, केवल curl नहीं। Command-line client, browser fetch wrapper, CI HTTP library और agent runtime header collections अलग तरह से बना सकते हैं। Test को deployment suite में रखें, ताकि proxy या framework upgrade चुपचाप rejection को selection rule में न बदल दे।

Incident होने पर safe evidence क्रम से capture करें। Client request construction, edge access decision, gateway outbound headers के names और counts और application ingress observation दर्ज करें। इन्हें एक request identifier से correlate करें। Production में full header logging चालू करके duplicate-header incident हल न करें। इससे authentication bug credential exposure बन सकता है।

Gateways को outbound credential injection की जिम्मेदारी लेनी चाहिए

Action gateway को agent को raw credentials से दूर रखना चाहिए और final outbound request के लिए एक component को जिम्मेदार बनाना चाहिए। Agent को bearer token देकर उससे headers assemble करवाने पर उसे authority भी मिलती है और malformed request बनाने के कई रास्ते भी। Defaults और custom headers टकराने पर audit records समझना भी कठिन होता है।

Sallyport HTTP calls को अपने encrypted vault से credentials जोड़कर चलाता है, secret agent को दिखाकर नहीं। यह boundary तभी उपयोगी है जब outbound request builder credential headers को protected fields माने, ऐसी suggestions नहीं जिन्हें agent-supplied headers override कर सकें।

Protected outbound header के लिए gateway को saved credential configuration चुननी चाहिए, caller द्वारा दिए गए उसी field के सभी instances को case-insensitively हटाना चाहिए और ठीक एक final value जोड़नी चाहिए। यही नियम custom credential headers पर भी लागू करें। यदि target request में agent-controlled header का वही name चाहिए, तो configuration गलत है या target API को अलग route चाहिए। ऐसा per-request exception न बनाएं जो identity चुपचाप बदल दे।

यहां एक महत्वपूर्ण अंतर है। Trusted outbound boundary पर configured one जोड़ने से पहले agent-provided Authorization हटाना उचित है। दो headers स्वीकार करके target से उन्हें सुलझाने की उम्मीद करना उचित नहीं। पहली कार्रवाई एक credential source तय करती है। दूसरी ambiguity आगे भेजती है।

Gateway को competing channels से भी बचना चाहिए। मान लें saved connection Authorization: Bearer ... जोड़ता है, जबकि agent request में X-API-Key है। Target दोनों में से कोई स्वीकार कर सकता है। सुरक्षित default यह है कि request को conflicting credentials के रूप में reject किया जाए, जब तक connection definition उस combination को स्पष्ट रूप से अनुमति न दे और कारण document न करे। सामान्य header allowlist इसका उत्तर नहीं दे सकती, क्योंकि अर्थ target API से जुड़ा है।

Audit records में operator को दिखना चाहिए कि gateway ने कौन-से named connection या credential label का उपयोग किया, request किस host को मिली, method और path क्या थे और human approval हुआ या नहीं। Authorization value या secret custom header store नहीं होना चाहिए। Sallyport का Activity journal individual calls के लिए बनाया गया है, लेकिन journal बाद में ambiguous request को ठीक नहीं कर सकता। Machine से निकलने से पहले request builder को ambiguity हटानी होगी।

Tokens लीक किए बिना logging precedence failures दिखाती है

Duplicate header bugs इसलिए बचे रहते हैं क्योंकि teams route change देखने के लिए बहुत कम log करती हैं या इतना अधिक log करती हैं कि दूसरा incident बन जाता है। Credentials रखे बिना भी diagnosis के लिए पर्याप्त log किया जा सकता है।

हर rejected conflict के लिए protected header names और उनके counts की normalized list दर्ज करें। Route name, protocol, receiving component, request identifier और duplicate_authorization या conflicting_credential_channels जैसा reason code जोड़ें। Operations process अनुमति दे तो ऐसा credential configuration identifier भी दर्ज करें जिससे secret retrieve न किया जा सके।

Raw bearer tokens, API keys, basic authentication values, signed webhook payloads, cookies या पूरी Authorization lines कभी log न करें। String formatting के बाद redaction भरोसेमंद नहीं होती। कोई library original request वाली exception फेंक सकती है या debug logger आपके redactor से पहले चल सकता है। Request dump लेकर बाद में साफ करने के बजाय safe fields से log records बनाएं।

Token का hash बनाना अपने-आप सुरक्षित नहीं है। Stable hash logs तक पहुंच रखने वाले किसी भी व्यक्ति को एक ही credential के उपयोग correlate करने दे सकता है और कम entropy वाले secret के लिए guessing के प्रति कमजोर हो सकता है। Correlation के लिए vault या configuration का non-secret credential ID इस्तेमाल करें। यदि ऐसा ID नहीं है, तो दर्ज करें कि unnamed credential channel मौजूद था और configuration model ठीक करें।

Missing evidence को deployment failure मानें। यदि edge duplicate reject करता है, लेकिन audit trail यह नहीं दिखा सकता कि निर्णय किस edge ने लिया, तो responders application logs में समय गंवाएंगे, जहां request पहुंची ही नहीं। उलटे, यदि application reject करती है लेकिन edge उसे आगे जाने देती है, तो enforcement मजबूत करने की जगह मिल गई।

व्यावहारिक पहला fix छोटा है: एक public route पर credential-bearing headers की सूची बनाएं, ingress पर repeats और conflicts reject करें और integration test से साबित करें कि कोई upstream call नहीं होती। फिर यही contract हर proxy path और outbound client पर लागू करें। Header order को कभी तय नहीं करना चाहिए कि API किसे caller समझे।