మీ యాప్‌కు రోల్-ఆధారిత యాక్సెస్ కంట్రోల్ (RBAC) ఎలా జోడించాలి

రోల్-ఆధారిత యాక్సెస్ కంట్రోల్ జోడించడానికి, ప్రతి వినియోగదారుకు ఒకటి లేదా అంతకంటే ఎక్కువ రోల్‌లు ఇవ్వండి (ఉదాహరణకు అడ్మిన్, ఎడిటర్, వ్యూయర్), ప్రతి రోల్ ఏ చర్యలు చేయగలదో నిర్వచించండి, మరియు ప్రతి రిక్వెస్ట్‌కు ఆ అనుమతులను సర్వర్‌లో తనిఖీ చేయండి — కేవలం బటన్‌లను దాచడం ద్వారా కాదు. యాక్సెస్ అవుతున్న రికార్డ్ వినియోగదారు ఖాతా లేదా టీమ్‌కు చెందినదో కూడా తనిఖీ చేయండి. మీ డేటాబేస్‌లో కొన్ని స్థిర రోల్‌లతో ప్రారంభించండి, మరియు మరో వినియోగదారు డేటాను నేరుగా చేరుకోవడానికి ప్రయత్నించి పరీక్షించండి.

ప్రామాణీకరణ vs అధికారం

కలిసిపోయే రెండు పదాలు:

• ప్రామాణీకరణ అంటే మీరు ఎవరు? — లాగిన్ చేయడం. మీ యాప్‌కు లాగిన్ ఎలా జోడించాలి చూడండి.
• అధికారం అంటే మీరు ఏమి చేయడానికి అనుమతించబడ్డారు? — లాగిన్ అయిన వినియోగదారు ఏ పేజీలను, రికార్డులను మరియు చర్యలను చేరుకోగలరు.

అధికారం అమలు చేయడానికి RBAC అత్యంత సాధారణ మార్గం. ఇది ముఖ్యం: సెప్టెంబర్ 2026 నాటికి, Broken Access Control OWASP Top 10:2025 లో #1, అంటే విస్తృతంగా ఉపయోగించే అత్యంత తీవ్రమైన వెబ్ అప్లికేషన్ భద్రతా ప్రమాదాల జాబితా. సాధారణ వైఫల్యాలు: URLలో ID మార్చడం ద్వారా వినియోగదారులు ఇతర వినియోగదారుల రికార్డులు చదవడం, లేదా సాధారణ వినియోగదారులు అడ్మిన్-మాత్రమే API మార్గాలను కాల్ చేయడం.

ఒక మోడల్ ఎంచుకోండి

ఆచరణలో చాలా యాప్‌లు రెండు విషయాలను కలుపుతాయి: ఎవరు ఎలాంటి చర్య చేయగలరో చెప్పే రోల్‌లు, మరియు ఏ రికార్డులపై చేయగలరో చెప్పే యాజమాన్యం. "ఎడిటర్లు పోస్ట్‌లను ఎడిట్ చేయగలరు" అనేది రోల్ నియమం; "…వారి స్వంత వర్క్‌స్పేస్‌లోని పోస్ట్‌లు" అనేది యాజమాన్య నియమం. మీకు రెండూ అవసరం.

మీరు అనుకున్నదానికంటే సరళంగా ప్రారంభించండి. అడ్మిన్, మెంబర్ మరియు వ్యూయర్ ఆశ్చర్యకరంగా చాలా యాప్‌లకు సరిపోతాయి. ఎవరికీ అర్థం కాని పది రోల్‌లను విడదీయడం కంటే, తర్వాత ఒక రోల్‌ను విభజించడం సులభం.

కోడ్ రాయడానికి ముందు రోల్‌లను డిజైన్ చేయండి

ముందుగా సాదా భాషలో అనుమతుల పట్టిక రాయండి. ఇది AIకి స్పెసిఫికేషన్‌గా మరియు మీ టెస్ట్ ప్లాన్‌గా కూడా పనిచేస్తుంది:

ఎడ్జ్ కేసులను కూడా నిర్ణయించండి: చివరి ఓనర్ వెళ్లిపోగలరా? అడ్మిన్ ఓనర్‌ను తొలగించగలరా? తొలగించబడిన వినియోగదారుకు ఏమి కనిపిస్తుంది?

దశలవారీగా

1. ముందుగా పని చేసే లాగిన్ ఉంచండి

RBAC ప్రామాణీకరణ పైన కూర్చుంటుంది. సర్వర్ ప్రతి రిక్వెస్ట్‌ను ఎవరు చేస్తున్నారో విశ్వసనీయంగా తెలుసుకోవాలి, సెషన్ లేదా ధృవీకరించిన టోకెన్ నుండి — రిక్వెస్ట్ బాడీలో బ్రౌజర్ పంపిన వినియోగదారు ID నుండి ఎప్పుడూ కాదు.

2. రోల్‌లను డేటాబేస్‌లో నిల్వ చేయండి

ఒకే-టీమ్ యాప్‌కు, వినియోగదారులపై 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)
);

సాధారణ ప్రొఫైల్ అప్‌డేట్ ద్వారా వినియోగదారులు తమ స్వంత రోల్‌ను సెట్ చేసుకోనివ్వవద్దు. రోల్ మార్పులు ప్రత్యేక, అనుమతి-తనిఖీ చేసే ఎండ్‌పాయింట్ ద్వారా మాత్రమే జరగాలి.

3. సర్వర్‌లో, ఒక చోట అనుమతులను తనిఖీ చేయండి

ఒక హెల్పర్ రాయండి — ఉదాహరణకు can(user, 'projects.delete', project) లాంటిది — మరియు డేటాను చదివే లేదా మార్చే ప్రతి API మార్గంలో, సర్వర్ యాక్షన్‌లో మరియు బ్యాక్‌గ్రౌండ్ టాస్క్‌లో దాన్ని కాల్ చేయండి. కోడ్ అంతటా చెదిరిన తనిఖీల కంటే ఒకే కేంద్ర ఫంక్షన్ సమీక్షించడానికి మరియు పరీక్షించడానికి సులభం. డిఫాల్ట్‌గా తిరస్కరించండి: ఏ నియమమూ ఒక చర్యను అనుమతించకపోతే, అది తిరస్కరించబడుతుంది.

4. ప్రతి క్వెరీని పరిమితం చేయండి

టీమ్ డేటా కోసం ప్రతి క్వెరీ టీమ్‌ను చేర్చాలి: కేవలం where id = :id కాకుండా where organization_id = :currentOrg. ఇదే ఎవరో /projects/123ని /projects/124గా మార్చి మరొక కంపెనీ ప్రాజెక్ట్ చూడకుండా ఆపుతుంది. ఇతర టీమ్‌ల రికార్డుల కోసం "forbidden" కాకుండా "not found" తిరిగి ఇవ్వండి, తద్వారా అవి ఉన్నాయని బయటపెట్టరు.

5. అవసరమైన చోట డేటాబేస్-స్థాయి రక్షణ జోడించండి

Postgres row-level security (RLS) ప్రతి వినియోగదారు ఏ వరుసలు చూడగలరో డేటాబేస్ స్వయంగా అమలు చేయడానికి అనుమతిస్తుంది. బ్రౌజర్ నేరుగా డేటాబేస్‌తో మాట్లాడితే (కొన్ని హోస్ట్ చేసిన బ్యాకెండ్‌ల వలె) ఇది అత్యవసరం, లేకపోతే సున్నితమైన టేబుల్‌లకు ఇది ఉపయోగకరమైన రెండవ పొర.

6. ఇంటర్‌ఫేస్‌లో రోల్‌లను ప్రతిబింబించండి

ఇప్పుడు వినియోగదారులు చేయలేనివాటిని దాచండి లేదా డిజేబుల్ చేయండి, తద్వారా యాప్ గందరగోళంగా ఉండదు. ఇది వినియోగానికి మాత్రమే; రక్షణ చేసేది సర్వర్ తనిఖీలే.

7. సున్నితమైన చర్యలను లాగ్ చేయండి

రోల్‌లు ఎవరు మార్చారు, డేటా ఎవరు తొలగించారు లేదా రికార్డులు ఎవరు ఎగుమతి చేశారు, మరియు ఎప్పుడు — రికార్డ్ చేయండి. ఆడిట్ లాగ్ సపోర్ట్ ప్రశ్నలు మరియు సంఘటనలకు సహాయపడుతుంది.

8. దాడిచేసేవారిలా పరీక్షించండి

ప్రతి రోల్‌గా లాగిన్ అయి, అనుమతుల పట్టికలోని ప్రతి చర్యను ప్రయత్నించండి. తర్వాత పని చేయకూడనివాటిని ప్రయత్నించండి: వ్యూయర్‌గా అడ్మిన్ API మార్గాలను కాల్ చేయండి, URLలు మరియు రిక్వెస్ట్‌లలో IDలు మార్చండి, చివరి ఓనర్‌గా మిమ్మల్ని మీరు తొలగించుకోండి. నియమాలు స్థిరపడిన తర్వాత అనుమతుల పట్టిక కోసం ఆటోమేటెడ్ టెస్ట్‌లు రాయడం విలువైనది.

పని చేసే ప్రాంప్ట్‌లు

రోల్-ఆధారిత యాక్సెస్ కంట్రోల్ జోడించండి. ప్రతి సంస్థకు రోల్‌లు: owner, admin, member, viewer, memberships పట్టికలో నిల్వ చేయబడినవి. అనుమతులు ఈ పట్టికలో ఉన్నాయి: [మీ పట్టికను అతికించండి]. ఒక సర్వర్-సైడ్ can(user, action, resource) హెల్పర్ సృష్టించండి, డిఫాల్ట్‌గా తిరస్కరించండి, మరియు ప్రతి API మార్గంలో ఉపయోగించండి. ప్రతి క్వెరీని organization_id ద్వారా పరిమితం చేయండి. వినియోగదారు చేయలేని చర్యలను UIలో దాచండి, కానీ భద్రత కోసం దానిపై ఎప్పుడూ ఆధారపడవద్దు.

ఈ యాప్‌లోని ప్రతి API మార్గాన్ని మరియు సర్వర్ ఫంక్షన్‌ను సమీక్షించండి. ప్రతిదానికి, అది ఏ డేటాను చదువుతుంది లేదా మారుస్తుంది, వినియోగదారు లాగిన్ అయ్యారో లేదో తనిఖీ చేస్తుందో, వారి రోల్‌ను తనిఖీ చేస్తుందో, మరియు క్వెరీని వారి సంస్థకు పరిమితం చేస్తుందో జాబితా చేయండి. తనిఖీ లేని వాటిని సరిచేసి, జాబితాను చూపండి.

అడ్మిన్-మాత్రమే /admin పేజీ జోడించండి, అక్కడ ఓనర్ సభ్యుల రోల్‌లు మార్చగలరు. చివరి ఓనర్‌ను తొలగించడం లేదా డిమోట్ చేయడం నిరోధించండి, ప్రతి రోల్ మార్పును ఎవరు మరియు ఎప్పుడు చేశారో లాగ్ చేయండి, మరియు ఓనర్ కానివారిని రోల్-మార్పు ఎండ్‌పాయింట్ తిరస్కరిస్తుందని నిర్ధారించండి.

సాధారణ తప్పులు

• ఫ్రంట్ ఎండ్‌లో మాత్రమే రోల్‌లను తనిఖీ చేయడం. API ఇంకా కాల్ చేసే ఎవరికైనా తెరిచే ఉంటుంది.
• క్లయింట్ నుండి వచ్చిన IDలను విశ్వసించడం — సెషన్‌కు బదులుగా రిక్వెస్ట్ బాడీలో userId లేదా role.
• పరిమితం కాని క్వెరీలు కేవలం రికార్డ్ ID ద్వారా తెచ్చేవి.
• పేజీలపై రోల్‌లు తనిఖీ చేసి API మార్గాలు, ఎగుమతులు, ఫైల్ డౌన్‌లోడ్‌లు లేదా వెబ్‌హుక్‌లపై తనిఖీ చేయకపోవడం.
• కోడ్‌లో హార్డ్-కోడ్ చేసిన ఇమెయిల్ చిరునామా ద్వారా అడ్మిన్ (if email === 'me@...'), ఇది మర్చిపోవడం సులభం మరియు మార్చడం కష్టం.
• చాలా ముందుగానే చాలా రోల్‌లు, ఆరు నెలల తర్వాత ఎవరూ వివరించలేనివి.
• పాత సెషన్‌లు: డిమోట్ చేయబడిన వినియోగదారు లాగ్ అవుట్ అయ్యే వరకు అడ్మిన్ హక్కులు కలిగి ఉంటారు. సున్నితమైన చర్యలపై, డేటాబేస్ నుండి రోల్‌లను తనిఖీ చేయండి లేదా వాటిని రిఫ్రెష్ చేయండి.

RBAC చెక్‌లిస్ట్

• అనుమతుల పట్టిక సాదా భాషలో రాయబడింది, ఎడ్జ్ కేసులు నిర్ణయించబడ్డాయి
• సర్వర్ వినియోగదారును సెషన్ నుండి తెలుసుకుంటుంది, ఎప్పుడూ రిక్వెస్ట్ డేటా నుండి కాదు
• రోల్‌లు డేటాబేస్‌లో నిల్వ చేయబడ్డాయి; వినియోగదారులు తమ స్వంతాన్ని మార్చలేరు
• ఒకే కేంద్ర అనుమతి తనిఖీ, డిఫాల్ట్‌గా తిరస్కరణ, ప్రతి మార్గంలో ఉపయోగించబడింది
• ప్రతి క్వెరీ వినియోగదారు సంస్థ లేదా యాజమాన్యానికి పరిమితం చేయబడింది
• బ్రౌజర్ డేటాబేస్‌ను చేరుకోగల చోట row-level security
• వినియోగదారులు చేయలేనివాటిని UI దాస్తుంది (వినియోగానికి మాత్రమే)
• సున్నితమైన చర్యలు లాగ్ చేయబడ్డాయి
• ప్రతి రోల్ పరీక్షించబడింది, నేరుగా API కాల్స్ మరియు మార్చిన IDలతో సహా

యాక్సెస్ కంట్రోల్ పొడవైన జాబితాలో ఒక అంశం; మిగతావాటిని AI-నిర్మిత యాప్‌ల కోసం సెక్యూరిటీ చెక్‌లిస్ట్ కవర్ చేస్తుంది. మీరు మీ స్వంత సిబ్బంది కోసం టూల్ నిర్మిస్తుంటే, అంతర్గత టూల్ ఎలా నిర్మించాలి రోల్‌లు ఎక్కడ సరిపోతాయో చూపిస్తుంది.

Mythex పై RBAC

Mythex మీ యాప్ వినియోగదారుల కోసం అంతర్నిర్మిత లాగిన్ లేదా రోల్స్ వ్యవస్థను అందించదు. మీరు ఆథ్ లైబ్రరీ లేదా ప్రొవైడర్‌ను ఎంచుకుని రోల్‌లను వివరిస్తారు, మరియు ఏజెంట్ వాటిని మీ కోడ్‌లో మరియు మీ ప్రాజెక్ట్ Postgres డేటాబేస్‌లో కలుపుతుంది (మీ యాప్‌కు లాగిన్ జోడించండి). Mythex యొక్క స్వంత వర్క్‌స్పేస్ రోల్‌లు, Owner మరియు Member వంటివి, మీ Mythex ప్రాజెక్ట్‌లను ఎవరు ఎడిట్ చేయగలరో నియంత్రిస్తాయి, మీరు ప్రచురించే యాప్‌ను ఎవరు ఉపయోగించగలరో కాదు. నిర్మించడానికి ముందు అనుమతుల పట్టికపై అంగీకరించడానికి Plan modeని ఉపయోగించండి, తర్వాత పైన ఉన్న సమీక్ష ప్రాంప్ట్‌ను ఉపయోగించండి, మరియు ప్రచురించే ముందు Previewలో ప్రతి రోల్‌ను పరీక్షించండి. డాక్స్‌లోని భద్రతా ప్రాంప్ట్‌లు ఒక ఉపయోగకరమైన తదుపరి దశ.

ప్రశ్నలు