एक नोट्स एप्लीकेशन एलिस को Quarterly budget draft को नोट 1 के तौर पर सेव करने की सुविधा देती है। बॉब अपने अकाउंट में साइन इन करता है, GET /notes/1 के लिए रिक्वेस्ट करता है, और उसे एलिस का नोट मिल जाता है क्योंकि सर्वर यह तो चेक करता है कि बॉब लॉग इन है, लेकिन यह कभी चेक नहीं करता कि नोट 1 का मालिक बॉब है या नहीं। बॉब को न तो एलिस के पासवर्ड की ज़रूरत थी और न ही किसी खास एक्सेस की, बस एक ऐसे आइडेंटिफ़ायर की ज़रूरत थी जिसका अंदाज़ा लगाया जा सके। अगर बॉब नोट 1 के लिए रिक्वेस्ट करता है, तो क्या API को एलिस का कंटेंट दिखाना चाहिए? नीचे दिया गया छोटा लोकल उदाहरण असुरक्षित रिक्वेस्ट और रिस्पॉन्स को दिखाता है:
यह कोड बॉब को एक्टिव यूज़र के तौर पर पहचानते हुए ऐलिस का JSON रिकॉर्ड देता है। इसमें दिखने वाली खराबी ब्रोकन एक्सेस कंट्रोल है, जहाँ सर्वर किसी ऑथेंटिकेटेड व्यक्ति को उसकी अनुमति के दायरे से बाहर कोई काम करने की इजाज़त देता है। इससे तुरंत बचाव का तरीका है नोट पढ़ने से पहले सर्वर-साइड पर ओनरशिप की जाँच करना, और इसका पता लगाने का संकेत एक लॉग एंट्री है जिसमें बॉब, नोट 1, और अस्वीकृत ऑथराइज़ेशन फ़ैसले का रिकॉर्ड होता है। हम इस एक नोट्स एप्लिकेशन को ठीक करते रहेंगे, ताकि हर सिक्योरिटी नियम एक रिक्वेस्ट, कोड के एक हिस्से और सुधार को वेरिफ़ाई करने के तरीके से जुड़ा रहे।
ओनरशिप की जाँच न होना इसलिए मायने रखता है क्योंकि ब्राउज़र API सर्वर की ट्रस्ट बाउंड्री (भरोसे की सीमा) के बाहर होता है। ट्रस्ट बाउंड्री वह बिंदु है जहाँ एप्लिकेशन को ऐसा डेटा या निर्देश मिलता है जिसे कोई दूसरी पार्टी प्रभावित कर सकती है, इसलिए सर्वर को इसे वैलिडेट करना चाहिए और अपने नियम लागू करने चाहिए। बॉब की कुकी और रिक्वेस्ट किया गया नोट ID एक अनट्रस्टेड क्लाइंट से सर्वर में जाते हैं; इसके बाद API ऑथराइज़ेशन का फ़ैसला लेने के बाद ही डेटाबेस क्वेरी भेजता है।
एक ही एप्लिकेशन में एक से ज़्यादा एंट्री पॉइंट होते हैं। कोई अन-ऑथेंटिकेटेड इंटरनेट यूज़र लॉगिन डेटा सबमिट कर सकता है या नोट बना सकता है। बॉब जैसा कम-प्रिविलेज वाला यूज़र लॉगिन के बाद नोट ID और नोट टेक्स्ट दे सकता है। बिल्ड के दौरान कोई कॉम्प्रोमाइज़्ड डिपेंडेंसी आ सकती है, जब पैकेज रजिस्ट्री ऐसा कोड देती है जिसे सर्वर बाद में चलाएगा। सुरक्षित रखने लायक एसेट्स हैं - एक्टिव सेशन, ऐलिस के नोट्स, सर्वर सीक्रेट्स और वे लॉग्स जो बताते हैं कि कौन सी रिक्वेस्ट की गईं। डायग्राम हर इनपुट को उस कंपोनेंट तक ले जाता है जिसे यह तय करना होता है कि उस पर भरोसा किया जाए या नहीं: