HTTP विधि ओवरराइड केवल विधि वाली समीक्षा तोड़ता है

अगर समीक्षक सिर्फ अनुरोध पंक्ति देखता है, तो HTTP विधि पर आधारित समीक्षा सुरक्षित नहीं है। कोई अनुरोध POST के रूप में आ सकता है, उसमें X-HTTP-Method-Override: DELETE हो सकता है, और एप्लिकेशन मिडलवेयर विधि बदलने के बाद वह डिलीट हैंडलर तक पहुंच सकता है। अगर मंजूरी स्क्रीन, गेटवे नियम, प्राधिकरण जांच या ऑडिट रिकॉर्ड उसे सामान्य POST मानता है, तो उसने लिफाफा देखा, कार्रवाई नहीं।

यह कोई ऐसा HTTP प्रोटोकॉल नियम नहीं है जिसे हर सर्वर समझता हो। यह एप्लिकेशन स्तर की परंपरा है, इसलिए अक्सर नजर से छूट जाती है। इसका समर्थन फ्रेमवर्क, मिडलवेयर क्रम, रूट और तैनाती के हिसाब से बदलता है। हर POST को छिपा हुआ विनाशकारी अनुरोध मानना सही हल नहीं है। पता लगाइए कि ओवरराइड कहां स्वीकार होते हैं, हर सुरक्षा निर्णय से पहले उन्हें हल कीजिए और अस्पष्टता को अस्वीकार कीजिए।

वायर विधि और प्रभावी विधि अलग तथ्य हैं

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

RFC 9110 के अनुसार विधि टोकन अनुरोध के अर्थ का मुख्य स्रोत है। वह POST को संसाधन के मुताबिक प्रसंस्करण और DELETE को मूल सर्वर से लक्ष्य संसाधन तथा उसकी मौजूदा कार्यक्षमता का संबंध हटाने का अनुरोध बताता है। RFC X-HTTP-Method-Override को मानकीकृत नहीं करता। यह हेडर उन संगतता परंपराओं में से है जिन्हें ऐसे क्लाइंट या मध्यस्थों के लिए बनाया गया था जो केवल GET और POST संभाल पाते थे।

सामान्य सॉफ्टवेयर आज भी यह सुविधा देते हैं। Express का method-override मिडलवेयर डिफॉल्ट रूप से POST पर X-HTTP-Method-Override पढ़ता है। मान स्वीकार करने पर वह req.method बदलता है और पुराना मान req.originalMethod में रखता है। ASP.NET Core में भी HTTP विधि ओवरराइड मिडलवेयर है, जिसका डिफॉल्ट हेडर यही है। Spring का HiddenHttpMethodFilter अलग तरीका अपनाता है: वह POST फॉर्म का _method पैरामीटर पढ़ता है और PUT, DELETE तथा PATCH स्वीकार करता है।

इन ब्योरों से वह फर्क साफ होता है जिसे टीमें अक्सर मिला देती हैं। “गेटवे ने POST स्वीकार किया” परिवहन को बताता है। “एप्लिकेशन ने DELETE किया” व्यवहार को बताता है। मंजूरी या पहुंच निर्णय को दूसरा तथ्य चाहिए। अगर निर्णय लेने वाला घटक प्रभावी विधि नहीं निकाल सकता, तो उसे ओवरराइड संकेत अस्वीकार करने चाहिए, बाहरी क्रिया के आधार पर चुपचाप वर्गीकरण नहीं करना चाहिए।

फ्रेमवर्क में समर्थन होना अपने आप जोखिम साबित नहीं करता। Express एप्लिकेशन को मिडलवेयर लगाना और सही क्रम देना पड़ता है। ASP.NET Core में मिडलवेयर जोड़ना पड़ता है। Spring में फिल्टर चालू करके सही जगह रखना पड़ता है। रिवर्स प्रॉक्सी और रूट आधारित मिडलवेयर समेत आपकी तैनात कॉन्फिगरेशन नतीजा तय करती है। स्रोत कोड संभावित जगहें बताता है, अवस्था जांचने वाला परीक्षण प्रमाण देता है।

मंजूर POST डिलीट हैंडलर तक पहुंच सकता है

टनल किया गया लेखन तब निकल जाता है जब घटक यह तय करने में असहमत हों कि कार्रवाई का आधिकारिक रूप कौन सा है। मान लीजिए कोई एजेंट प्रोजेक्ट API को यह अनुरोध देता है:

POST /v1/projects/42 HTTP/1.1
Host: api.example.test
Authorization: Bearer [injected outside the agent]
X-HTTP-Method-Override: DELETE
Content-Length: 0

मंजूरी परत इसे “POST /v1/projects/42” कहती है और ऐसा नियम लगाती है जो इस सत्र के लिए POST स्वीकार करता है। रिवर्स प्रॉक्सी अनजाना हेडर आगे भेज देता है। RFC 9110 आम तौर पर प्रॉक्सी से अनजाने फील्ड आगे भेजने को कहता है, जब तक कॉन्फिगरेशन उन्हें रोके या बदले नहीं। एप्लिकेशन के भीतर ओवरराइड मिडलवेयर रूटिंग से पहले विधि बदल देता है। राउटर DELETE हैंडलर चुनता है और प्रोजेक्ट गायब हो जाता है।

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

मिडलवेयर क्रम तय करता है कि कौन सा नियंत्रण कौन सा तथ्य देखेगा। Express दस्तावेज साफ कहते हैं कि विधि ओवरराइड को उस हर मिडलवेयर से पहले चलना चाहिए जिसे अनुरोध विधि जाननी है। एक प्रक्रिया के भीतर रूटिंग और CSRF तर्क के लिए यह सही है। इससे प्रक्रिया के बाहर वह गेटवे ठीक नहीं होता जो अनुरोध पंक्ति देखकर पहले ही निर्णय ले चुका है।

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

सिर्फ DELETE शब्द देखकर असर न मानें। RFC 9110 कहता है कि DELETE संसाधन और उसकी मौजूदा कार्यक्षमता का संबंध हटाता है; संग्रह सच में मिटेगा या जगह खाली होगी, यह एप्लिकेशन पर निर्भर है। DELETE एंडपॉइंट संग्रहित, निष्क्रिय, कतारबद्ध या मिटा सकता है। सामान्य क्रिया नहीं, रूट का असली नतीजा जांचें।

नियंत्रित विधि मैट्रिक्स से एंडपॉइंट जांचें

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

पहले बिना ओवरराइड वाला आधार POST भेजें। उसकी स्थिति, प्रतिक्रिया बॉडी और फिक्स्चर अवस्था दर्ज करें। फिर मूल DELETE भेजें। इससे पता चलता है कि रूट मौजूद है और परीक्षण पहचान उसे चला सकती है। अंत में हर परंपरा के साथ POST दोहराएं। हेडर का छोटा परीक्षण ऐसा है:

BASE='https://staging.example.test'
ID='override-probe-17'

curl -sS \n  -D response.headers \n  -o response.body \n  -w 'case=x-http-method-override outer=POST status=%{http_code} bytes=%{size_download}
' \n  -X POST "$BASE/v1/projects/$ID" \n  -H 'Authorization: Bearer test-token' \n  -H 'X-HTTP-Method-Override: DELETE'

curl -sS \n  -o state.body \n  -w 'verify=read-after-request status=%{http_code} bytes=%{size_download}
' \n  -H 'Authorization: Bearer test-token' \n  "$BASE/v1/projects/$ID"

आउटपुट जानबूझकर स्थिर है ताकि CI उसे पढ़ सके:

case=x-http-method-override outer=POST status=204 bytes=0
verify=read-after-request status=404 bytes=71

यह नमूना ऐसा ओवरराइड दिखाता है जिसने फिक्स्चर मिटाया; यह हर API का अपेक्षित दर्जा नहीं है। कुछ API नतीजे के साथ 200, कतारबद्ध डिलीट के लिए 202 या पढ़े जा सकने वाले नरम डिलीट का रूप लौटाते हैं। सफलता को अपने एप्लिकेशन अनुबंध से परिभाषित करें।

