API प्राधिकरण चुपचाप विफल होता है: हर ऑब्जेक्ट, रोल और एक्शन को टेस्ट करें

संक्षेप में: ऑथेंटिकेशन साबित करता है कि रिक्वेस्ट किसने की; ऑथराइज़ेशन तय करता है कि वह पहचान क्या कर सकती है। API सुरक्षा तब टूटती है जब टीमें पहला सवाल टेस्ट करती हैं और मान लेती हैं कि दूसरा सवाल हर जगह काम करता है।

एक वैध टोकन कोई अनुमति-पर्ची नहीं है

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

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

एक पूर्ण ऑथराइज़ेशन-मैट्रिक्स बनाएँ

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

डेटा-सीमा पर डिफ़ॉल्ट रूप से अस्वीकार करें

सबसे भरोसेमंद डिज़ाइन हर क्वेरी को अनुरोधित ऑब्जेक्ट और कॉलर के प्राधिकृत दायरे — दोनों से बाँधता है। पहचानकर्ता से रिकॉर्ड फ़ेच करना और स्वामित्व बाद में जाँचना भुला दी गई जाँचों, साइड-चैनलों और असंगत एरर-हैंडलिंग के लिए जगह बनाता है। टेनेंट या स्वामित्व-सीमा के भीतर क्वेरी करना सुरक्षित शर्त को रिट्रीवल का ही हिस्सा बना देता है।

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

प्रमाण को यह साबित करना चाहिए कि निषिद्ध रास्ता बंद रहा

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

KENSAI एक्सेस-कंट्रोल सत्यापन को एक ही 'हैप्पी-पाथ' स्कैन के बजाय एक मैट्रिक्स की तरह देखता है। लक्ष्य पहचानों और एक्शन के आर-पार आइसोलेशन साबित करना है, फिर किसी भी सीमा-विफलता को दोहराने और उसके सुधार को सत्यापित करने लायक़ पर्याप्त प्रमाण सुरक्षित रखना है।

निष्कर्ष

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