SaaS API में function-level authorization
SaaS API में function-level authorization सुरक्षित करने के लिए default deny, role व tenant checks और privileged actions के direct tests अपनाएँ।
इस मार्गदर्शिका में
Function-level authorization क्या है और SaaS API इसे कैसे लागू करे?
Function-level authorization तय करता है कि caller को invite भेजने, data export करने, billing बदलने या tenant administer करने जैसे operation की अनुमति है या नहीं। यह authentication से अलग है, जो caller की पहचान करता है; और object-level authorization से भी अलग है, जो किसी खास record तक access जाँचता है। हर operation, role और tenant context पर explicit server-side permission check रखें और बाकी को deny करें। Hidden button या `/admin` URL access-control boundary नहीं है।
केवल role name नहीं, action के आधार पर permission परिभाषित करें
Role बदलना, API key जारी करना, data export, workspace हटाना और payment setting बदलना जैसे sensitive operations सूचीबद्ध करें। हर action को उस role, tenant relationship और workflow condition से जोड़ें जो उसे अनुमति देता है। Permission सीमित व समझने योग्य रखें; `manager` जैसा व्यापक नाम अपने-आप असंबंधित admin features न खोले।
Server-side business operation में permission जाँचें
हर controller, resolver, job और service path से एकसमान policy या authorization service चलाएँ जो action करता है। केवल frontend, URL prefix, HTTP method, gateway rule या client से आए role claim पर निर्भर न रहें। किसी खास record से जुड़े action पर function permission और object-level permission दोनों लागू करें।
Unknown और नए functions को default रूप से denied रखें
Endpoint या operation उपलब्ध करने से पहले explicit grant जरूरी रखें। Code review में नए routes, GraphQL mutations, पुराने API versions, exports और admin functions भी जाँचें। Identity, tenant या policy decision न मिले तो access रोकें और कोई partial change किए बिना सुरक्षित denial लौटाएँ।
| Function/operation | Member | Workspace owner | Support/platform role | Negative test और owner |
|---|---|---|---|---|
| Member invite या removal | ||||
| Tenant data export | ||||
| Role, billing या security setting |
कौन-सी authorization गलतियाँ privileged API functions खोल देती हैं?
Route name या client interface से privilege का अनुमान न लगाएँ
Privileged function सामान्य `/users` route, GraphQL mutation या केवल mobile endpoint में हो सकता है। Attacker API सीधे call, HTTP method बदल या interface के बिना request replay कर सकता है। Protected state पढ़ने या बदलने वाले action पर server-side policy लागू करें।
Roles, groups और tenant संबंध हर request में सही जाँचें
किसी व्यक्ति के अलग workspaces में अलग roles हो सकते हैं, वह nested groups में हो सकता है या उसे अस्थायी delegated permission मिल सकती है। हर request पर trusted server data से सही tenant और मौजूदा membership निकालें। जब अधिकार एक workspace या action तक सीमित हो, तब global role flag न रखें।
Background और support operations भी सुरक्षित करें
Exports, scheduled jobs, support tools और internal service endpoints वही privileged functions खोल सकते हैं जो web controller में हैं। Queued काम में authenticated actor या service identity आगे भेजें, अनुमति का कारण दर्ज करें और sensitive बदलाव audit करें। Internal network या hidden route को authorization न मानें।
Function-level authorization का test कैसे करें?
Role-by-function matrix बनाएँ और हर denied cell test करें
हर operation पर anonymous caller और member, owner, support व administrator जैसे test accounts चलाएँ। API से सीधे निषिद्ध action आजमाएँ, जिसमें alternate methods, routes, GraphQL mutations और versions शामिल हों। पुष्टि करें कि data leak या state change से पहले denial आता है।
Cross-tenant और बदली हुई membership की स्थिति जाँचें
अलग test tenants बनाकर गलत tenant context में privileged function चलाएँ; role हटाने, invite revoke करने और account suspend होने के बाद भी test करें। Queued work authority फिर से जाँचे या जानबूझकर लिया गया auditable authorization decision आगे ले जाए—पुराने client state पर निर्भर न रहे।
Function policy के साथ regression tests रखें
नया operation जोड़ते या role नियम बदलते समय अनुमत और निषिद्ध callers के tests जोड़ें। Sensitive payload log किए बिना authorization outcome देखें; अनपेक्षित allow या denial की जाँच करें। API gateway, identity provider या role model बदले तो matrix फिर चलाएँ।
Function-level authorization के सवाल
क्या authenticated user हर API endpoint call कर सकता है?
नहीं। Authentication caller की पहचान करता है; function-level authorization तय करता है कि वह कौन-से operation कर सकता है। हर sensitive action पर permission जाँचें।
क्या `/admin` URL बताता है कि endpoint सुरक्षित है?
नहीं। Route का नाम security control नहीं है। Path या interface admin जैसा दिखे तब भी server-side operation पर authorization जाँचें।
क्या function authorization और object-level authorization एक ही हैं?
नहीं। Function-level check करता है कि caller operation कर सकता है या नहीं; object-level check करता है कि वह इसे किसी खास record पर कर सकता है या नहीं। कई requests को दोनों चाहिए।
क्या नए operations हर authenticated role के लिए default खुले होने चाहिए?
नहीं। Default deny रखें और जरूरत वाले roles व tenant contexts को स्पष्ट अनुमति दें। इससे नया route चुपचाप access नहीं बढ़ाता।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .