پژوهش‌های اخیر در زمینه امنیت سایبری نشان می‌دهد که بیش از ۱۶ هزار نمونه از سرویس Supabase به دلیل پیکربندی نادرست در لایه دسترسی (Row Level Security – RLS)، داده‌های حساس کاربران شامل اطلاعات هویتی (PII)، گذرواژه‌ها و توکن‌های احراز هویت را در معرض دسترسی عمومی قرار داده‌اند. این رخداد زنگ خطری جدی برای توسعه‌دهندگانی است که از پلتفرم‌های BaaS (Backend-as-a-Service) بدون درک عمیق از معماری امنیتی آن استفاده می‌کنند.
ماهیت فنی آسیب‌پذیری در Supabase
مشکل اصلی در این نشت داده‌ها، ماهیت سرویس Row Level Security (RLS) در پایگاه‌داده PostgreSQL نهفته است. در پلتفرم Supabase، هنگامی که یک جدول ایجاد می‌شود، توسعه‌دهنده باید قوانین دسترسی را به صورت صریح تعریف کند. اگر قابلیت RLS فعال نشود یا قوانین دسترسی به صورت «دسترسی عمومی» (Public Access) تنظیم شده باشد، هر کاربری که به API عمومی پروژه دسترسی داشته باشد، می‌تواند بدون نیاز به احراز هویت، کوئری‌های SELECT را روی جداول حساس اجرا کند. این اتفاق فراتر از یک حفره امنیتی در زیرساخت است و مستقیماً به ناتوانی در پیاده‌سازی منطق کنترل دسترسی (Access Control Logic) مربوط می‌شود.
چرا RLS برای امنیت داده‌ها حیاتی است؟
پلتفرم Supabase از معماری PostgreSQL استفاده می‌کند. بر خلاف پایگاه‌داده‌های سنتی که امنیت در سطح شبکه (Firewall) تأمین می‌شد، در مدل‌های مدرن ابری، امنیت باید در سطح ردیف (Row) اعمال شود. بسیاری از توسعه‌دهندگان به اشتباه تصور می‌کنند که حذف رابط کاربری داشبورد یا مخفی کردن URL API کافی است، اما در واقع، تا زمانی که سیاست‌های RLS برای جداول حساس تعیین نشود، پایگاه‌داده همچنان از طریق نقاط پایانی (Endpoints) API در دسترس باقی می‌ماند. مهاجمان در این سناریو با استفاده از ابزارهای خودکار، جداول دارای اطلاعات حساس مانند ایمیل‌ها و توکن‌های JWT را هدف قرار داده و از طریق این اینترفیس در معرض دید، داده‌ها را استخراج کرده‌اند.
مشخصات و ابعاد فنی آسیب‌پذیری
- نوع آسیب‌پذیری: پیکربندی نادرست کنترل دسترسی (Insecure Access Control)
- فناوری پایه: PostgreSQL (سرویس مدیریت شده توسط Supabase)
- داده‌های در معرض: PII، رمزهای عبور هش شده، توکن‌های API و داده‌های خصوصی
- تعداد شناسایی شده: بیش از ۱۶,۰۰۰ نمونه عمومی در اسکن‌های اینترنتی
- راهکار فوری: فعال‌سازی Policyهای سخت‌گیرانه RLS برای تمامی جداول
اقدامات لازم برای ایمن‌سازی پروژه‌ها
برای جلوگیری از تکرار چنین بحران‌هایی، توسعه‌دهندگان باید استراتژی «امنیت توسط طراحی» (Security by Design) را در پیش بگیرند. اولین قدم، بررسی وضعیت RLS در تمام جداول پروژه از طریق داشبورد Supabase است. برای جداولی که حاوی داده‌های حساس هستند، باید سیاست‌های خاصی تعریف کرد که تنها به کاربران احراز هویت شده (Authenticated Users) اجازه خواندن یا نوشتن بدهد. همچنین، بررسی منظم لاگ‌های دسترسی API و محدود کردن دامنه دسترسی‌ها به جداول مورد نیاز، از جمله اقدامات ضروری برای کاهش سطح حمله (Attack Surface) است.
نتیجه‌گیری
این حادثه نشان می‌دهد که سهولت در استفاده از ابزارهای ابری و پلتفرم‌های PaaS/BaaS هرگز نباید منجر به نادیده گرفتن تنظیمات امنیتی پایه شود. اگرچه Supabase ابزارهای قدرتمندی برای مدیریت امنیت ارائه می‌دهد، اما مسئولیت نهایی پیکربندی این سیاست‌ها بر عهده توسعه‌دهنده است. با توجه به گزارش‌های منتشر شده در پاییز ۱۴۰۳، ارتقای دانش فنی در مدیریت امنیت پایگاه‌داده در محیط‌های ابری به یکی از مهارت‌های کلیدی برای تیم‌های توسعه تبدیل شده است.
