# क्वेरी स्ट्रिंग वाले क्रेडेंशियल किसी के पढ़ने से पहले क्यों लीक हो जाते हैं

URL में रखा सीक्रेट पहले ही लंबा चक्कर लगा चुका होता है। API तक पहुंचने से पहले वह क्लाइंट लाइब्रेरी, प्रॉक्सी, एक्सेस लॉग, ट्रेसिंग सिस्टम, ब्राउज़र हिस्ट्री डेटाबेस और एक्सपोर्ट की गई CSV से गुजर सकता है। HTTPS तार पर मौजूद अनुरोध की रक्षा करता है। वह URL संभालने वाली हर मशीन और सेवा की याददाश्त नहीं मिटाता।

इसीलिए कोई स्वायत्त एजेंट टोकन देखे बिना भी क्रेडेंशियल लीक करवा सकता है। यदि एजेंट एक्शन गेटवे से `https://api.example.test/v1/builds?access_token=...` कॉल करने को कहता है, तो गेटवे टोकन को एजेंट ट्रांसक्रिप्ट से बाहर रख सकता है, लेकिन फिर भी ऐसा URL बना देता है जिसे दूसरे सिस्टम आदतन रिकॉर्ड करते हैं। सीक्रेट मॉडल की पहुंच से बाहर गया, मगर बहुत अधिक जगहों तक पहुंच गया।

इसका हल सीक्रेट स्कैनिंग जितना आकर्षक नहीं है। URL में सिर्फ रिसोर्स की पहचान और सामान्य फिल्टर रखें। क्रेडेंशियल को रिक्वेस्ट हेडर में रखें, या प्रोटोकॉल मांगे तो रिक्वेस्ट बॉडी में। फिर सीक्रेट रखने वाला कंपोनेंट उसे सबसे आखिरी संभव क्षण में जोड़े। इससे ऐसा अनुरोध, जिसका नाम लेना, टेस्ट में दोहराना और ऑडिट रिकॉर्ड में रखना सुरक्षित है, उस अनुरोध से अलग रहता है जो ऑथराइजेशन साथ लेकर चलता है।

## URL सिर्फ रास्ता नहीं, एक रिकॉर्ड है

URL को कॉपी, दिखाने, तुलना, कैश, बुकमार्क और लॉग करने के लिए बनाया गया है। यही गुण उसे रिसोर्स की पहचान के लिए उपयोगी और बेयरर सामग्री के लिए बेहद खराब बनाते हैं। क्वेरी पैरामीटर रिक्वेस्ट टारगेट का हिस्सा बनता है, जिसे कई लेयर सामान्य ऑपरेशनल डेटा मानती हैं।

CWE-598 इस कमजोरी को "Use of HTTP Request With Sensitive Query String" कहता है। इसके विवरण में सामान्य लीक रास्ते बताए गए हैं: ब्राउज़र हिस्ट्री, Referer हेडर, वेब लॉग और दूसरे रिकॉर्डिंग स्रोत। समाधान भी सीधा है: संवेदनशील जानकारी को हेडर या रिक्वेस्ट बॉडी में भेजें। इसका अर्थ यह नहीं कि GET मना है। चेतावनी यह है कि URI में सीक्रेट डालने से उसे हासिल कर सकने वाले लोगों और सिस्टमों की संख्या बदल जाती है।

RFC 9110 भी अपनी सिक्योरिटी कंसिडरेशन्स में यही फर्क बताता है। वह चेतावनी देता है कि यूज़र इनपुट से बने URI क्वेरी फील्ड संवेदनशील डेटा ले जा सकते हैं और सर्वर से बना अलग URI बाद के लिंक्स से संवेदनशील डेटा हटा सकता है। API क्रेडेंशियल के लिए मैं एक कदम आगे जाऊंगा: शुरुआत में ही सीक्रेट वाला URI न बनाएं। बाद में बदलने पर पुरानी कॉपियां रह जाती हैं।

कभी URL पैरामीटर को "बस एक API कुंजी" या "सिर्फ थोड़े समय का टोकन" कहा जाता है। कोई भी नाम उसके एक्सपोज़र को नहीं बदलता। लॉग शिपर भेजते समय कम समय का टोकन भी सक्रिय हो सकता है। API कुंजी किसी सीमित एंडपॉइंट की अनुमति दे सकती है, मगर वही एंडपॉइंट डेटा पढ़ने, खर्च बढ़ाने या बेहतर क्रेडेंशियल बनाने के लिए काफी हो सकता है। ऑथराइजेशन डेटा को तब तक सीक्रेट मानें, जब तक उसे जारी करने वाली सेवा कुछ और न कहे।

## एक्सेस लॉग उस हिस्से को सहेजते हैं जिसे लोग भूल जाते हैं

अधिकांश HTTP एक्सेस लॉग में मेथड, रिक्वेस्ट टारगेट, स्टेटस, आकार और समय होते हैं, क्योंकि ट्रैफिक की समस्या समझने के लिए ऑपरेटरों को ये फील्ड चाहिए। रिक्वेस्ट टारगेट में पाथ और क्वेरी स्ट्रिंग शामिल हैं। एक सामान्य लाइन ऐसी दिखती है:

```
203.0.113.24 - - [14/Jun/2026:12:42:18 +0000] "GET /v1/builds?access_token=sk_live_example HTTP/1.1" 200 481
```

नुकसान पहुंचाने वाला हिस्सा कोई असामान्य डिबग सेटिंग नहीं है। यह वही सामान्य फील्ड है जिसमें ऑपरेटर तब खोजता है जब कोई रूट एरर देने लगे। `Authorization` हेडर को रिडैक्ट करना आम है, क्योंकि टीमों को पता होता है कि उसमें सीक्रेट हो सकते हैं। मनमाने क्वेरी नामों को रिडैक्ट करना कठिन है: कोई अपस्ट्रीम इसे `token` कहता है, कोई `api_key`, तीसरा `sig` स्वीकार करता है और चौथा क्रेडेंशियल को साइन किए हुए ब्लॉब में रख देता है।

"हम लॉग रिडैक्ट करते हैं" को उत्तर न मानें, जब तक कोई हर हॉप पर रिडैक्शन के बाद का सटीक रिक्वेस्ट टारगेट, क्वेरी मानों समेत, न दिखा दे। `token` को छिपाने वाला नियम `access_token` छोड़ देगा। `access_token` को छिपाने वाला नियम उस वेंडर को छोड़ देगा जो उसी मान को `key` कहता है। ज्ञात नामों को छिपाने वाला नियम प्री-साइन्ड URL पर कुछ नहीं करता, जहां क्रेडेंशियल कई पैरामीटरों में बंटा होता है।

व्यावहारिक फर्क यह है: हेडर रिडैक्शन सीक्रेट वाले अनुरोध के चारों ओर सुरक्षा है, जबकि हेडर इंजेक्शन URL को सीक्रेट वाला बनने से रोकता है। हेडर के लिए लॉग कंट्रोल फिर भी चाहिए। साथ ही क्वेरी नामों के अपवादों की अंतहीन सूची लिखना बंद किया जा सकता है, जो वेंडर API के पीछे हमेशा चलती रहती है।

## रिवर्स प्रॉक्सी एक अनुरोध को कई रिकॉर्ड में बदल देती है

रिवर्स प्रॉक्सी फॉरवर्ड करने से पहले पूरा अनुरोध देखती है। लोड बैलेंसर, API गेटवे, सर्विस मेश, WAF, CDN एज सर्विस और रिक्वेस्ट लाइफसाइकल को इंस्ट्रूमेंट करने वाले ऑब्ज़र्वेबिलिटी एजेंट भी ऐसा करते हैं। वे सभी एक जैसा फॉर्मेट लॉग नहीं करते, डेटा एक ही अवधि तक नहीं रखते और न ही उसे एक ही अकाउंट में भेजते हैं।

यह इसलिए मायने रखता है कि साफ एप्लिकेशन लॉग बहुत कम साबित करता है। इनग्रेस लॉग में मूल URL हो सकता है। अपस्ट्रीम कनेक्शन सेटअप फेल होने पर प्रॉक्सी एरर लॉग उसे दोहरा सकता है। ट्रेस स्पैन `http.target` या रूट मान जोड़ सकता है। टाइमआउट में मदद चाहिए होने पर सपोर्ट बंडल इनमें से कई फाइलें पैक कर सकता है। हर कॉपी अलग से देखने पर ऑपरेशनल रूप से उचित लगती है। साथ मिलकर वे एक लीक हुई कुंजी को इन्वेंट्री की समस्या बना देती हैं।

टीमें अक्सर इसे ग्लोबल रिडैक्शन फिल्टर से सुलझाने की कोशिश करती हैं। फिल्टर इस्तेमाल करें, मगर उसकी सीमा समझें। फिल्टर तभी काम करता है जब किसी कंपोनेंट को URL मिल चुका हो, उसने उसे सही ढंग से पार्स किया हो और सीक्रेट की हर वर्तनी से मिलान किया हो। इससे URL क्रेडेंशियल बनाए रखने का दबाव भी बनता है, क्योंकि उन्हें हटाने के लिए क्लाइंट कोड बदलना पड़ेगा। लंबे समय का हल कॉल बाउंड्री पर है, जहां क्रेडेंशियल अनुरोध से जुड़ता है।

मान लें कोई एजेंट डिप्लॉयमेंट रिक्वेस्ट बनाता है। वह यह सुरक्षित एक्शन विवरण दे सकता है:

```
GET https://deploy.example.test/v2/releases?project=docs-site&limit=20
credential: deploy-read
```

क्रेडेंशियल रखने वाला गेटवे अपने वॉल्ट में `deploy-read` हल करता है और अपस्ट्रीम को `Authorization: Bearer ...` भेजता है। प्रॉक्सी को फिर भी अनुरोध दिखता है। उसके रिक्वेस्ट टारगेट में `project` और `limit` होते हैं, बेयरर मान नहीं। अगर उसका हेडर लॉग गलती से `Authorization` दिखा दे, तो वह अलग कमी है, जिसका साफ और सीमित टेस्ट हो सकता है। उस कमी को न छिपाएं, पर URL लीक से उसे कई गुना न बढ़ाएं।

## ब्राउज़र हिस्ट्री एक स्थानीय लीक है, जिसका असर लंबा रहता है

हेडलेस एजेंट के लिए ब्राउज़र हिस्ट्री मुख्य रास्ता नहीं है, लेकिन यह मानवीय वर्कफ्लो की गलती दिखाती है। इंजीनियर एरर पेज देखने, कॉलबैक दोहराने या API रूट चलने का प्रमाण लेने के लिए फेल होता URL ब्राउज़र में पेस्ट करते हैं। ब्राउज़र पूरा पता सहेजता है, बाद में सुझाता है और स्थानीय सेटिंग्स के अनुसार हिस्ट्री सिंक भी कर सकता है। स्क्रीन रिकॉर्डिंग, साझा सेशन या मशीन उधार लेने वाला सहकर्मी इसे फिर सामने ला सकता है।

Referer हेडर एक और रास्ता जोड़ता है। जब ब्राउज़र किसी ऐसे पेज को लोड करता है जिसके पते में क्वेरी सीक्रेट है, और वह पेज रिसोर्स मांगता है या लिंक फॉलो करता है, तो ब्राउज़र नीति के अधीन डाउनस्ट्रीम सर्वर को रेफरर मान मिल सकता है। आधुनिक रेफरर पॉलिसी कुछ मामले घटाती हैं, पर सीक्रेट URL को सही डिजाइन नहीं बनातीं। सुरक्षा के लिए पॉलिसी पर निर्भर रहने की जगह क्रेडेंशियल वहां होना ही नहीं चाहिए।

इसीलिए "एजेंट ने इसे कभी नहीं देखा" पर्याप्त नहीं है। डेवलपर एजेंट के नतीजे में URL देख सकता है, उसे टिकट में पेस्ट कर सकता है या मैन्युअल जांच में इस्तेमाल कर सकता है। URL दिखाने वाला हर सिस्टम उसे कॉपी करने को बढ़ावा देता है। इंसान को दिखने वाली कार्रवाई में सीक्रेट मान नहीं, एक अस्पष्ट सीक्रेट नाम रखें।

एक अपवाद का नाम लेना जरूरी है: साइन किया हुआ URL, जो जानबूझकर URL के जरिए ही एक्सेस देता है। किसी स्टोरेज सेवा में अस्थायी डाउनलोड के लिए यही प्रोटोकॉल हो सकता है। इसे सामान्य API क्रेडेंशियल नहीं, सीमित क्षमता की तरह संभालें। इसकी एक्सपायरी छोटी रखें, प्रदाता अनुमति दे तो इसे एक ऑब्जेक्ट और मेथड तक सीमित रखें, इसे प्रिंट करने से बचें और एजेंट को मनमाने क्वेरी पैरामीटर चुनने न दें। साइन किया हुआ URL हिस्ट्री और लॉग में फिर भी संवेदनशील है। उसका अस्थायी होना नुकसान सीमित करता है, लीक का रास्ता नहीं हटाता।

## ऑडिट एक्सपोर्ट घटना को वितरण घटना बना देते हैं

ऑडिट ट्रेल से पता चलना चाहिए कि किसने कार्रवाई मांगी, किस क्रेडेंशियल पहचान ने उसे अधिकृत किया, किस डेस्टिनेशन ने उसे पाया और क्या हुआ। वह दूसरा क्रेडेंशियल स्टोर नहीं बनना चाहिए। खतरनाक ऑडिट स्कीमा पूरा URL रिकॉर्ड करता है, क्योंकि यह सटीक लगता है। किस बात के प्रति सटीक? यह उस मान को सहेजता है जिसकी जांचकर्ता को जरूरत ही नहीं होनी चाहिए।

ऐसा ऑडिट रिकॉर्ड इस्तेमाल करें जो स्थिर पहचानकर्ताओं को सीक्रेट सामग्री से अलग रखे। उपयोगी HTTP एक्शन रिकॉर्ड में मेथड, स्कीम, होस्ट, पाथ, गैर-संवेदनशील क्वेरी नाम और मान, क्रेडेंशियल उपनाम, सेशन पहचान, निर्णय, स्टेटस, रिस्पॉन्स वर्गीकरण और टाइमस्टैम्प हो सकते हैं। छेड़छाड़ के प्रमाण के लिए जरूरत हो तो चुने हुए रिक्वेस्ट घटकों का डाइजेस्ट रखा जा सकता है। इसमें ऑथराइजेशन मान, कुकी सामग्री और गुप्त क्वेरी मान नहीं होने चाहिए।

यह ढांचा एक्सपोर्ट को भी सुरक्षित बनाता है। JSON, CSV और सपोर्ट आर्काइव अपनी मूल एक्सेस बाउंड्री से बाहर जाते हैं। कोई उन्हें वेंडर को भेजता है, बग के साथ लगाता है, शेयर्ड ड्राइव में सहेजता है या स्प्रेडशीट में लोड करता है। एक्सपोर्ट का सामान्य जीवन ऐसा ही है। इसे इस तरह डिजाइन करें कि उससे जांच का उत्तर मिल जाए, मगर वह रोटेशन की सूची न बन जाए।

Sallyport एक ही एन्क्रिप्टेड, हैश-चेन वाले ऑडिट लॉग से एजेंट सेशन और अलग-अलग कॉल प्रोजेक्ट करता है। उसका `sp audit verify` कमांड कुंजी के बिना सिफरटेक्स्ट पर उस चेन को ऑफलाइन सत्यापित करता है। इससे साबित होता है कि लॉग बदला नहीं गया। इससे सीक्रेट URL रिकॉर्ड करना उचित नहीं हो जाता। इंटीग्रिटी और कॉन्फिडेंशियलिटी अलग समस्याएं हैं, और टीमें अक्सर उन्हें मिला देती हैं क्योंकि दोनों को "ऑडिट सिक्योरिटी" कहा जाता है।

लाइव क्रेडेंशियल रखने वाला छेड़छाड़-रोधी लॉग ठीक-ठीक बता सकता है कि क्रेडेंशियल कब लीक हुआ। इंटीग्रिटी की कहानी के बिना रिडैक्ट किया लॉग साझा करने में सुरक्षित हो सकता है, पर उस पर भरोसा करना मुश्किल होता है। दोनों गुण चाहिए, अलग-अलग फील्ड पर लागू किए हुए।

## हेडर इंजेक्शन सीक्रेट को एक्शन विवरण से बाहर रखता है

बेयरर और कस्टम-हेडर इंजेक्शन इसलिए काम करते हैं क्योंकि कॉलर क्रेडेंशियल रखे बिना डेस्टिनेशन का विवरण दे सकता है। गेटवे क्रेडेंशियल लेबल और उसकी एन्क्रिप्टेड वॉल्ट एंट्री के बीच की मैपिंग रखता है। वह अनुरोध बनाता है, हेडर जोड़ता है, भेजता है और परिणाम लौटाता है। एजेंट को न हेडर मान मिलता है, न ऐसा प्लेसहोल्डर जिसे वह बढ़ा सके।

बेयरर API के लिए ढांचा समझने में सरल है:

```
agent request
  method: GET
  url: https://metrics.example.test/v1/usage?team=infra
  credential: metrics-production

gateway outbound request
  GET /v1/usage?team=infra HTTP/1.1
  Host: metrics.example.test
  Authorization: Bearer [vault value]
```

कोष्ठक में दिया टेक्स्ट समझाने के लिए है, कोई ऐसा मान नहीं जो असली ट्रांसक्रिप्ट में दिखना चाहिए। अच्छे बाउंड्री डिजाइन में एजेंट इसे दिखाने, फाइल में सहेजने या क्वेरी स्ट्रिंग में डालने को नहीं कह सकता। गेटवे क्रेडेंशियल को इस्तेमाल करने योग्य डेटा मानता है, लौटाने योग्य डेटा नहीं।

कस्टम हेडर के साथ भी यही तरीका होना चाहिए। कुछ सेवाएं `Authorization` की जगह `X-API-Key`, `Api-Key` या वेंडर-विशिष्ट हेडर इस्तेमाल करती हैं। सटीक नाम बदलता है, नियम नहीं: क्लाइंट को दिखने वाले अनुरोध विवरण में क्रेडेंशियल पहचान होनी चाहिए और गेटवे को कार्रवाई के समय मान जोड़ना चाहिए। बेसिक ऑथेंटिकेशन भी हेडर में होना चाहिए, हालांकि प्रदाता के उपलब्ध अधिक मजबूत तरीके को प्राथमिकता दें।

Sallyport HTTP कॉल के लिए बेयरर, बेसिक और कस्टम-हेडर क्रेडेंशियल इंजेक्शन सपोर्ट करता है। यह यहां उपयोगी है क्योंकि इससे MCP-सक्षम एजेंट अपने कॉन्टेक्स्ट में API कुंजी रखे बिना HTTP कार्रवाई मांग सकता है। यही बाउंड्री कोई जादुई सैनिटाइज़र नहीं है: यदि आप अनुमति दें, तो एजेंट द्वारा दिए URL और फील्ड में फिर भी सीक्रेट हो सकते हैं। रिक्वेस्ट का ढांचा वैलिडेट करें और उन जगहों पर सीक्रेट जैसे मान अस्वीकार करें, जिन्हें सार्वजनिक रहना चाहिए।

## POST URL में मौजूद क्रेडेंशियल को ठीक नहीं करता

`GET` को `POST` में बदलने पर, जबकि URL में `?api_key=...` बना रहे, इस लीक में लगभग कुछ नहीं बदलता। प्रॉक्सी को फिर भी रिक्वेस्ट टारगेट मिलता है। एक्सेस लॉग उसे अक्सर रिकॉर्ड करते हैं। ब्राउज़र और टूल उसे दिखा सकते हैं। CWE-598 साफ बताता है कि क्वेरी स्ट्रिंग GET के अलावा दूसरे मेथड के साथ भी आ सकती है।

क्रेडेंशियल को रिक्वेस्ट बॉडी में ले जाने से कुछ स्टैक में अनजाने लॉगिंग का जोखिम घट सकता है, क्योंकि एक्सेस लॉग डिफॉल्ट रूप से बॉडी नहीं रखते। यह हेडर इंजेक्शन जैसा नहीं है। डिबगिंग मिडलवेयर, API क्लाइंट, एरर रिपोर्टर और रिक्वेस्ट रिकॉर्डिंग टूल अक्सर बॉडी कैप्चर करते हैं। इससे क्रेडेंशियल एक्शन पेलोड का हिस्सा भी बनता है, जिसे एजेंट बनाने या दोहराने के लिए प्रेरित हो सकता है।

API का मांगा हुआ मेथड और बॉडी इस्तेमाल करें। सीक्रेट को बॉडी में सिर्फ तब रखें जब प्रोटोकॉल साफ तौर पर मांगे, जैसे फॉर्म पैरामीटर बताने वाला टोकन एक्सचेंज। तब बॉडी लॉगिंग सीमित करें, एंडपॉइंट को व्यापक रिक्वेस्ट कैप्चर से बाहर रखें और एक्सचेंज को क्रेडेंशियल वाले कंपोनेंट के भीतर रखें। अंधविश्वास में हर रीड रिक्वेस्ट को POST न बनाएं। HTTP सेमांटिक्स बनाए रखें और URI से सीक्रेट हटाएं।

इससे जुड़ी एक और खराब सलाह है: "इसे URL-एन्कोड कर दें, लॉग हानिरहित हो जाएंगे"। प्रतिशत एन्कोडिंग सिर्फ प्रस्तुति बदलती है। URL वाला कोई भी व्यक्ति इसे डिकोड कर सकता है और कई लॉग व्यूअर ऐसा पहले से करते हैं। Base64 की भी यही समस्या है। एन्कोडिंग क्वेरी को आंख से स्कैन करना कठिन बना सकती है और रिडैक्शन नियमों की नजर से चूकना आसान।

## सुरक्षित माइग्रेशन सामूहिक बदलाव से नहीं, सबूत से शुरू होता है

हर क्वेरी पैरामीटर न बदलें। `page`, `sort`, `project` और `fields` जैसे क्वेरी पैरामीटर अक्सर वैध, उपयोगी और गैर-गुप्त होते हैं। पहले पता करें कि क्रेडेंशियल वास्तव में URL में कहां आते हैं, फिर आउटबाउंड रिक्वेस्ट देखने वाले टेस्ट के साथ उन कॉल साइट को बदलें।

यह क्रम अपनाएं:

1. सोर्स कोड, एजेंट प्रॉम्प्ट, सहेजे हुए curl कमांड, टेस्ट फिक्स्चर, डैशबोर्ड और रनबुक में `token`, `key`, `secret`, `signature` और `credential` जैसे नाम खोजें। `?` वाले पूरे URL भी खोजें। नाम अलग-अलग होते हैं।
2. हर इनग्रेस लेयर से प्रतिनिधि एक्सेस लॉग और ट्रेस डेटा इकट्ठा करें। पुष्टि करें कि हर रिक्वेस्ट टारगेट सिर्फ पैरामीटर नाम नहीं, क्वेरी मान भी रिकॉर्ड करता है या नहीं। रिटेंशन में मौजूद एक्सपोर्ट और सपोर्ट बंडल को भी एक लेयर मानें।
3. API मालिक से पूछें कि वह किस हेडर या बॉडी तंत्र को सपोर्ट करता है। यदि वह सिर्फ क्वेरी क्रेडेंशियल स्वीकार करता है, तो अपवाद दर्ज करें, क्रेडेंशियल का दायरा सख्त रखें और उस कॉल को सामान्य उद्देश्य वाले एजेंटों से अलग रखें।
4. एक्शन इंटरफेस को `url with secret` से `url plus credential alias` में बदलें। ऐसा टेस्ट जोड़ें जो ज्ञात टेस्ट टोकन वाले URL को अस्वीकार करे और जांचे कि आउटबाउंड हेडर में वह टोकन है।
5. URL में दिखे हर क्रेडेंशियल को रोटेट करें, फिर रिटेंशन प्रक्रिया के तहत पुराने लॉग और एक्सपोर्ट हटाएं। सफाई के बिना रोटेशन से पुराना एक्सपोज़र बचता है, रोटेशन के बिना सफाई से सक्रिय कुंजी घूमती रहती है।

टेस्ट वह जगह है जहां कई माइग्रेशन फेल होते हैं। सिर्फ अंतिम HTTP रिस्पॉन्स जांचने वाला यूनिट टेस्ट यह नहीं बता सकता कि कुंजी हेडर में गई या क्वेरी स्ट्रिंग में। क्लाइंट के पीछे लोकल टेस्ट सर्वर लगाएं और मेथड, पाथ, क्वेरी व हेडर अलग-अलग कैप्चर करें। जांचें कि क्वेरी में टेस्ट मान नहीं है और वह सिर्फ इच्छित हेडर में है।

गेटवे के लिए अस्वीकृति का एक केस जोड़ें। किसी भी क्रेडेंशियल उपनाम के साथ उसे `https://api.example.test/v1/jobs?access_token=test-canary` दें और नेटवर्क कॉल से पहले फेल कराएं। इससे भविष्य में ऐसा प्रॉम्प्ट टेम्पलेट या सुविधाजनक रैपर पकड़ा जाएगा जो सीक्रेट वापस URL में डालने की कोशिश करे। कैनरी टोकन अद्वितीय हो और टेस्ट के बाहर उपयोग न हो सके।

## डिजाइन ठीक होने के बाद भी रिडैक्शन जरूरी है

हेडर इंजेक्शन संभावित लीक की संख्या घटाता है। इससे नियम के बल पर लॉग सुरक्षित नहीं हो जाते। कोई एप्लिकेशन अपवाद में ऑथराइजेशन हेडर दोहरा सकता है, डिबग घटना के दौरान प्रॉक्सी सभी हेडर लॉग कर सकता है, या एजेंट ऐसा रिस्पॉन्स डेटा टिकट में पेस्ट कर सकता है जिसमें सीक्रेट हो। रिडैक्शन, एक्सेस कंट्रोल, रिटेंशन लिमिट और इंसिडेंट रिस्पॉन्स बनाए रखें।

मगर इन कंट्रोल को सही क्रम में रखें। पहले क्रेडेंशियल को URL और एजेंट को दिखने वाले रिक्वेस्ट विवरण से बाहर रखें। फिर हर ऐसे लॉगर में ज्ञात संवेदनशील हेडर और बॉडी रिडैक्ट करें जो उन्हें कैप्चर कर सकता है। उसके बाद तय करें कि रॉ रिकॉर्ड कौन पा सकता है और वे कितने समय तक रहेंगे। आखिर में रोटेशन और एक्सपोर्ट सफाई का अभ्यास करें, ताकि कंट्रोल फेल हो तो टीम कार्रवाई कर सके।

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

## एजेंट ऑथराइजेशन में आउटबाउंड डेस्टिनेशन भी शामिल होना चाहिए

टोकन न पढ़ सकने वाला एजेंट भी उसकी अथॉरिटी खर्च कर सकता है। अगर वह कोई भी URL चुन सकता है, तो उलझे कॉन्फिगरेशन, टाइपो, SSRF पाथ या उदार एक्शन इंटरफेस का फायदा उठाने वाले प्रॉम्प्ट के जरिये वैध क्रेडेंशियल को अनचाहे होस्ट पर भेज सकता है। सीक्रेट न बताना और डेस्टिनेशन कंट्रोल अलग जरूरतें हैं।

क्रेडेंशियल उपनाम को इच्छित सेवा से बांधें और होस्ट, स्कीम व अनुमत पाथ का ढांचा साफ रखें। जब कार्रवाई में `metrics.example.test.evil.invalid` लिखा हो, तो गेटवे को `metrics.example.test` के लिए चुना क्रेडेंशियल अस्वीकार कर देना चाहिए। उसे यूज़र-इन्फो ट्रिक, क्रेडेंशियल फॉरवर्ड करने वाले अनपेक्षित रीडायरेक्ट और एन्कोडिंग के पीछे छिपे होस्ट बदलाव भी अस्वीकार करने चाहिए। ये जांच वहीं होनी चाहिए जहां हेडर जुड़ता है, क्योंकि वही आखिरी जगह है जहां क्रेडेंशियल पहचान और पार्स किया डेस्टिनेशन दोनों होते हैं।

Sallyport का प्रति-सेशन ऑथराइजेशन कार्ड नए एजेंट प्रोसेस को उसकी कोड-साइनिंग अथॉरिटी से पहचानता है और प्रति-कॉल कुंजियों में हर इस्तेमाल पर क्लिक या Touch ID की जरूरत रखी जा सकती है। ये कंट्रोल बताते हैं कि यह प्रोसेस कोई कार्रवाई चला सकता है या नहीं। ये किसी मनमाने डेस्टिनेशन को सुरक्षित नहीं बनाते, इसलिए एक्शन कॉन्फिगरेशन इतना सीमित रखें कि मंजूरी का ठोस अर्थ हो।

## उपयोगी चीज वह रिक्वेस्ट रिकॉर्ड है जिसे आप साझा कर सकें

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

ऐसे रिकॉर्ड का लक्ष्य रखें:

```
request_id: 01J...
agent_session: signed-process-42
method: GET
destination: https://metrics.example.test/v1/usage
query: team=infra
credential_alias: metrics-production
authorization: injected, value omitted
result: 200, 481 bytes
```

यह रिकॉर्ड जांचकर्ता को कॉल का संबंध जोड़ने, सुरक्षित टेस्ट क्रेडेंशियल से रूट दोहराने और यह पूछने के लिए पर्याप्त जानकारी देता है कि एजेंट ने `metrics-production` क्यों चुना। यह जानबूझकर किसी को ऑथेंटिकेट नहीं कर सकता। यदि जांचकर्ता को स्वयं सीक्रेट चाहिए, तो वह अलग विशेषाधिकार वाली रिकवरी प्रक्रिया है, सामान्य टेलीमेट्री का फील्ड नहीं।

पहली कार्रवाई आम तौर पर सोर्स, प्रॉम्प्ट और एक्सपोर्ट किए लॉग में URL खोजने का साधारण काम होती है। फिर भी इसे करें। वहां मिला क्रेडेंशियल उन सिस्टमों से कॉपी हो चुका हो सकता है जिनके बारे में आप भूल गए थे, और साफ समाधान यही है कि इस तरह के URL बनाना बंद कर दें।