तात्कालिक क्रम के बजाय मैट्रिक्स चलाएं। नियंत्रण मामला बिना ओवरराइड वाला POST है और उसे सामान्य POST जैसा व्यवहार करना चाहिए। मूल मामला बिना ओवरराइड वाला DELETE है और वह दस्तावेज वाला डिलीट व्यवहार तय करता है। फिर X-HTTP-Method-Override: DELETE, X-HTTP-Method: DELETE और X-Method-Override: DELETE के साथ अलग POST भेजें। अंत में क्वेरी में ?_method=DELETE और फॉर्म बॉडी में _method=DELETE जांचें। हर ओवरराइड या तो आपकी स्पष्ट टनल डिजाइन से मेल खाए या बिना अवस्था बदले विफल हो।

OWASP Web Security Testing Guide यही तीन हेडर बताता है और प्रतिबंधित विधि अस्वीकार होने पर ओवरराइड के साथ अनुरोध दोहराने की सलाह देता है। मैं केवल दर्जे की तुलना से आगे जाऊंगा, क्योंकि अंतर सत्यापन, रूटिंग या मध्यस्थ से आ सकता है। हर परीक्षण के बाद संसाधन, उसका संस्करण और कतार का काम जांचें।

अगर पूरा स्टैक आपका है, तो हर पड़ाव पर अवलोकन रखें: किनारे का अनुरोध लॉग, मंजूरी घटना, एप्लिकेशन अनुरोध लॉग, चुना रूट और डेटा नतीजा। आप असहमति खोज रहे हैं। सुरक्षित नतीजा लगातार अस्वीकृति भी हो सकता है, या जानबूझकर सामान्यीकरण के बाद मूल DELETE जैसी ही मंजूरी और प्राधिकरण।

दर्जा संकेत है, अवस्था बदलना प्रमाण

सिर्फ HTTP दर्जे से नहीं पता चलता कि ओवरराइड चला। 204 के बाद फिक्स्चर का गायब होना मजबूत प्रमाण है। 200 सामान्य POST प्रतिक्रिया, डिलीट रसीद या गलत ढंग से लिखी कस्टम त्रुटि हो सकता है। 405 किनारे से ओवरराइड मिडलवेयर के पहले आ सकता है, जबकि दूसरा पथ या सामग्री प्रकार अभी भी उसे पहुंचता हो।

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

प्रतिक्रिया तुलना फिर भी उपयोगी है। दर्जा, चुने प्रतिक्रिया हेडर, बॉडी आकार और बॉडी सार बचाएं। ओवरराइड को साधारण POST और मूल DELETE दोनों से तुलना करें। अगर प्रतिक्रिया और अवस्था DELETE जैसी हैं, निष्कर्ष मजबूत है। अगर प्रतिक्रिया POST जैसी और अवस्था DELETE जैसी है, तो लॉग या प्रतिक्रिया परत बाहरी विधि इस्तेमाल कर सकती है।

रीडायरेक्ट अलग जांचें। 301, 302, 303, 307 या 308 का अनुसरण करते समय क्लाइंट व्यवहार बदल सकता है और टूल विधि तथा बॉडी अलग ढंग से रखते हैं। पहले रीडायरेक्ट बंद करके Location दर्ज करें, फिर जानबूझकर अनुसरण करके हर पड़ाव पकड़ें। रीडायरेक्ट और ओवरराइड को एक अस्पष्ट नतीजे में न मिलाएं।

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

नकारात्मक अवस्था भी जांचें। अस्वीकृत ओवरराइड को बनाना, अपडेट, संग्रह, कतार, ईमेल या विशेषाधिकार वाला वेबहुक नहीं करना चाहिए। साफ 4xx भटका सकता है: बाद का घटक असर कर चुका हो और फिर पहले का घटक प्रतिक्रिया पथ रोक दे। फिक्स्चर पर इतनी निगरानी रखें कि यह क्रम पकड़ में आए।

हेडर रूप और अस्पष्टता साथ जांचें

केवल प्रचलित नाम जांचने से संगतता कोड और पार्सर असहमति छूटती है। आम नाम X-HTTP-Method-Override, X-HTTP-Method और X-Method-Override हैं, पर एप्लिकेशन अपना गेटर बना सकते हैं। क्वेरी और फॉर्म में _method हो सकता है और पुराने एकीकरण विक्रेता या फ्रेमवर्क से जुड़े नाम रखते हैं।

हेडर नाम का केस अलग परंपरा नहीं है। RFC 9110 में फील्ड नाम केस से स्वतंत्र हैं, इसलिए x-http-method-override और X-HTTP-Method-Override एक ही फील्ड हैं। केवल बड़े अक्षर वाले रूप को मिलाने वाला फिल्टर दोषपूर्ण है, खासकर जब एप्लिकेशन लाइब्रेरी नाम सामान्य करती हो।

