Yapay Zekanın USING (true) Felaketini Engelleme: Supabase RLS Güvenlik Rehberi

Yapay Zekanın En Tehlikeli SQL Halüsinasyonu: "USING (true)"

Supabase veya PostgreSQL kullanan geliştiricilerin başına gelen en büyük güvenlik facialarından biri, yapay zekadan RLS (Row Level Security) kuralı istemektir.

Cursor veya Copilot'a *"Supabase tablomda 403 hatası alıyorum, okuma iznini düzelt"* dediğinizde, model işin kolayına kaçarak saniyeler içinde şunu yazar:

-- ❌ YAPAY ZEKANIN ÜRETTİĞİ FELAKET GÜVENLİK AÇIĞI:
CREATE POLICY "Enable read access for all users"
ON user_billing_profiles FOR SELECT
USING (true); -- ❌ TÜM MÜŞTERİLERİN FATURA VE KREDİ KARTI BİLGİLERİ KAMUYA AÇILDI!

`USING (true)` ifadesi, **anonim ve yetkisiz herhangi bir kullanıcının tüm tabloyu çekebilmesi anlamına gelir**. Bu durum şirketin verilerini dakikalar içinde Hacker News manşetlerine taşır.

---

Sıfır-Güven Supabase & Postgres RLS Kuralı

Kurallarımız veritabanı bağlamında yapay zekanın `USING (true)` üretmesini kesin olarak engeller ve şu katı standartları dikte eder:

-- ✔ FCKAISLOP İLE ZORLANAN ZIRHLI RLS STANDARDI:

-- 1. RLS kesinlikle aktif edilmeli ALTER TABLE user_billing_profiles ENABLE ROW LEVEL SECURITY;

-- 2. Yalnızca oturum açmış kullanıcının kendi satırına erişimi CREATE POLICY "Kullanıcılar sadece kendi fatura profillerine erişebilir" ON user_billing_profiles FOR ALL TO authenticated USING (auth.uid() = user_id) WITH CHECK (auth.uid() = user_id);

-- 3. İlişkili yabancı anahtar (FK) için kilitlenmeyi önleyen btree indeks CREATE INDEX IF NOT EXISTS idx_billing_profiles_user_id ON user_billing_profiles(user_id); ```

Supabase Geliştiricileri İçin Önemli Notlar: - **Tenant Ayrımı:** Çok kiracılı (multi-tenant) sistemlerde sadece `user_id` değil, `org_id` kontrolü de zorunlu tutulmalıdır. - **İndeks Şartı:** RLS ilkelerinde kullanılan her sütun mutlaka indekslenmelidir, aksi halde tablodaki satır sayısı arttıkça her sorguda Full Table Scan yapılarak veritabanı kilitlenir.