तुमच्या अ‍ॅपमध्ये भूमिका-आधारित प्रवेश नियंत्रण (RBAC) कसे जोडावे

भूमिका-आधारित प्रवेश नियंत्रण जोडण्यासाठी, प्रत्येक वापरकर्त्याला एक किंवा अधिक भूमिका द्या (उदाहरणार्थ admin, editor, viewer), प्रत्येक भूमिका कोणत्या क्रिया करू शकते ते ठरवा, आणि प्रत्येक विनंतीसाठी त्या परवानग्या सर्व्हरवर तपासा — फक्त बटणे लपवून नव्हे. तसेच प्रवेश होत असलेला रेकॉर्ड वापरकर्त्याच्या खात्याचा किंवा टीमचा आहे का ते तपासा. तुमच्या डेटाबेसमध्ये काही निश्चित भूमिकांपासून सुरुवात करा, आणि थेट दुसऱ्या वापरकर्त्याच्या डेटापर्यंत पोहोचण्याचा प्रयत्न करून चाचणी करा.

Authentication विरुद्ध authorisation

दोन शब्द ज्यांची सहसा गल्लत होते:

• Authentication म्हणजे तू कोण आहेस? — लॉग इन करणे. तुमच्या अ‍ॅपमध्ये लॉगिन कसे जोडावे पहा.
• Authorisation म्हणजे तुला काय करण्याची परवानगी आहे? — लॉग-इन केलेला वापरकर्ता कोणती पाने, रेकॉर्ड्स आणि क्रिया गाठू शकतो.

RBAC हा authorisation करण्याचा सर्वात सामान्य मार्ग आहे. हे महत्त्वाचे आहे: सप्टेंबर 2026 पर्यंत, Broken Access Control हा OWASP Top 10:2025 मध्ये क्रमांक 1 वर आहे, जी वेब अ‍ॅप्लिकेशन सुरक्षेच्या सर्वात गंभीर धोक्यांची व्यापक वापरली जाणारी यादी आहे. ठराविक अपयश म्हणजे URL मधील ID बदलून वापरकर्त्यांनी इतरांचे रेकॉर्ड वाचणे, किंवा सामान्य वापरकर्त्यांनी फक्त-admin API मार्गांना कॉल करणे.

मॉडेल निवडा

प्रत्यक्षात बहुतेक अ‍ॅप्स दोन गोष्टी एकत्र करतात: कोणत्या प्रकारच्या क्रिया कोण करू शकतो यासाठी भूमिका, आणि कोणत्या रेकॉर्ड्सवर करू शकतो यासाठी मालकी. "Editors पोस्ट संपादित करू शकतात" हा भूमिकेचा नियम आहे; "…त्यांच्या स्वतःच्या workspace मधील पोस्ट" हा मालकीचा नियम आहे. तुम्हाला दोन्ही हवे आहेत.

तुम्हाला वाटते त्यापेक्षा सोपे सुरू करा. Admin, member आणि viewer अनेक अ‍ॅप्ससाठी पुरेसे आहेत. दहा भूमिका ज्या कोणालाच नीट समजत नाहीत त्या उलगडण्यापेक्षा नंतर एक भूमिका विभागणे सोपे आहे.

कोड लिहिण्यापूर्वी भूमिका ठरवा

साध्या भाषेत आधी परवानग्यांचा टेबल लिहा. तो AI साठी स्पेक आणि तुमची चाचणी योजना दोन्ही म्हणून काम करतो:

कडा प्रकरणेही ठरवा: शेवटचा मालक सोडू शकतो का? Admin मालकाला काढू शकतो का? काढलेल्या वापरकर्त्याला काय दिसते?

टप्प्याटप्प्याने

1. आधी काम करणारे लॉगिन ठेवा

RBAC authentication वर बसतो. प्रत्येक विनंती कोण करत आहे हे सर्व्हरला विश्वसनीयपणे माहीत असले पाहिजे, session किंवा सत्यापित token वरून — कधीही browser ने request body मध्ये पाठवलेल्या user ID वरून नव्हे.

2. भूमिका डेटाबेसमध्ये साठवा

एकाच टीमच्या अ‍ॅपसाठी users वर role कॉलम पुरेसा आहे. टीम्ससाठी, मेंबरशिप टेबल वापरा:

create table memberships (
  user_id uuid references users(id),
  organization_id uuid references organizations(id),
  role text not null check (role in ('owner','admin','member','viewer')),
  primary key (user_id, organization_id)
);

