Vibe Coding Uygulamaları 16 Bin Veritabanını Açıkta Bıraktı

16.326 veritabanı. Hepsi herkese açık, hepsinde okunabilir tablolar var. Siber güvenlik şirketi UpGuard'ın 25 Eylül 2026'da yayımladığı araştırmaya göre Supabase üzerinde çalışan bu veritabanlarının yarısından fazlasında kişisel veri izi bulundu. Sızıntıların ortak noktası, çoğunun yapay zeka kodlama araçlarıyla hızla kurulan vibe coding uygulamaları olması. Bu yazıda raporun bulguları, sorunun teknik kökeni ve projeleri korumak için atılabilecek adımlar ele alınıyor.

Supabase Veri Sızıntısında Ne Ortaya Çıktı?

Araştırma, UpGuard'ın Araştırma ve İçgörü Direktörü Greg Pollock imzasıyla UpGuard'ın "Everything Everywhere" başlıklı raporunda yayımlandı. Ekip önce BuiltWith'in teknoloji tespit verilerini ve Google'ın Chrome UX Report veri setini kullandı. Web sitelerinin herkese açık JavaScript dosyalarında Supabase anahtarları ve veritabanı adresleri arandı.

Sonraki adımda yaklaşık 300 bin alan adında "users" adlı bir tabloya erişim denendi. Veritabanlarından üç tür yanıt alındı: erişim reddi, "users tablosu yok ama şu tablo açık" şeklinde bir ipucu ya da doğrudan veri. Sonuçta 16.326 veritabanının okunabilir tablolar sunduğu tespit edildi.

Raporun dikkat çeken bir bulgusu, işletme modelinin sonucu değiştirmemesi. Sitenin B2C ya da B2B hizmet sunması, açığa çıkan verinin türünde bir fark yaratmadı. Coğrafi dağılımda ise Avrupa'nın veri koruma yasaları sayesinde daha iyi uygulamalar görülürken gelişmekte olan bölgelerde sızıntıların daha yaygın olduğu belirtildi.

Hangi Veriler Açıkta Kaldı?

Açık tablolarda ad, e-posta, doğum tarihi ve adres gibi kişisel bilgilerin yanında pasaport, ehliyet ve Hindistan'ın kimlik belgeleri olan PAN ve Aadhaar kayıtları görüldü. Şifreler, API token'ları ve tek kullanımlık doğrulama (OTP) kodları da sızan veriler arasında yer aldı. Ödeme tarafında Stripe bilgileri ve kartların son dört hanesi bulundu.

Sektörel dağılımda e-ticaret ve restoranlar kişisel veri ile ödeme sistemleri nedeniyle öne çıktı. Lisanssız bahis siteleri şifre ve kimlik bilgileri açısından, endüstriyel ürün satıcıları ise kurumsal müşteri verileri açısından riskli gruplar olarak sıralandı. UpGuard'ın örnek olarak paylaştığı vakalar sorunun boyutunu somutlaştırıyor:

Vale hizmetinde sızan e-postaların %11'inin, yani 4.560 adresin bölgesel işverenlere ve Fortune 500 şirketlerine ait olduğu raporda belirtildi. Konsolosluk vakasında ise verilerin acil barınma konumlarını da ortaya çıkardığı görüldü.

Row Level Security Nedir Ve Neden Devre Dışı Kaldı?

Supabase, açık kaynaklı PostgreSQL veritabanını hazır kimlik doğrulama ve API katmanıyla sunan bir platform. Uygulamanın ön yüzü veritabanına doğrudan "anon" adlı herkese açık bir anahtarla bağlanıyor. Bu anahtarın tarayıcıda görünmesi tasarım gereği normal kabul ediliyor. Verinin güvenliği ise Row Level Security (RLS), yani satır düzeyinde güvenlik politikalarıyla sağlanıyor. RLS açık değilse, anon anahtarı eline geçiren herkes tabloyu okuyabiliyor.

Sorunun geçmişi yeni değil. Mart 2025'te geliştirici Matt Turner, Lovable platformuyla oluşturulan veritabanlarında yaygın bir yanlış yapılandırma bildirdi ve açık CVE-2025-48757 koduyla kayda geçti. Cybernews'te yayınlanan habere göre Lovable'da ayrıca kaynak kodu, veritabanı kimlik bilgileri ve yapay zeka sohbet geçmişlerini açığa çıkaran ayrı bir hata da tespit edildi.

Supabase bunun ardından kendi arayüzündeki Table Editor ile oluşturulan tablolarda RLS'yi varsayılan olarak açtı. UpGuard'a göre asıl boşluk burada kalıyor: API üzerinden programatik olarak oluşturulan tablolarda RLS varsayılan olarak açılmıyor. Kodlama ajanları da Supabase ile tam olarak bu yoldan çalışıyor. Raporda RLS'nin açık olmasının da tek başına yetmediği, politikaların doğru kurulması ve doğru kimlik bilgileriyle kullanılması gerektiği de ekleniyor.

Kodlama Ajanları Bu Açığı Nasıl Büyütüyor?

UpGuard raporunda Supabase, "Claude Code'un en çok önerdiği veritabanı ürünü" olarak tanımlanıyor. Önceki araştırmalar Lovable ve Replit gibi platformlardan gelen daha küçük örneklemlere odaklanmıştı. Yeni çalışma ise tek bir aracın değil, genel bir örüntünün izini sürüyor.

"Ortak nokta, bu sitelerin yapay zeka kodlama ajanları tarafından oluşturulması ve insanların yapılandırmadan haberdar olmaması." (UpGuard raporu)

Bunu doğru okumak gerekiyor: sorun, ajanların kötü niyetli olması ya da kodun çalışmaması değil. Uygulama çalışıyor, kullanıcı kaydı alınıyor, ödeme alınıyor. Eksik kalan, kimsenin bakmadığı güvenlik yapılandırması. Raporda da bu insanların ne tür bir iş yaptığını bildiği ama veritabanının nasıl yapılandırıldığını anlamadığı belirtiliyor.

Vibe coding yaklaşımı, yazılım geliştirme deneyimi olmayan kişilerin de birkaç komutla ürün çıkarmasını sağlıyor. Aynı hız, "çalışıyorsa bitmiştir" algısını da güçlendiriyor. Masqot'ta daha önce ele alınan Agentjacking saldırısı kodlama ajanlarının dışarıdan nasıl kandırılabileceğini göstermişti. Supabase vakası ise ajanın hiçbir saldırı olmadan, sadece eksik bir ayar yüzünden açık bırakabildiği kapıları gösteriyor.

Supabase, S3 Ve GitHub Kıyası: Hikaye Tekrar mı Ediyor?

UpGuard, Supabase'i daha önce benzer bir yoldan geçen iki platformla karşılaştırıyor. Raporda veri sızıntılarının, bir teknolojinin yanlış yapılandırılma kolaylığı ile kullanıcı tabanı büyüklüğünün çarpımından doğduğu ifade ediliyor. Amazon S3'teki güvensiz varsayılan ayarların bugün hala süren binlerce sızıntıya yol açtığı, GitHub'ın "varsayılan olarak herkese açık" modelinin de sayısız kimlik bilgisi ifşasına neden olduğu hatırlatılıyor.

Supabase cephesinde yanıt ortak sorumluluk üzerine kuruldu. TechCrunch'ta yayınlanan habere göre şirketin bilgi güvenliği direktörü (CISO) Bil Harmer şu açıklamayı yaptı:

"Supabase'te güvenlik hiçbir zaman bitmiş bir iş değil. Bunu doğru yapmayı çok önemsiyoruz."

Harmer, güvenliğin şirket ile müşteriler arasında paylaşılan bir sorumluluk olduğunu da ekledi. Haziran 2026'da 10 milyar dolar değerlemeye ulaşan platformun kullanıcı tabanı büyüdükçe, UpGuard'ın formülüne göre risk de aynı oranda büyüyor. Raporun kapanışında, S3 ve GitHub'ın zamanla yaptığı gibi varsayılan ayarlarda köklü bir değişiklik olmadan bu sorunların sürmesinin muhtemel olduğu belirtiliyor.

Vibe Coding Projesi Nasıl Güvenli Hale Getirilir?

Yapay zeka ile geliştirilen bir uygulama Supabase kullanıyorsa ilk kontrol, her tabloda RLS'nin açık olup olmadığı. Supabase'in Advisors dokümantasyonuna göre paneldeki Security Advisor bölümü, RLS'si kapalı tabloları uyarı olarak listeliyor. Kapalı tablolar tek satırlık bir SQL komutuyla korunabiliyor:

alter table public.users enable row level security;

RLS'yi açmak ilk adım. Açıldıktan sonra politika yazılmazsa tablo tamamen kilitlenir, gelişigüzel yazılan bir politika ise yine herkese okuma izni verebilir. Dikkat edilmesi gereken başlıca noktalar şunlar:

Anon ve service_role anahtarı: Anon anahtarının ön yüzde görünmesi normal kabul ediliyor. Tüm yetkilere sahip service_role anahtarı ise asla tarayıcıya, mobil uygulamaya veya herkese açık bir depoya konmamalı.

Ajan çıktısının denetimi: Kodlama ajanından tablo oluşturması istendiğinde, RLS politikalarını da yazması ve her tablo için hangi kullanıcının neyi okuyabileceğini açıklaması istenmeli.

Hassas verinin saklanması: Şifreler düz metin olarak değil, hash'lenerek tutulmalı. Kimlik belgesi gibi dosyalar herkese açık depolama alanlarına konmamalı.

Test: Uygulama yayına alınmadan önce, oturum açmamış bir kullanıcının anon anahtarıyla hangi tablolara erişebildiği denenmeli.

Türkiye'den çıkan girişimler için konu yalnızca teknik bir ayar meselesi değil. Kişisel veri işleyen bir uygulamanın açıkta kalması, 6698 sayılı Kişisel Verilerin Korunması Kanunu kapsamında veri sorumlusunun yükümlülüklerini doğrudan ilgilendiriyor. Kişisel Verileri Koruma Kurulu'nun 2019/10 sayılı kararına göre ihlallerin Kurul'a en geç 72 saat içinde bildirilmesi gerekiyor. KVKK ve yapay zeka başlıklı yazıda şirketlerin bu süreçte nelere dikkat etmesi gerektiği ayrıntılı olarak ele alınmıştı. Yapay zeka kod yazma siteleri ile hızla ürün çıkaran ekiplerin yayın öncesi kontrol listesine veritabanı erişim testini eklemesi, olası bir ihlalin maliyetinin yanında küçük bir iş yükü olarak kalıyor.

Sıkça Sorulan Sorular

Supabase'in kendisi hacklendi mi?

Hayır, Supabase altyapısında bir saldırı tespit edilmedi. Sızıntılar, platformu kullanan uygulamaların veritabanlarını yanlış yapılandırmasından kaynaklanıyor. Veritabanlarına, uygulamaların kendi JavaScript dosyalarında herkese açık duran anahtarlarla erişilebildi.

Row Level Security (RLS) nedir?

RLS, PostgreSQL'de her satır için kimin okuma ve yazma yetkisi olduğunu belirleyen güvenlik mekanizmasıdır. Supabase'te ön yüz veritabanına doğrudan bağlandığı için verinin korunması büyük ölçüde RLS politikalarına dayanıyor. RLS kapalıysa, herkese açık anahtarı bulan herkes tabloyu okuyabiliyor.

Vibe coding ile yapılan her uygulama risk altında mı?

Hayır, risk kullanılan araca değil yapılandırmaya bağlı. UpGuard'ın bulgusuna göre API üzerinden oluşturulan tablolarda RLS varsayılan olarak açılmadığı için kodlama ajanlarıyla kurulan projelerde bu adımın atlanma ihtimali daha yüksek. RLS açık ve politikaları doğru yazılmış bir proje bu açıktan etkilenmiyor.

Uygulamamın etkilenip etkilenmediğini nasıl anlarım?

En hızlı yöntem Supabase panelindeki Security Advisor uyarılarını kontrol etmek. Ardından oturum açmadan, yalnızca anon anahtarıyla tablolara sorgu atılarak hangi verilerin döndüğü test edilebilir. Veri dönüyorsa ilgili tablolar için RLS açılıp politika yazılmalı.

Açık veritabanı fark edildiğinde ne yapılmalı?

Önce ilgili tablolarda RLS açılarak erişim kapatılmalı, sızmış olabilecek API anahtarları ve şifreler yenilenmeli. Kişisel veri içeren bir sızıntı söz konusuysa Türkiye'de KVKK kapsamında Kurul'a 72 saat içinde bildirim yapılması gerekiyor. Etkilenen kullanıcıların da bilgilendirilmesi yükümlülükler arasında.

Kodlama ajanları bir uygulamayı birkaç saatte ayağa kaldırabiliyor ama o uygulamanın kapılarını kilitleyip kilitlemediğini henüz kendiliğinden sormuyor. S3 ve GitHub'da varsayılan ayarların değişmesi yıllar almıştı. Supabase'in ve kodlama ajanı geliştiren şirketlerin bu raporun ardından varsayılanları ne kadar hızlı değiştireceği, önümüzdeki aylarda açığa çıkacak yeni vakaların sayısını da belirleyecek.