اپنی ایپ میں Role-Based Access Control (RBAC) کیسے شامل کریں

Role-based access control شامل کرنے کے لیے ہر صارف کو ایک یا زیادہ کردار دیں (مثلاً 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 کے لیے تفصیل کا کام بھی دیتا ہے اور آپ کے جانچ کے منصوبے کا بھی:

خاص صورتیں بھی طے کریں: کیا آخری owner چھوڑ سکتا ہے؟ کیا admin owner کو ہٹا سکتا ہے؟ ہٹائے گئے صارف کو کیا نظر آتا ہے؟

مرحلہ وار طریقہ

1. پہلے کام کرنے والا لاگ ان رکھیں

RBAC auth کے اوپر کھڑا ہوتا ہے۔ سرور کو ہر درخواست کرنے والے کی شناخت قابلِ اعتماد طریقے سے معلوم ہونی چاہیے، session یا تصدیق شدہ token سے، کبھی براؤزر کی بھیجی ہوئی request body میں موجود user 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)
);

کسی صارف کو عام پروفائل اپڈیٹ کے ذریعے اپنا کردار خود بدلنے نہ دیں۔ کردار کی تبدیلیاں ایک مخصوص، اجازت جانچنے والے endpoint سے گزریں۔

3. اجازتیں سرور پر، ایک جگہ جانچیں

ایک ہیلپر لکھیں، جیسے can(user, 'projects.delete', project)، اور اسے ہر API راستے، سرور ایکشن اور بیک گراؤنڈ ٹاسک میں کال کریں جو ڈیٹا پڑھے یا بدلے۔ ایک مرکزی فنکشن کا جائزہ اور جانچ آسان ہے، کوڈ میں بکھری ہوئی جانچوں کے مقابلے میں۔ Deny by default: اگر کوئی قاعدہ کسی کارروائی کی اجازت نہ دے تو وہ مسترد ہو۔

4. ہر کوئری کا دائرہ طے کریں

ٹیم کے ڈیٹا کی ہر کوئری میں ٹیم شامل ہونی چاہیے: where organization_id = :currentOrg، صرف where id = :id نہیں۔ یہی روکتا ہے کہ کوئی /projects/123 کو /projects/124 میں بدل کر کسی اور کمپنی کا پروجیکٹ دیکھ لے۔ دوسری ٹیموں کے ریکارڈز کے لیے "forbidden" کے بجائے "not found" واپس کریں، تاکہ ان کے موجود ہونے کا پتہ نہ چلے۔

5. جہاں ضروری ہو، ڈیٹا بیس کی سطح پر تحفظ شامل کریں

Postgres row-level security (RLS) ڈیٹا بیس کو طے کرنے دیتی ہے کہ ہر صارف کون سی قطاریں دیکھ سکتا ہے۔ یہ لازمی ہے اگر براؤزر ڈیٹا بیس سے براہ راست بات کرتا ہو (جیسا کہ کچھ ہوسٹڈ بیک اینڈز میں)، اور ورنہ حساس ٹیبلز کے لیے ایک مفید دوسری تہہ ہے۔

6. انٹرفیس میں کردار دکھائیں

اب وہ چیزیں چھپائیں یا غیر فعال کریں جو صارف نہیں کر سکتا، تاکہ ایپ الجھن پیدا نہ کرے۔ یہ صرف استعمال میں آسانی کے لیے ہے؛ حفاظت سرور کی جانچیں کرتی ہیں۔

7. حساس کارروائیوں کا ریکارڈ رکھیں

ریکارڈ کریں کہ کردار کس نے بدلے، ڈیٹا کس نے حذف کیا یا ریکارڈز کس نے ایکسپورٹ کیے، اور کب۔ آڈٹ لاگ سپورٹ کے سوالات اور واقعات میں مدد دیتا ہے۔

8. حملہ آور کی طرح جانچیں

ہر کردار سے لاگ ان کریں اور اجازتوں کے ٹیبل کی ہر کارروائی آزمائیں۔ پھر وہ چیزیں آزمائیں جو نہیں ہونی چاہئیں: viewer کے طور پر admin API راستوں کو کال کریں، URLs اور درخواستوں میں IDs بدلیں، آخری owner کے طور پر خود کو ہٹائیں۔ قواعد طے ہونے کے بعد اجازتوں کے ٹیبل کے لیے خودکار ٹیسٹ لکھنا فائدہ مند ہے۔

کام کرنے والے پرامپٹس

Role-based access control شامل کریں۔ ہر تنظیم کے کردار: owner، admin، member، viewer، جو memberships ٹیبل میں محفوظ ہوں۔ اجازتیں اس ٹیبل میں ہیں: [اپنا ٹیبل یہاں چسپاں کریں]۔ ایک سرور سائیڈ can(user, action, resource) ہیلپر بنائیں، deny by default، اور اسے ہر API راستے میں استعمال کریں۔ ہر کوئری کو organization_id کے ذریعے محدود کریں۔ UI میں وہ کارروائیاں چھپائیں جو صارف نہیں کر سکتا، لیکن حفاظت کے لیے کبھی اس پر بھروسا نہ کریں۔

اس ایپ کے ہر API راستے اور سرور فنکشن کا جائزہ لیں۔ ہر ایک کے لیے بتائیں کہ وہ کون سا ڈیٹا پڑھتا یا بدلتا ہے، کیا وہ چیک کرتا ہے کہ صارف لاگ ان ہے، کیا وہ اس کا کردار جانچتا ہے، اور کیا وہ کوئری کو اس کی تنظیم تک محدود کرتا ہے۔ جہاں جانچ غائب ہو وہاں اسے درست کریں، اور مجھے فہرست دکھائیں۔

ایک صرف-admin والا /admin صفحہ شامل کریں جہاں owner ارکان کے کردار بدل سکے۔ آخری owner کو ہٹانے یا اس کا درجہ گھٹانے سے روکیں، ہر کردار کی تبدیلی کا ریکارڈ رکھیں کہ کس نے اور کب کیا، اور یقینی بنائیں کہ کردار بدلنے والا endpoint owner کے علاوہ کسی کو قبول نہ کرے۔

عام غلطیاں

• صرف فرنٹ اینڈ پر کردار جانچنا۔ API پھر بھی ہر اس شخص کے لیے کھلی ہے جو اسے کال کرے۔
• کلائنٹ کے بھیجے ہوئے IDs پر بھروسا کرنا — request body میں userId یا role سیشن کے بجائے۔
• بغیر دائرے کی کوئریاں جو صرف ریکارڈ ID سے لاتی ہیں۔
• صفحات پر کردار جانچنا مگر API راستوں، ایکسپورٹس، فائل ڈاؤن لوڈز یا webhooks پر نہیں۔
• کوڈ میں لکھا ہوا email پتہ بطور admin (if email === 'me@...')، جو بھولنا آسان اور بدلنا مشکل ہے۔
• بہت جلد بہت سارے کردار، جنہیں چھ ماہ بعد کوئی سمجھا نہ سکے۔
• پرانے sessions: ایک درجہ گھٹایا گیا صارف لاگ آؤٹ ہونے تک admin حقوق رکھتا ہے۔ حساس کارروائیوں پر کردار ڈیٹا بیس سے جانچیں، یا انہیں تازہ کریں۔

RBAC چیک لسٹ

• سادہ زبان میں اجازتوں کا ٹیبل لکھا گیا، خاص صورتیں طے ہوئیں
• سرور صارف کو session سے جانتا ہے، کبھی request data سے نہیں
• کردار ڈیٹا بیس میں محفوظ ہیں؛ صارف خود انہیں نہیں بدل سکتے
• ایک مرکزی اجازت جانچ، deny by default، ہر راستے میں استعمال
• ہر کوئری صارف کی تنظیم یا ملکیت تک محدود
• جہاں براؤزر ڈیٹا بیس تک پہنچتا ہے وہاں row-level security
• UI وہ چیزیں چھپاتا ہے جو صارف نہیں کر سکتا (صرف استعمال میں آسانی کے لیے)
• حساس کارروائیوں کا ریکارڈ رکھا جاتا ہے
• ہر کردار کی جانچ ہوئی، بشمول براہ راست API کالز اور بدلے ہوئے IDs

رسائی کنٹرول محفوظ ایپ کی لمبی فہرست کا ایک حصہ ہے؛ AI سے بنی ایپس کے لیے سیکیورٹی چیک لسٹ باقی حصے بیان کرتی ہے۔ اگر آپ اپنے اسٹاف کے لیے ٹول بنا رہے ہیں تو اندرونی ٹول کیسے بنائیں دکھاتی ہے کہ کردار کہاں فٹ ہوتے ہیں۔

Mythex پر RBAC

Mythex آپ کی ایپ کے صارفین کے لیے کوئی بلٹ اِن لاگ ان یا کردار کا نظام فراہم نہیں کرتا۔ آپ ایک auth لائبریری یا فراہم کنندہ چنتے ہیں اور کردار بیان کرتے ہیں، اور ایجنٹ انہیں آپ کے کوڈ اور پروجیکٹ کے Postgres ڈیٹا بیس میں جوڑ دیتا ہے (ایپ میں لاگ ان شامل کریں)۔ Mythex کے اپنے ورک اسپیس کے کردار، جیسے Owner اور Member، یہ کنٹرول کرتے ہیں کہ کون آپ کے Mythex پروجیکٹس میں ترمیم کر سکتا ہے، نہ کہ کون آپ کی پبلش شدہ ایپ استعمال کر سکتا ہے۔ بنانے سے پہلے Plan mode میں اجازتوں کے ٹیبل پر متفق ہوں، پھر اوپر دیا گیا جائزہ پرامپٹ استعمال کریں اور پبلش کرنے سے پہلے Preview میں ہر کردار کی جانچ کریں۔ docs کے سیکیورٹی پرامپٹس ایک مفید اگلا قدم ہیں۔

سوالات