امنیت سطح سطر در داده‌های سازمانی با Supabase RLS
انتقال مجوزها به پایگاه داده به جای کد کلاینت: اصول کلیدی که باید هنگام طراحی سیاست‌های Row Level Security در نظر بگیرید.
یکی از رایج‌ترین اشتباهات در برنامه‌های سازمانی، انجام کنترل دسترسی تنها در رابط کاربری است. فرض بر این است که وقتی یک دکمه پنهان می‌شود، داده‌ها نیز محافظت می‌شوند؛ با این حال، برای کسی که مستقیماً به API درخواست می‌فرستد، این دکمه اصلاً وجود نداشته است.
مجوز باید در پایگاه داده زندگی کند
ویژگی Row Level Security در PostgreSQL به شما امکان می‌دهد شرایط سیاستی را تعریف کنید که به طور خودکار به هر پرس‌وجو اضافه می‌شود. Supabase این سیاست‌ها را با اطلاعات احراز هویت ترکیب می‌کند: با auth.uid() کاربر فعال در نشست را می‌شناسد و فقط سطرهای مجاز را بازمی‌گرداند.
به داده‌هایی که کاربر می‌تواند تغییر دهد اعتماد نکنید
نگهداری اطلاعات نقش در متادیتای کاربر وسوسه‌انگیز است، اما این فیلد اغلب توسط کلاینت قابل به‌روزرسانی است. رویکرد امن‌تر این است که نقش‌ها را در جداول جداگانه نگهداری کنید و با توابع security definer آن‌ها را بررسی نمایید.
فهرست بررسی
- RLS را در هر جدول فعال کنید و به طور پیش‌فرض به هیچ چیزی اجازه ندهید.
- س سیاست‌های خواندن ناشناس را فقط به محتوای منتشر شده محدود کنید.
- عملیات نوشتن را به جداول مجوز متصل کنید.
- سیاست‌ها را با تست‌های خودکار تأیید کنید.
این رویکرد همچنین اساس پنل‌های مدیریتی است که در Cy Logic توسعه می‌دهیم.