बॉब अपने वैध अकाउंट से लैब API में साइन इन करता है, GET /invoices/inv_100 का अनुरोध करता है, और ऐलिस का इनवॉइस प्राप्त करता है। हमलावर ने न तो कोई टोकन चुराया, न ही लॉगिन को बायपास किया, और न ही पासवर्ड का अनुमान लगाया। बॉब ने एक रूट में ऑब्जेक्ट आइडेंटिफायर बदल दिया, जिसे सर्वर ने यह जांचे बिना स्वीकार कर लिया कि inv_100 बॉब का है या नहीं। इसलिए, डिफेंडर का सवाल इस बात से कहीं अधिक सीमित और उपयोगी है कि क्या लॉगिन काम करता है। क्या हर अनुरोध के लिए API यह साबित करता है कि प्रमाणित प्रिंसिपल (authenticated principal) इस ऑब्जेक्ट पर यह ऑपरेशन कर सकता है?
हमारा चालू आर्टिफैक्ट एक छोटा REST API है जिसमें POST /login, GET /invoices/{invoiceId}, PUT /invoices/{invoiceId}, और GET /admin/audit शामिल हैं। ऐलिस के पास inv_100 है, बॉब के पास inv_200 है, और एक एडमिनिस्ट्रेटर ऑडिट रिकॉर्ड पढ़ सकता है। एक थ्रेट मॉडल यह पहचानता है कि हमलावर का पहले से किस पर नियंत्रण है, अनुरोध किस सीमा (boundary) को पार करता है, हमलावर क्या चाहता है, और सर्वर का कौन सा निर्णय अनुरोध को रोकना चाहिए। यहाँ, बॉब का अपने प्रमाणित अनुरोध और invoiceId पर नियंत्रण है; वह ऐलिस का इनवॉइस चाहता है; डेटा के स्टोर से बाहर निकलने से पहले ऑथराइजेशन को एक्सेस को अस्वीकार कर देना चाहिए।
ऑथेंटिकेशन यह स्थापित करता है कि अनुरोध बॉब की ओर से आया है। ऑथराइजेशन को अभी भी यह तय करना होगा कि क्या बॉब inv_100 को पढ़ सकता है। उन निर्णयों को एक ही जांच के रूप में मानने से विफलता होती है, क्योंकि एक वैध पहचान ओनरशिप या प्रशासनिक विशेषाधिकार के बारे में कुछ नहीं बताती है। पूरे कोर्स के दौरान हमारा लक्ष्य इसी API को सुरक्षित (harden) बनाना और यह साबित करना है कि परीक्षण के दौरान प्रत्येक सीमा (boundary) कायम रहती है। निम्नलिखित मैप उन सीमाओं को दिखाता है जिन्हें बॉब पार करता है।
यह डायग्राम दिखाता है कि कोई रिक्वेस्ट ऑथेंटिकेशन में तो पास हो सकती है, लेकिन ऑथराइजेशन या डेटा एक्सेस में फेल हो सकती है। ऑब्जेक्ट आइडेंटिफ़ायर तब खतरनाक हो जाता है जब API उसका इस्तेमाल करके कोई रिकॉर्ड तो निकालता है, लेकिन उस रिकॉर्ड को ऑथेंटिकेटेड यूज़र (प्रिंसिपल) से लिंक नहीं करता।
ओनरशिप चेक का न होना OWASP API सिक्योरिटी टॉप 10 2023 में API1:2023 Broken Object Level Authorization (BOLA) है। कोई भी एंडपॉइंट जो क्लाइंट-कंट्रोल्ड ऑब्जेक्ट ID लेता है, उसे उस ऑब्जेक्ट के लिए ऑथराइजेशन फ़ैसले की ज़रूरत होती है। GET /invoices/inv_100 और PUT /invoices/inv_100 अलग-अलग ऑपरेशन हैं, इसलिए दोनों के लिए अलग-अलग फ़ैसले की ज़रूरत होती है, भले ही दोनों एक ही इनवॉइस का ज़िक्र कर रहे हों।
शुरुआती अन्य जोखिम भी इसी रिक्वेस्ट पाथ से जुड़े हैं। API2:2023 Broken Authentication का संबंध इस बात से है कि क्या API बॉब की सही पहचान करता है। API3:2023 Broken Object Property Level Authorization का संबंध इस बात से है कि क्या इनवॉइस का रिस्पॉन्स ऐसे फ़ील्ड दिखाता या स्वीकार करता है जिन्हें बॉब को एक्सेस नहीं करना चाहिए, जैसे कि इंटरनल approvalLimit। API4:2023 Unrestricted Resource Consumption का संबंध बॉब द्वारा इतनी बार महंगी रिक्वेस्ट भेजने से है कि कैपेसिटी खत्म हो जाए या पेड डाउनस्ट्रीम काम शुरू हो जाए। API5:2023 Broken Function Level Authorization का संबंध बॉब के एडमिनिस्ट्रेटिव परमिशन न होने के बावजूद GET /admin/audit तक पहुँचने से है।
हर कैटेगरी रिक्वेस्ट के अलग हिस्से को बदलती है, लेकिन सभी यह टेस्ट करती हैं कि क्या सर्वर क्लाइंट इनपुट, सिर्फ़ टोकन या एंडपॉइंट के नाम पर भरोसा करने के बजाय कोई बाउंड्री लागू करता है। टेबल अटैकर द्वारा किए गए बदलाव, सुरक्षित परिणाम और डिफेंडर को ज़रूरी सबूतों का आकलन करती है।