Eksik Row Level Security, art arda gelen üretim veritabanı ihlallerine bağlandı

Yinelenen bir hata kalıbı

dev.to'da yayımlanan bir yazı, bu yıl üretim veritabanlarının ihlal edilmesinin en yaygın yollarından birinin aynı zamanda en sıradan olanlardan biri olduğunu savunuyor: Row Level Security'nin hiç açılmadığı bir tablo.

Yazıya göre en net örnek, Mayıs 2025'te açıklanan CVE-2025-48757. Yapay zekâ destekli uygulama geliştirme platformu Lovable ile oluşturulmuş 170 uygulamadaki 303 uç noktayı etkileyen bu açık, Supabase tablolarının herkes tarafından okunabilmesine yol açtı. Yazı, RLS'nin yanlış yapılandırılmadığını vurguluyor — hiç açılmamıştı.

Yazar ayrıca, Mart 2026'daki bir olaya da değiniyor: Bir yapay zekâ platformunun veritabanı, saldırganın aynı açığı barındıran bir örnek bulmasının ardından dışarı sızdırıldı ve yönetici e-posta adresleri ile iç şema metaverisi açığa çıktı. Tekil olayların ötesinde, yazı birçok Supabase örneğinin yalnızca bir curl isteği ve herkese açık "anon" anahtarıyla sorgulanabildiğini, tüm tabloların dökülebildiğini gösteren güvenlik araştırmacılarına atıf yapıyor; küresel ölçekte yanlış yapılandırılmış örnek sayısına ilişkin tahminler yüzlerden binlere kadar uzanıyor.

Yazıda birden fazla 2025–2026 kaynağına dayandırılan çerçeve şöyle: Supabase'de veri koruması kabaca yüzde 90 erişim kontrolü, yüzde 10 şifrelemeden oluşuyor. Zayıf halka nadiren şifrelemedir; zayıf halka erişim kontrolü katmanıdır.

Yeni bir platformda eski bir hata

Bu hata kalıbı Supabase'e ya da bu yıla özgü değil. Yazı, Firebase ile doğrudan bir paralellik kuruyor: Doğrulanmış ve belgelenmiş bir sızıntı, sağlık, finans ve eğitimi kapsayan 900'den fazla mobil uygulamada 1,8 milyondan fazla kullanıcıya ait düz metin parolaları ve diğer hassas verileri açığa çıkardı. Neden, herkese açık bırakılmış Realtime Database örnekleriydi. Teknoloji farklı, ama kök neden aynı: elle yapılandırılması gereken ve yapılandırılmayan bir erişim kontrolü katmanı.

Migration'lar neden işleri zorlaştırıyor

Yazarın araştırması bir yan proje olarak başladı: Firestore Security Rules'ı Postgres RLS politikalarına doğru şekilde nasıl çevireceğini çözmeye çalışıyordu. Firestore kuralları, Postgres'in ayrı tuttuğu iki konuyu bir arada barındırır — veriye kim erişebilir sorusu ile verinin doğru biçimde olup olmadığı sorusu; ikincisini Postgres CHECK kısıtlamaları ve sütun tipleriyle halleder. Bu, çeviriyi bul-değiştir işinden ziyade anlamsal bir probleme dönüştürüyor ve migration teslim tarihi baskısı altında politikaları elle yeniden oluşturmak, tam da izin veren hataların sızdığı andır.

Yazıya göre bu konudaki araç desteği zayıf. Bu yıl yayımlanan migration rehberleri güvenlik kurallarının yeniden oluşturulmasını hâlâ elle yapılacak bir kontrol listesi adımı olarak ele alıyor. rebasepro/rebase projesi çevirme sürecini kullanıcıların politikaları bir kez kendi DSL'inde tanımlamasıyla atlatırken, supashim kural çevirisini henüz kamuya açık kodu olmadan geliştirme aşamasında olarak listeliyor.

Yazının belirttiğine göre Supabase 2026'da taban çizgiyi yükseltti: RLS artık yeni tablolarda varsayılan olarak etkin ve dashboard, RLS bulunmayan tabloları işaretliyor. Bu, "açmayı unuttum" durumunu çözüyor ama daha zorlu migration durumunu çözmüyor — özellikle bir migration'ın tabloları normal akışın dışında oluşturduğu senaryolarda.

Pratik öneriler

Firestore'dan ya da erişim kurallarının veri katmanının içinde yaşadığı herhangi bir sistemden geçiş yapan ekipler için yazı şu önerilerde bulunuyor:

• Güvenle çeviremediğiniz her kural için varsayılan olarak reddetmeyi seçin; izin verici bir politikayı tahmin etmeyin.

• Üretilen her politikayı insan incelemesi gerektiren bir taslak olarak görün; asla otomatik uygulanacak bir şey olarak değil.

• Sonunda ne elde ettiyseniz, pgrls gibi bir statik RLS linter'ı ile çalıştırın; kiracı kapsamı hatalarını ve ters çevrilmiş kimlik doğrulama kontrollerini yakalayan onlarca kural içeriyor.

• Veri doğruluğunu ve erişim kontrolü doğruluğunu iki ayrı risk olarak görün ve güvenliği, veri yerleştikten sonra bitirilecek bir şey olarak görmek yerine her ikisi için de plan yapın.

Neden önemli

Anlatılan ihlallerin hiçbirinde egzotik saldırılar yoktu: zero-day yok, akıllıca istismar yok; yalnızca bir politika taşıması gereken ama taşımadığı bir tabloya yapılan kimliği doğrulanmamış bir istek vardı. Sorun tam da bu sıradanlıkta — sıkıcı hatalar, bir CVE'de ortaya çıkana kadar araç geliştirmeyi gerektirecek kadar acil hissettirmiyor. Postgres tabanlı backend'leri benimseyen ekipler için RLS kapsamı, lansman kontrol listesinde şifrelemenin yanında bir yer hak ediyor ve migration projeleri politika çevirisini başlı başına bir mühendislik işi olarak ele almalı.