SaaS API BOLA prevention: object-level authorization checklist
हर request पर signed-in user, tenant policy और relationship के आधार पर हर record तथा action जाँचकर SaaS APIs में broken object-level authorization रोकें।
इस मार्गदर्शिका में
Broken object-level authorization (BOLA) क्या है?
Broken object-level authorization (BOLA) तब होता है जब API object identifier स्वीकार करती है लेकिन यह नहीं जाँचती कि signed-in user उस खास record पर माँगा गया action कर सकता है या नहीं। Endpoint चलाने की अनुमति होने पर भी user को दूसरे tenant का object पढ़ने, बदलने या हटाने का अधिकार जरूरी नहीं। हर object access पर server-side authorization जाँचें; random ID, छिपे हुए interface controls और authentication अपने-आप access control नहीं हैं।
User, object और माँगे गए action को साथ authorize करें
Record पढ़ने या बदलने वाली हर request में current identity, object का tenant या owner संबंध, माँगा गया operation और product के sharing rules जाँचें। केवल user ID की object ID से तुलना पर्याप्त नहीं, क्योंकि teams, delegated roles या shared resources भी हो सकते हैं। API, web और background-job रास्ते में एक जैसी policy लगाएँ।
Database access को authorized tenant या relationship तक सीमित करें
Tenant context trusted authenticated identity से लें और केवल user के योग्य records query करें। Client-supplied ID से global object load करके यह न मानें कि interface ने पहले filter किया होगा। Nested resources, bulk operations, GraphQL resolvers, exports, search results और async jobs पर भी policy लागू करें।
Object access और property-level permissions अलग रखें
User को record देखने की अनुमति हो सकती है, पर owner, billing status, role या security settings बदलने की नहीं। हर operation में कौन-से fields पढ़ या बदल सकता है validate करें और unexpected fields reject करें। Object-level और property-level authorization अलग निर्णय हैं; दोनों की जरूरत हो सकती है।
| Role / tenant संबंध | Object type | Read / update / delete | Server-side policy | Cross-tenant test |
|---|---|---|---|---|
| Member | Report | |||
| Workspace owner | Member record | |||
| Support operator | Customer export |
SaaS teams object-level authorization लगातार कैसे लागू करें?
Caller द्वारा भेजे ownership पर भरोसा किए बिना policy तय करें
स्पष्ट authorization policy या domain service रखें ताकि controllers, resolvers और jobs एक जैसे rules लागू करें। Request body से आए IDs, tenant names और ownership fields को untrusted मानें; server authoritative records से संबंध निकाले या verify करे। Identity या tenant context न हो तो policy fail closed करे।
हर method और collection path पर authorization लगाएँ
GET, POST, PATCH, PUT, DELETE, bulk actions, list filters, nested routes और दूसरे API versions जाँचें। Detail endpoint सुरक्षित होने से फायदा नहीं यदि export, search या batch job वही objects बिना जाँच लौटा दे। Denied request पर कोई बदलाव आंशिक रूप से लागू न हो और error से संवेदनशील fields उजागर न हों।
Unpredictable identifiers को केवल अतिरिक्त सुरक्षा मानें
UUID या opaque ID से सामान्य enumeration कठिन हो सकती है, लेकिन वे permission साबित नहीं करते। ID notification, browser history, log, shared link या API response से copy हो सकती है। कठिन अनुमान लगने वाली ID होने पर भी object-level authorization जाँचें।
SaaS tenants और roles में BOLA कैसे test करें?
Cross-tenant और role-based test matrix बनाएँ
कम-से-कम दो अलग test tenants, अलग users और records बनाएँ; जहाँ लागू हो member, owner और support staff roles जोड़ें। हर object type पर allowed और denied read, update, delete तथा bulk actions चलाएँ। Shared records और delegated access को सामान्य tenant ownership से अलग test करें।
दूसरे user की object ID से API boundary जाँचें
Controlled environment में एक test user से authenticate होकर दूसरे test user के object की request करें। पुष्टि करें कि server path, query, header या body identifier बदलने पर भी sensitive fields बताए बिना operation रोकता है। Client ID लेने वाले हर endpoint और nested relation पर दोहराएँ।
Regression tests जोड़ें और denied access patterns audit करें
Automated tests रखें जो APIs, jobs और exports में user को दूसरे tenant का record मिलने से रोकें। Principal, object type, operation, tenant context और निर्णय को सुरक्षित रूप से log करें; record का sensitive content नहीं। बार-बार cross-tenant denial पर alert दें और release से पहले policy changes review करें।
SaaS BOLA prevention के सवाल
क्या UUID या कठिन अनुमान वाली ID BOLA रोकती है?
नहीं। इससे सामान्य enumeration कठिन हो सकती है, लेकिन caller को record access की अनुमति साबित नहीं होती। हर request पर object और operation के लिए authorization लागू करें।
क्या API object बचाने के लिए authentication पर्याप्त है?
नहीं। Authentication caller की पहचान करती है; authorization तय करती है कि वह caller किसी record पर खास action कर सकता है या नहीं। Server पर tenant membership, ownership, sharing और role policy जाँचें।
क्या tenant-ID की तुलना हमेशा पर्याप्त है?
अपने-आप नहीं। कुछ records shared या delegated हो सकते हैं और request में भेजा tenant value forged हो सकता है। Context trusted identity से लें और product की असली access policy लागू करें।
क्या सुरक्षित web interface API को भी सुरक्षित साबित करता है?
नहीं। API को सीधे call किया जा सकता है और background jobs या exports अलग code paths अपना सकते हैं। हर route, resolver, job और bulk operation पर server-side authorization लागू करें।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .