API property-level authorization: data exposure और mass assignment रोकें
Explicit response और request allowlists, सुरक्षित update models तथा excessive data exposure और mass assignment के tests से SaaS API fields पर नियंत्रण रखें।
इस मार्गदर्शिका में
API property-level authorization क्या है और इसे कैसे लागू करें?
Object-level authorization बताता है कि व्यक्ति किसी record तक पहुँच सकता है या नहीं; property-level authorization बताता है कि record के कौन-से fields वह देख या बदल सकता है। हर API response उन fields से बनाएँ जिनकी caller को जरूरत है और हर update में केवल उन्हीं fields को स्वीकार करें जिन्हें caller बदल सकता है। पूरे database model को serialize या मनमाने request body से bind न करें। इससे record तक वैध पहुँच होने पर भी excessive data exposure और mass assignment का जोखिम घटता है।
हर audience और action के लिए केवल जरूरी fields लौटाएँ
Response DTO, resource serializer या schema में public fields जानबूझकर चुनें। अपना account देखने वाले customer को display name और plan चाहिए हो सकता है, लेकिन internal risk notes, authentication factors, billing-provider secrets या moderation flags नहीं। Nested GraphQL और REST objects पर भी यही नियम रखें और model में नए fields जुड़ने पर समीक्षा करें।
Update के लिए उद्देश्य-विशेष field list रखें
Request input को ऐसे command या update object में map करें जिसमें केवल वही fields हों जिन्हें यह action बदल सकता है। Raw JSON को ORM model, user object या administrative record पर mass-assign न करें। Tenant, account status, billing state, role, verification state और ownership जैसी values customer request से लेने के बजाय server पर निकालें।
Caller, object और action के अनुसार field permission लागू करें
किसी field को पढ़ना संभव लेकिन लिखना निषिद्ध हो सकता है; या वह केवल owner, administrator अथवा खास workflow step में बदल सकता है। Business action के साथ ये नियम तय करें और अनजाने fields पर access रोकें। Interface में control छिपाने से client API को सीधे वही field भेजने से नहीं रुकता।
| Endpoint और role | लौटाए गए object fields | Update के लिए स्वीकार fields | Server पर तय होने वाले fields | Read/write tests और owner |
|---|---|---|---|---|
| Profile: member | ||||
| Billing: workspace owner | ||||
| Moderation: support operator |
Field exposure रोकने के लिए कौन-से design choices अपनाएँ?
Public response schema को database model से अलग रखें
Database model में internal workflows के लिए fields हो सकते हैं। API response shape अलग बनाएँ, उसमें न्यूनतम जरूरी values चुनें और जहाँ उचित हो sensitive endpoint के response को validate करें। `toJSON` जैसे generic serialization को default contract न मानें, खासकर जब model में समय के साथ नए columns जुड़ते हों।
Create, patch और bulk operations में explicit input validation रखें
ऐसा validation जो model की कोई भी पहचानी property स्वीकार करता है, फिर भी caller को निषिद्ध field बदलने दे सकता है। हर operation, role और API version के लिए field allowlist बनाएं; अतिरिक्त fields reject करें या उनका व्यवहार एकसमान तय करें। यही जाँच imports, GraphQL mutations, background jobs और bulk endpoints पर भी होनी चाहिए।
Hidden, derived और workflow fields को संवेदनशील समझें
`isAdmin`, `verified`, `approved`, `blocked`, `price`, `creditLimit`, `tenantId` और `ownerId` जैसे fields access या money flow बदल सकते हैं। इन्हें अलग server-side workflow में निकालें या बदलें, जिसमें authorization, validation और audit trail हों। केवल इसलिए इन्हें स्वीकार न करें कि database में column मौजूद है।
Property-level access flaws के tests कैसे करें?
अतिरिक्त data पढ़ने और unauthorized बदलाव, दोनों test करें
हर role और object type पर लौटाए गए fields की approved schema से तुलना करें। फिर create, patch, nested update और bulk operations में अतिरिक्त fields भेजकर देखें कि protected values नहीं बदलतीं। ऐसा user भी test करें जो object का owner हो, फिर भी हर property देखने या बदलने का अधिकारी न हो।
Role, tenant और workflow state के संयोजन जाँचें
अलग tenants में member, owner, support operator और सीमित या suspended account को test करें। Approval, payment, verification या moderation state बदलने से पहले और बाद में fields देखें। Error rejected secret को उजागर न करे और कोई आधा बदलाव commit न हो।
Schema और model बदलावों के साथ regression checks जोड़ें
नया field data model, API serializer या GraphQL type में आए तो पूछें कि क्या यह public है, कौन-से role इसे पढ़ सकते हैं और कौन-सा operation इसे लिख सकता है। Explicit field list पर आधारित tests रखें ताकि नया column चुपचाप public response का हिस्सा न बने। Schema change के बाद API versions और generated clients भी जाँचें।
API property-authorization के सवाल
क्या record का owner होने पर user को हर field दिखा सकते हैं?
नहीं। Record तक पहुँच का मतलब internal या sensitive properties देखने की अनुमति नहीं है। उस operation और role के लिए जरूरी fields ही लौटाएँ।
क्या mass assignment तभी समस्या है जब user किसी दूसरे का record बदले?
नहीं। व्यक्ति अपना record बदलते हुए भी role, verification, billing या अन्य protected fields बदलने का अधिकारी नहीं हो सकता। Record permission के साथ field permission भी जाँचें।
क्या frontend में admin field छिपाना उसे सुरक्षित करता है?
नहीं। Client सीधे API request भेज सकता है। जिस field को पढ़ने या बदलने की अनुमति नहीं है, server उसे reject करे।
क्या API को अनजान update fields reject करने चाहिए?
Sensitive operations में सख्त allowlist सबसे स्पष्ट तरीका है। जो भी व्यवहार चुनें, उसे लिखें और test करें; बिना समीक्षा वाले fields को persistence model से चुपचाप bind न करें।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .