نظرات Postgres: امنیت پنهان GOTCHA در Supabase

هنگام ساختن با Supabase ، نمای Postgres می تواند ابزاری قدرتمند برای ساده سازی نمایش داده های پیچیده باشد. اما آنها با یک ملاحظات مهم امنیتی همراه هستند که بلافاصله آشکار نیست: بازدید از سطح ردیف بای پس از امنیت (RLS) به طور پیش فرض، به طور بالقوه داده های حساس را حتی در صورت ایمن کردن جداول شما در معرض دید قرار می دهد.

به عنوان یک یادآوری: RLS همان چیزی است که به شما امکان می دهد با خیال راحت از پایگاه داده supabase خود مستقیماً از جلوی ، بدون مسیریابی از طریق سرور پس زمینه خود ، پرس و جو کنید. اما اگر RLS روی یک میز کار نمی کند ، آن جدول مانند صفحه تلفن شما در حمل و نقل عمومی است – هر کسی که می خواهد نگاهی بیندازد ، می تواند.

چالش امنیتی

حتی اگر خط مشی های RLS را روی میزهای خود با دقت تنظیم کرده باشید ، نماها می توانند یک پشتی ناخواسته ایجاد کنند زیرا:

• به طور پیش فرض ، نماها از RLS استفاده نمی کنند
• صفحه خط مشی های RLS Supabase در مورد نماهای در معرض نشان نمی دهد یا هشدار نمی دهد (آخرین بررسی 09.03.2025)
• نمایش ها از RL ها به همان روشی که جداول انجام می دهند پشتیبانی نمی کنند

امنیت نمای خود را آزمایش کنید

قبل از استفاده از هرگونه دیدگاه به تولید ، تأیید این نکته ضروری است که به درستی به سیاست های RLS شما احترام می گذارد. در اینجا یک روش سریع برای آزمایش در صورت امنیت مشاهده شما وجود دارد:

// First, sign in as a specific user
// Then try to fetch ALL rows from your view
const { data } = await supabase.from('my_view').select('*')
// If your view respects RLS, you should only see rows this user has permission to access.
// If you see ALL rows, your view is bypassing RLS! 🚨
console.log("view response" ,data)

ایمن کردن نظرات خود

برای محافظت از داده های خود ، گزینه های مختلفی دارید:

1. برای Postgres 15+:

CREATE VIEW public.my_view
WITH (security_invoker = true) AS
SELECT * FROM my_table;

این اعمال RLS است my_table به منظره ای که ایجاد می کنید.

1. برای نسخه های قدیمی Postgres:

• یک طرح داخلی ایجاد کنید: CREATE SCHEMA internal;
• دیدگاه حساس را در طرح داخلی دوباره ایجاد کنید
• نسخه عمومی نمایش را حذف کنید

چه موقع از نمایش استفاده کنید

دیدگاه ها در صورت نیاز به ویژه ارزشمند هستند:

• نمایش داده های پیچیده ای را که مرتباً استفاده می کنید ساده کنید
• ستون های محاسبه شده را اضافه کنید که نمی توان ستون های تولید کرد
• جداول مجازی ایجاد کنید که با هر درخواست دوباره محاسبه می شود

مثال: وضعیت اشتراک فعال

من به تازگی یک سیستم اشتراک ایجاد کردم و می خواستم از نوشتن خودداری کنم active_until > NOW() در هر پرس و جو که در آن باید اشتراک های فعال را بررسی کنم. با برنامه ریزی پیش رو ، من ابتدا اضافه کردم is_active ستون تولید شده به جدول. اما من به یک دیوار برخورد کردم: Postgres اجازه نمی دهد عملکردهای فرار مانند now() در ستون های تولید شده. این زمانی است که من به عنوان یک راه حل به دیدگاه ها روی آوردم:

CREATE VIEW public.active_subscriptions
WITH (security_invoker = true) AS
SELECT 
    *,
    (active_until > now()) AS is_active
FROM 
    public.subscriptions;

این دیدگاه کاملاً کار کرده است و ضمن حفظ امنیت به من داده های تمیز می دهد security_invokerبشر