दोहराए और टकराते मान कठिन समस्या दिखाते हैं। फील्ड परिभाषा अनुमति दे तो RFC 9110 प्राप्तकर्ता को दोहराई पंक्तियां अल्पविराम वाली सूची में जोड़ने देता है, और एकल मान की उम्मीद में भी दोहराव पर विचार करने को कहता है। ओवरराइड हेडर साझा पार्सिंग नियम वाले मानकीकृत एकल फील्ड नहीं हैं। Express दस्तावेज कहते हैं कि वह दोहराए हेडर की पहली घटना लेता है, जबकि कई ओवरराइड हैंडलर अलग नामों में प्राथमिकता बना सकते हैं।

बुनियादी मैट्रिक्स के बाद x-http-method-override: DELETE भेजें और प्रचलित केस जैसा नतीजा मांगें। दो समान DELETE मान भेजकर दस्तावेज वाला एक नतीजा या अस्वीकृति मांगें। PUT के बाद DELETE और दो नामों में अलग मान भेजें; दोनों संघर्ष अस्पष्ट मानकर रोकें। PUT, DELETE, मूल PATCH के साथ DELETE ओवरराइड और DELETE हेडर के साथ _method=PATCH भी रोकें, जब तक अनुबंध साफ रूप से कुछ और न कहे।

DELETE पर न रुकें। PUT और PATCH भी जांचें, क्योंकि समीक्षा प्रणाली निर्माण, प्रतिस्थापन, आंशिक अपडेट और डिलीट अलग मान सकती है। असमर्थित टोकन नकारात्मक नियंत्रण बने। TRACE और CONNECT तभी जांचें जब वातावरण और दायरा अनुमति दें; वे अलग ढांचागत व्यवहार चलाते हैं और इस निष्कर्ष को बेहतर नहीं करते।

खाली जगह और मान का केस असंगत सामान्यीकरण खोल सकता है। क्लाइंट अनुमति दे तो delete, DELETE और खाली मान भेजें। सुरक्षित नियम है कि सिर्फ दस्तावेज वाली चीज सामान्य करें, स्पष्ट विधि समूह से जांचें और बाकी रोकें। पहला पढ़ने योग्य मान चुनना वह बाइपास है जो प्रॉक्सी या लाइब्रेरी बदलने पर लौटेगा।

एजेंट अनुरोध इस चूक को आसान बनाते हैं

AI एजेंट यह कमजोरी पैदा नहीं करते, लेकिन अधूरी समीक्षा को अधिक खतरनाक बनाते हैं। एजेंट मनचाहे हेडर जोड़ सकता है, दस्तावेज उदाहरण दोहरा सकता है और असफल मूल DELETE को POST टनल के रूप में फिर चला सकता है, बिना समझे कि दूसरी शक्ल मंजूरी सीमा पार करती है। छोटी मंजूरी कार्ड देखने वाला व्यक्ति साफ दिख रही विधि और पथ पर ध्यान देगा।

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

टूल स्कीमा अनुरोध बनने से पहले अस्पष्टता घटा सकता है। मुक्त हेडर वाला सामान्य HTTP टूल कॉलर को ओवरराइड मांगने की पूरी भाषा देता है। रूट विशेष डिलीट टूल कार्रवाई सीधे बता सकता है और ओवरराइड फील्ड हटा सकता है। दूसरा रूप समीक्षा में आसान है, अगर उसके भीतर छिपे रास्ते से अतिरिक्त हेडर न जा सकें।

सामान्य HTTP टूल जरूरी हो तो इंसान को दिखाने से पहले अनुरोध पार्स करें। पार्सर और निष्पादक की सूची और प्राथमिकता एक हो। मंजूरी के बाद सामान्य कार्रवाई स्थिर करें ताकि बाद में अलग मान न निकले। मंजूरी के बाद कोई मध्यस्थ हेडर बदले तो उस तय बदलाव को समीक्षा में शामिल करें या फिर से हल करके नई मंजूरी मांगें।

दोबारा प्रयास पर भी ध्यान दें। POST अपने आप सुरक्षित या दोहराने योग्य नहीं है। RFC 9110 उसे संसाधन आधारित प्रसंस्करण कहता है और कई POST बिना ओवरराइड के डेटा बदलते हैं। एजेंट टूल केवल बाहरी POST देखकर सुरक्षित पुनः प्रयास नहीं मान सकता, न हर POST को विनाशकारी कह सकता है। उसे रूट अर्थ और प्रभावी विधि चाहिए।

परीक्षण और उत्पादन पहचान अलग रखें। व्यापक उत्पादन क्रेडेंशियल हर जांच सफल करके प्राधिकरण फर्क छिपा सकता है। एजेंट की वास्तविक सीमित भूमिका लें, मूल और टनल रूप पर समान निर्णय जांचें और इंसानी मंजूरी में दिखी चीज दर्ज करें। प्रस्ताव, प्रदर्शन, निष्पादन और नतीजे को एक श्रृंखला में दिखाने पर ही समीक्षा असंगति सिद्ध होती है।

सबसे पहला नियंत्रण प्रभावी कार्रवाई समझे

हर विधि आधारित निर्णय एक सामान्य रिजॉल्वर के बाद चले, नहीं तो सभी ओवरराइड इनपुट रोके। इंसानी मंजूरी, प्राधिकरण, CSRF रक्षा, रूट रोक, दर सीमा और ऑडिट वर्गीकरण सब पर यह लागू है। हर नियंत्रण में अलग पार्सिंग से असहमति तय है।

रिजॉल्यूशन साफ लिखें:

{
  "transport_method": "POST",
  "effective_method": "DELETE",
  "override_source": "header:x-http-method-override",
  "override_value": "DELETE",
  "target": "/v1/projects/42",
  "ambiguous": false
}

रिजॉल्वर हर समर्थित हेडर और पैरामीटर की सूची बनाए, सारे मान ले और एक से अधिक अलग उम्मीदवार पर अनुरोध रोक दे। वह सामान्यतः केवल POST जैसी स्वीकृत बाहरी विधि से ओवरराइड ले। मान को जानबूझकर समर्थित विधियों से जांचे और आगे के नियंत्रणों के लिए अपरिवर्तनीय रिकॉर्ड बनाए।

प्राधिकरण रिजॉल्यूशन के बाद रखें और उसे रूट तथा प्रभावी विधि से बांधें। POST टनल हो तो “क्या यह पहचान इस पथ पर POST कर सकती है” कमजोर सवाल है। पूछें कि वह मौजूदा हालात में इस संसाधन पर DELETE कर सकती है या नहीं। मूल DELETE और समर्थित टनल दोनों पर वही हैंडलर प्राधिकरण लगे।

मंजूरी स्क्रीन नतीजे को पहले दिखाए और फर्क पर दोनों रूप बताए। DELETE /v1/projects/42 via POST override प्रभावी कार्रवाई और परिवहन ब्यौरा दोनों देता है। ओवरराइड हेडर को खुलने वाले कच्चे पैनल में छिपाने से समीक्षक को दबाव में खतरा खोजना पड़ता है।

ऊपरी गेटवे एप्लिकेशन नियम नहीं दोहरा सकता तो उसे अधूरा नियम न सिखाएं। मंजूरी से पहले हर ज्ञात संकेत रोकें या मंजूरी को भरोसेमंद सामान्यीकरण के बाद रखें। एक हेडर समझने वाला गेटवे और तीन समझने वाला एप्लिकेशन झूठा भरोसा देते हैं।

रिजॉल्यूशन को कारोबारी अर्थ से अलग रखें। रिजॉल्वर DELETE निकाल सकता है, रूट तय करता है कि इसका अर्थ संग्रह, निरस्तीकरण, संबंध हटाना या मिटाना है। बड़े असर की मंजूरी को रूट आधारित विवरण चाहिए। विधि सामान्यीकरण जरूरी है, पर अकेली क्रिया सब असर नहीं बताती।

एक हेडर हटाना अधूरा सुधार है

प्रॉक्सी पर X-HTTP-Method-Override हटाना तभी सुरक्षित है जब सेवा किसी ओवरराइड को जानबूझकर न स्वीकारे। यह सरल है और पहला प्रमाण रोक देता है, इसलिए लोकप्रिय है। दूसरा हेडर, _method, सीधा अपस्ट्रीम पथ या बाद का मिडलवेयर बचा हो तो यह विफल है।

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

