Lovable ile geliştirilen uygulamalar, eksik Supabase RLS nedeniyle pasaport verilerini ve 200 bin mesajı sızdırdı

Ne yaşandı

Bir dev.to yazısına göre, yapay zekâ uygulama geliştiricisi Lovable ile kurulmuş uygulamaları konu alan bir Hacker News gönderisi, ortaya çıkardığı pasaport bilgileri ve 200 binden fazla özel mesaj nedeniyle bu hafta yaklaşık 600 puan topladı. Yazı yakından incelendiğinde, olayın arkasında sofistike bir saldırı bulunmuyor. Çoğu durumda bu uygulamaların arkasındaki Postgres tablolarında yalnızca Row Level Security (RLS) devre dışıydı; bunları sorgulamak için gereken kimlik bilgileri ise herkesin indirebileceği bir JavaScript bundle içinde dağıtılıyor.

Lovable, Bolt ve Cursor gibi yapay zekâ kod üretim araçlarını Supabase ile birleştiren freelance ve girişim projelerini inceleyen yazar, Vietnam'da aynı yanlış yapılandırmayla düzenli olarak karşılaştığını bildiriyor.

Anon anahtarı neden bir sır değil

Yazı sorunun kaynağını bir zihniyet farkına bağlıyor. Geleneksel backend teknolojilerinden gelen geliştiriciler .env dosyalarındaki API anahtarlarını sır olarak görür. Supabase farklı çalışır: tarayıcı veritabanıyla doğrudan PostgREST üzerinden konuşur ve anon anahtarı, anon rolünü taşıyan, tasarımı gereği herkese açık bir JWT'dir. VITE_SUPABASE_ANON_KEY gibi adlandırılan herhangi bir değer, her ziyaretçiye sunulan JavaScript'e karışır.

Bu, RLS politikalarını anonim bir istek ile satırlar arasındaki tek bariyer hâline getirir. Ancak ham SQL ile ya da bir yapay zekâ aracının ürettiği migration'larla oluşturulan tablolarda RLS varsayılan olarak etkinleşmez. Supabase dashboard'u bir uyarı gösterir; ama prompt'lara ve migration dosyalarına dayalı bir iş akışı o dashboard'u hiç açmaz.

Beş dakikalık öz test

Yazar, yalnızca curl ve üretim URL'si kullanarak saldırganın konumundan denetim yapmayı öneriyor. Önce sayfayı fetch edin, asset bundle'ı bulun ve JWT'yi (eyJ önekiyle tanınan) proje URL'siyle birlikte çıkarın. Ardından her tablodan tek bir satırı, exact-count başlığıyla REST endpoint'i üzerinden isteyin. Yanıt, kişisel veri içeren bir tabloda sıfırdan fazla okunabilir satır bildiriyorsa, uygulama Hacker News raporundaki uygulamalarla aynı açığa sahiptir; güvenli bir kurulum hiçbir sayı döndürmez.

Tablo listesinin kendisi, REST kökünde sunulan OpenAPI spesifikasyonundan gelir; bir saldırganın şemayı saydıracağı yöntem de tam olarak budur. Yazı ayrıca yazma işlemlerinin de test edilmesini salık veriyor; örneğin başka bir kullanıcının profilindeki role alanını güncellemek, çünkü birçok uygulama okuma politikası ekleyip INSERT ve UPDATE'i tamamen unutuyor.

En sık görülen politika hataları

• Koşulu düz true olan politikalar. Yapay zekâ araçları bunları sıkça izin hatalarını susturmak için üretir; bu, RLS'yi etkinleştirmeyi anlamsız kılar.

• Yalnızca SELECT politikaları. INSERT ve UPDATE üzerinde eşleşen bir denetim olmadan kullanıcılar başkasının user id'sini ya da role'unu yeniden yazabilir.

• İzinler için kullanıcı metadata'sına güvenmek. Kullanıcılar bunu Supabase'in update-user çağrısıyla kendileri düzenleyebilir; bu yüzden yetkilendirme verisi app metadata'da ya da ayrı bir tabloda yer almalıdır.

• Politikaların içinde doğrudan auth.uid() çağırmak. Bunu bir scalar subquery olarak sarmalamak, planlayıcının değeri önbelleğe almasını sağlar; yazar bunun, yüz binlerce satırlı tablolarda onlarca kat daha hızlı olabileceğini söylüyor.

• Frontend'e sızan service_role anahtarı. RLS'yi tamamen atladığı için Edge Functions gibi sunucu tarafı kodda kalmalıdır.

• Herkese açık storage bucket'ları. Genel depolamaya konan pasaport ve kimlik belgesi yüklemeleri tablo politikalarıyla korunmaz.

• Sıradan view'lar. Varsayılan olarak sahip yetkileriyle çalışır ve security_invoker = true ile oluşturulmadıkça RLS'yi atlatır.

CI'da gerilemeleri engellemek

Tek seferlik bir düzeltme zamanla bozulur, çünkü bir sonraki prompt ile üretilen tablo aynı açığı yeniden getirir. Yazar, psycopg üzerine kurulu küçük bir Python denetim betiği paylaşıyor; betik RLS'siz herkese açık tabloları, koşulu kelimenin tam anlamıyla true olan politikaları ve security_invoker eksik view'ları işaretliyor. Hedeflenen CI akışı yerel bir Supabase veritabanı başlatır, migration'ları uygular, betiği buna karşı çalıştırır ve herhangi bir bulguda pull request'i engeller. Ülke ya da fiyat listesi gibi meşru olarak herkese açık tablolar, tesadüfen sızmak yerine açık bir allowlist'ten geçer.

Neden önemli

d.to yazarının çerçevelediği gibi, sızıntı tek bir yapay zekâ aracının başarısızlığı değil; bir veritabanını güvenlik modelini anlamadan internete koymanın sonucuydu. Yapay zekâ desteği fikirden üretime giden yolu kısaltır ve bir güvenlik açığını yayına almak için olan yolu da en az o kadar etkili biçimde kısaltır. Supabase modelinde RLS, herkese açık bir anahtarı kabul edilebilir kılan şeydir ve biri açana kadar kapalı kalır. Yapay zekâ destekli geliştirmeyi benimseyen ekipler bunu, zamanında fark etmeyi umdukları bir dashboard uyarısı değil, CI tarafından dayatılan bir değişmez olarak görmeli.