← Radar

Konu: Veritabanı3 dk okuma

Her dokuz uygulamadan biri Supabase anahtarını tarayıcıya gönderiyor: Hangisi sorun, hangisi değil?

Bu neden önemli?

Supabase ile uygulama kurmak birkaç dakika sürüyor ve yapay zekâyla yazılan uygulamaların çoğu onu kullanıyor. Hangi anahtarın tarayıcıda durabileceğini ve onu neyin koruduğunu bilmezsen, bütün veritabanını farkında olmadan internete açabilirsin.

Rapor ne buldu?

SupaExplorer adlı bir sitenin Ocak 2026 raporu, beş küçük ürün dizininden (Fazier, TinyLaunch, Uneed, PeerPush, TrustMRR) topladığı 20.052 siteyi taradı. Her sitenin ana sayfasına ve yüklediği JavaScript dosyalarına bakıp *.supabase.co adreslerini ve JWT biçimindeki anahtarları aradılar. 2.217 alan adında, yani yaklaşık %11’inde bir şey buldular. Başlıktaki “dokuzda bir” buradan geliyor.

Ama rakamı okurken dikkatli ol. Rapor, bulunan anahtarların kaçının gerçekten gizli anahtar olduğunu ayrıca vermiyor. Sadece “önemli bir kısmının” güvenlik kurallarını atlayabildiğini söylüyor. Tarama aracı da kapalı kaynak, yani sonucu bağımsız olarak tekrarlamak mümkün değil. Üstelik bulunan her anahtar bir sızıntı değil, çünkü bazıları zaten herkese açık olması için yapılmış.

Supabase’de iki tür anahtar var

Supabase’in belgelerine göre:

  • Publishable anahtar (sb_publishable_..., eski adı anon): Tarayıcıda ve mobil uygulamada durması için yapılmış. Gizli değil. İsteği yetkisiz anon ya da giriş yapmış kullanıcı için authenticated rolüyle yapıyor.
  • Secret anahtar (sb_secret_..., eski adı service_role): Sadece sunucuda kullanılmalı. Bağlı olduğu Postgres rolünde BYPASSRLS yetkisi var, yani bütün güvenlik kurallarını atlıyor.

Supabase, tarayıcıdan gelen secret anahtarlı istekleri User-Agent başlığına bakıp reddediyor. Bu seni korumaz: Anahtarı ele geçiren biri onu tarayıcı dışından, basit bir komutla kullanır.

Açık anahtarı ne koruyor?

Supabase’in API’si, PostgREST yazımızda anlattığımız gibi, veritabanı rollerine ve Row Level Security (RLS) kurallarına güveniyor. Publishable anahtarla gelen biri, sadece tablodaki kuralların izin verdiği satırları görebiliyor. RLS açık ama hiç kural yoksa hiçbir şey göremiyor.

Tersi de doğru: RLS kapalı bir tablo, anahtarı bulan herkese açık. Yani publishable anahtarın güvenliği tamamen RLS’ye bağlı.

Anahtar pakete nasıl giriyor?

Next.js, NEXT_PUBLIC_ ile başlayan ortam değişkenlerini derleme sırasında JavaScript’in içine gömüyor. Vite’ta bu önek VITE_. Videodaki benzetme yerinde: Bu önek bir güvenlik etiketi değil, kargo etiketi. Videoda basit bir Next.js uygulaması derleniyor, ardından tarayıcıya giden dosyada arama yapılıyor ve adresle anahtar orada çıkıyor. Kimse bir şey hack’lemedi. Sadece tarayıcının zaten indirdiği dosya okundu. Aynı yol, yanlışlıkla secret anahtarı da gönderebilir.

Ne yapmalısın?

  • Gizli işleri sunucuya taşı. Tarayıcı senin API’ni çağırsın, secret anahtarı sadece o API kullansın.
  • Her açık tabloda RLS’yi aç ve kuralları dene. Farklı bir kullanıcıyla giriş yapıp başkasının satırını okumaya çalış.
  • Derlenmiş çıktıda ara. sb_secret_ ile başlayan bir değer görürsen sorun var. Eski anahtarlar eyJ ile başlayan JWT’ler ve rol adı açıkça yazmıyor. Ortadaki kısmı base64’ten çözdüğünde "role":"service_role" görürsen o anahtar sızmış demektir.
  • Sızdıysa hemen değiştir. Belgelerdeki sıra: yeni anahtar oluştur, her yerde değiştir, sonra eskisini kapat. Gizli anahtarları genel olarak nasıl yöneteceğini .env yazımızda anlattık.

Sonra ne oldu?

Supabase’in 7 Ocak 2026’daki güvenlik özetine göre panelden oluşturulan tablolarda RLS artık varsayılan olarak açık. SQL ya da migration ile oluşturulan tablolar için otomatik açan bir event trigger öneriliyor. Ayrıca herkese açık GitHub depolarına düşen secret anahtarlar otomatik iptal ediliyor. Eski anon ve service_role anahtarları 2026 sonunda kaldırılacak. Yeni anahtar oluşturmak eskilerini kapatmıyor, bu ayrı bir adım.

28 Nisan 2026’da duyurulan bir değişiklikle public şemasındaki yeni tablolar artık API’ye kendiliğinden açılmıyor. Açıkça grant vermen gerekiyor. Yeni projelerde bu Mayıs sonundan beri varsayılan. Duyuruya göre mevcut projelere 30 Ekim 2026’da uygulanacak. RLS ise aynen yerinde: İzin ve satır kuralı iki ayrı katman.

Düşün

  • Uygulamanın tarayıcıya gönderdiği dosyalarda en son ne zaman arama yaptın?
  • Tablolarındaki RLS kurallarını gerçekten başka bir kullanıcıyla test ettin mi?

Videoyu izle

Tıklayınca video YouTube'dan yüklenir; o ana kadar bu sayfa YouTube'a hiçbir istek göndermez.
Kaynaklar (9, İngilizce)

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.

Konu: Veritabanı3 dkVideo: Better Stack

İşe yarayan bir RAG sistemi: Parçalama, karma arama ve ölçmek

RAG, modele cevap vermeden önce kendi belgelerinden ilgili parçaları bulup vermek demek. Better Stack, Star Wars senaryolarıyla çalışan bir örnek üzerinden en sık yapılan hataları gösteriyor. Biz de videonun değinmediği adımları ekliyoruz: kelime ve anlam aramasını birleştirmek, yeniden sıralamak ve sonucu ölçmek.

Konu: Veritabanı3 dkVideo: Better Stack

NocoDB ve Plane: Airtable'ı ve Jira'yı kendi sunucunda çalıştırmak

NocoDB, var olan PostgreSQL ya da MySQL veritabanını Airtable benzeri bir tabloya ve otomatik bir API'ye çeviriyor. Plane ise Jira ve Linear yerine kendi sunucuna kurabileceğin bir proje yönetim aracı. İkisi de Docker ile dakikalar içinde ayağa kalkıyor, ama lisansları aynı değil: NocoDB Ocak 2026'da AGPL'den ayrıldı.