दो स्वीकार्य डिजाइन हैं। कोई क्लाइंट टनल न चाहता हो तो एप्लिकेशन मिडलवेयर बंद करके किनारे पर सारे संकेत रोकें। जरूरत हो तो एक दस्तावेज वाला इनपुट स्वीकारें, बाकी हटाएं या रोकें, नियंत्रणों से पहले सामान्य करें और मूल तथा टनल को एक कार्रवाई की तरह जांचें।

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

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

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

लॉग में अनुरोध और चुनी कार्रवाई दोनों हों

ऑडिट रिकॉर्ड परिवहन विधि, प्रभावी विधि, स्रोत, सामान्य मान, रूट, पहचान, लक्ष्य, निर्णय, प्रतिक्रिया और नतीजा रखे। दोनों विधि के बिना POST का DELETE तक जाना नहीं समझेगा। नतीजे के बिना केवल इरादा दिखेगा, असर नहीं।

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

पहले भरोसेमंद पड़ाव पर बना अनुरोध पहचान सभी परतों में चलाएं। बाहरी पहचान सीधे न मानें, उसे बदलें या नाम क्षेत्र दें। किनारा, रिजॉल्वर, मंजूरी सेवा, एप्लिकेशन और असिंक्रोनस कर्मी उसी पहचान से कार्रवाई जोड़ें।

फील्ड नाम साफ हों। सामान्य method में हर घटक अलग अर्थ लिख सकता है। अनुरोध पंक्ति के लिए transport_method और रूट कार्रवाई के लिए effective_method लिखें। मिडलवेयर के originalMethod को साफ मैप करें, हर फ्रेमवर्क में समान न मानें।

Sallyport एजेंट को क्रेडेंशियल दिए बिना उसका HTTP कॉल चलाता है और Activity जर्नल में कॉल दर्ज करता है। यह अलगाव ओवरराइड को सुरक्षित नहीं करता; समीक्षा को निष्पादन से पहले प्रभावी विधि पहचाननी होगी।

स्वचालित रन के बाद छेड़छाड़ का प्रमाण जरूरी है। केवल लिखने वाला हैश श्रृंखला रिकॉर्ड चुप बदलाव पकड़ता है, पर गायब अर्थ वापस नहीं ला सकता। निर्णय के समय सामान्य कार्रवाई लॉग करें, बाद की प्रक्रिया से अनुमान न लगाएं।

समीक्षा डैशबोर्ड असमानता सामने रखे। सेवा और स्रोत के आधार पर transport_method != effective_method गिनने से अप्रत्याशित संगतता ट्रैफिक दिखता है। नए स्रोत, अस्पष्ट अनुरोध और ऐसे विनाशकारी प्रभावी तरीके पर चेतावनी दें जिसकी मंजूरी में केवल बाहरी विधि थी।

प्रतिगमन परीक्षण सुरक्षित रूप से असफल हो

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

मैट्रिक्स की हर पंक्ति का अपेक्षित व्यवहार लिखें। टनल बंद हो तो हर संकेत दस्तावेज वाला 4xx दे और फिक्स्चर न बदले। एक परंपरा हो तो उसका DELETE प्राधिकरण, मंजूरी, रूटिंग और ऑडिट में मूल DELETE जैसा हो। संघर्ष और अनजाने टोकन असर से पहले रुकें।

तैनात पथ में ये दावे रखें:

• मंजूरी घटना प्रभावी विधि बताती है;
• मूल और टनल रूप पर समान प्राधिकरण है;
• अस्वीकृत इनपुट कैनरी संस्करण या असर गिनती नहीं बदलता;
• एक भरोसेमंद पहचान में दोनों विधि फील्ड हैं;
• सीधी अपस्ट्रीम पहुंच सामान्यीकरण नहीं छोड़ती।

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

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

साफ प्रणाली में प्रवेश से नतीजे तक एक कार्रवाई विवरण होता है। वायर पर POST और एप्लिकेशन में DELETE हो तो किसी इंसान या घटक की हां से पहले फर्क दिखना चाहिए। उसके बाद केवल घटना पुनर्निर्माण बचता है।