सामान्य profile अपडेटमधून वापरकर्त्यांना स्वतःची भूमिका कधीही सेट करू देऊ नका. भूमिका बदल एका समर्पित, परवानगी-तपासलेल्या endpoint मधून जावेत.

3. परवानग्या सर्व्हरवर, एकाच ठिकाणी तपासा

एक helper लिहा — जसे can(user, 'projects.delete', project) — आणि डेटा वाचणाऱ्या किंवा बदलणाऱ्या प्रत्येक API route, server action आणि background task मध्ये तो कॉल करा. एकच मध्यवर्ती फंक्शन कोडभर विखुरलेल्या तपासण्यांपेक्षा पुनरावलोकन आणि चाचणीसाठी सोपे आहे. डीफॉल्टनुसार नाकारा: जर कोणताही नियम क्रियेला परवानगी देत नसेल, तर ती नाकारली जाते.

4. प्रत्येक क्वेरी मर्यादित करा

टीमच्या डेटासाठी प्रत्येक क्वेरीत टीम समाविष्ट असावी: where id = :id नव्हे तर where organization_id = :currentOrg. यामुळेच कोणी /projects/123 ला /projects/124 करून दुसऱ्या कंपनीचा प्रोजेक्ट पाहू शकत नाही. इतर टीम्सच्या रेकॉर्ड्ससाठी "forbidden" ऐवजी "not found" परत करा, म्हणजे ते अस्तित्वात असल्याचे उघड होत नाही.

5. जिथे महत्त्वाचे तिथे डेटाबेस-स्तरावरील संरक्षण जोडा

Postgres row-level security (RLS) डेटाबेसला ठरवू देते की कोणते रो प्रत्येक वापरकर्ता पाहू शकतो. जर browser थेट डेटाबेसशी बोलत असेल (काही होस्ट केलेल्या backends प्रमाणे), तर ते अत्यावश्यक आहे, आणि इतर बाबतीत संवेदनशील टेबल्ससाठी उपयुक्त दुसरा स्तर आहे.

6. इंटरफेसमध्ये भूमिका दाखवा

आता वापरकर्ते जे करू शकत नाहीत ते लपवा किंवा निष्क्रिय करा, जेणेकरून अ‍ॅप गोंधळात टाकणार नाही. हे फक्त वापरण्यायोग्यतेसाठी आहे; संरक्षण सर्व्हर तपासण्या करतात.

7. संवेदनशील क्रियांची नोंद ठेवा

कोणी भूमिका बदलल्या, डेटा हटवला किंवा रेकॉर्ड्स निर्यात केले आणि कधी ते नोंदवा. Audit log सपोर्ट प्रश्न आणि घटनांसाठी उपयोगी ठरतो.

8. हल्लेखोरासारखी चाचणी करा

प्रत्येक भूमिकेने लॉग इन करा आणि परवानग्या टेबलमधील प्रत्येक क्रिया करून पहा. मग जे चालू नये ते करून पहा: viewer म्हणून admin API मार्ग कॉल करा, URL आणि विनंत्यांमधील ID बदला, स्वतःला शेवटचा मालक म्हणून काढा. नियम स्थिर झाल्यावर परवानग्या टेबलसाठी स्वयंचलित चाचण्या लिहिणे फायदेशीर आहे.

उपयोगी प्रॉम्प्ट्स

भूमिका-आधारित प्रवेश नियंत्रण जोडा. प्रति organisation भूमिका: owner, admin, member, viewer, memberships टेबलमध्ये साठवलेल्या. परवानग्या या टेबलमध्ये आहेत: [तुमचा टेबल पेस्ट करा]. एक सर्व्हर-साइड can(user, action, resource) helper तयार करा, डीफॉल्टनुसार नाकारा, आणि प्रत्येक API route मध्ये वापरा. प्रत्येक क्वेरी organization_id नुसार मर्यादित करा. वापरकर्ता करू शकत नाही अशा क्रिया UI मध्ये लपवा, पण सुरक्षेसाठी त्यावर कधीही अवलंबून राहू नका.

या अ‍ॅपमधील प्रत्येक API route आणि server function तपासा. प्रत्येकासाठी यादी द्या: ते कोणता डेटा वाचते किंवा बदलते, वापरकर्ता लॉग इन आहे का ते तपासते का, त्याची भूमिका तपासते का, आणि क्वेरी त्याच्या organisation नुसार मर्यादित करते का. ज्यात तपासणी नाही ते दुरुस्त करा, आणि मला यादी दाखवा.

फक्त-admin /admin पान जोडा जिथे owner सदस्यांच्या भूमिका बदलू शकेल. शेवटच्या owner ला काढणे किंवा त्याची पदावनती प्रतिबंधित करा, प्रत्येक भूमिका बदल कोणी आणि कधी केला ते नोंदवा, आणि owner नसलेल्या कोणालाही भूमिका-बदल endpoint नाकारेल याची खात्री करा.

सामान्य चुका

• भूमिका फक्त फ्रंट एंडवर तपासणे. API तरीही कोणीही कॉल करू शकणारा खुला राहतो.
• क्लायंटकडून आलेल्या IDs वर विश्वास ठेवणे — session ऐवजी request body मधील userId किंवा role.
• अनमर्यादित क्वेरी जे फक्त रेकॉर्ड ID ने आणतात.
• पानांवर भूमिका तपासणे पण API routes, निर्यात, फाइल डाउनलोड किंवा webhooks वर नाही.
• कोडमध्ये ईमेल पत्त्याने admin ठरवणे (if email === 'me@...'), जे विसरणे सोपे आणि बदलणे कठीण आहे.
• खूप लवकर खूप भूमिका, ज्या सहा महिन्यांनी कोणालाच स्पष्ट करता येत नाहीत.
• जुने sessions: पदावनती झालेला वापरकर्ता लॉग आउट होईपर्यंत admin अधिकार ठेवतो. संवेदनशील क्रियांवर डेटाबेसमधून भूमिका तपासा, किंवा त्या रिफ्रेश करा.

RBAC चेकलिस्ट

• साध्या भाषेत लिहिलेला परवानग्या टेबल, कडा प्रकरणे ठरवलेली
• सर्व्हरला session वरून वापरकर्ता माहीत आहे, कधीही request data वरून नव्हे
• भूमिका डेटाबेसमध्ये साठवलेल्या; वापरकर्ते स्वतःच्या बदलू शकत नाहीत
• एक मध्यवर्ती परवानगी तपासणी, डीफॉल्टनुसार नाकारणारी, प्रत्येक route मध्ये वापरलेली
• प्रत्येक क्वेरी वापरकर्त्याच्या organisation किंवा मालकीनुसार मर्यादित
• जिथे browser डेटाबेसपर्यंत पोहोचू शकतो तिथे row-level security
• UI वापरकर्ता करू शकत नसलेल्या क्रिया लपवते (फक्त वापरण्यायोग्यतेसाठी)
• संवेदनशील क्रियांची नोंद
• प्रत्येक भूमिका तपासली, थेट API कॉल्स आणि बदललेल्या IDs सह

प्रवेश नियंत्रण हा एका मोठ्या यादीतील एक मुद्दा आहे; AI-निर्मित अ‍ॅप्ससाठी सुरक्षा चेकलिस्ट बाकीचे कव्हर करते. तुम्ही तुमच्या स्वतःच्या कर्मचाऱ्यांसाठी टूल बनवत असाल, तर अंतर्गत टूल कसे बनवावे दाखवते की भूमिका कुठे बसतात.

Mythex वर RBAC

Mythex तुमच्या अ‍ॅपच्या वापरकर्त्यांसाठी अंगभूत लॉगिन किंवा भूमिका प्रणाली देत नाही. तुम्ही auth लायब्ररी किंवा प्रदाता निवडता आणि भूमिका वर्णन करता, आणि एजंट त्या तुमच्या कोडमध्ये आणि प्रोजेक्टच्या Postgres डेटाबेसमध्ये जोडतो (तुमच्या अ‍ॅपमध्ये लॉगिन जोडा). Mythex ची स्वतःची workspace भूमिका, जसे Owner आणि Member, तुमचे Mythex प्रोजेक्ट्स कोण संपादित करू शकतो ते नियंत्रित करते, तुम्ही प्रकाशित केलेले अ‍ॅप कोण वापरू शकतो ते नव्हे. बांधण्यापूर्वी परवानग्या टेबलवर सहमत होण्यासाठी Plan mode वापरा, मग वरील पुनरावलोकन प्रॉम्प्ट वापरा आणि प्रकाशित करण्यापूर्वी Preview मध्ये प्रत्येक भूमिका तपासा. docs मधील security prompts हे उपयुक्त पुढचे पाऊल आहे.

प्रश्न