Sitemi ya da uygulamamı yayına almadan önce gizli anahtar, erişim ve izleme kontrolü yapan düzen

Sistem nasıl bağlanıyor

Gizli anahtar taraması (TruffleHog) → GitHub uyarılarına bakış → sızıntıda anahtarı yenileme → Supabase erişim gözden geçirmesi → yayın ve alan adı ayarları → erişilebilirlik ve açık/kapalı izleme → sorumlu kişili düzeltme listesi.

• 
  TruffleHog gerekli

  Depo geçmişini ve dosyaları yerel bilgisayarında tarar; varsayılan ayarda bulduğu anahtarı hizmetin API'sinde dener

  Araç rehberi

• 
  GitHub gizli anahtar taraması isteğe bağlı

  Depon GitHub'daysa uyarıların ve push protection'ın nerede göründüğünü kontrol edersin

  Alternatif: Deponu GitHub'da tutuyorsan; TruffleHog'un yanında ek bir uyarı katmanıdır, yerine geçmez

  Aracı tanı

• 
  GitGuardian ggshield isteğe bağlı

  TruffleHog yerine kullanılabilecek komut satırı tarayıcısı; GitGuardian hesabı ister ve taranan içerik GitGuardian'ın API'sine gönderilir

  Alternatif: Hesap açmayı ve taranan içeriğin GitGuardian sunucusuna gitmesini kabul ediyorsan

  Araç rehberi

• S
  Supabase satır düzeyi güvenlik gerekli

  Kullanıcı verisinin kimler tarafından okunup yazılabildiğini belirleyen veritabanı kuralları; bu rehberde yalnız gözden geçirilir

  Resmî sitesi

• 
  Lighthouse gerekli

  Chrome DevTools içinde erişilebilirlik denetimi çalıştırır

  Aracı tanı

• 
  Better Stack gerekli

  Sitenin açık olup olmadığını dışarıdan kontrol edip uyarı gönderir

  Araç rehberi

• 
  SigNoz isteğe bağlı

  Uygulamanın içinden iz ve hata verisi toplamak isteyen ekipler için daha kapsamlı izleme

  Alternatif: Basit açık/kapalı kontrolü yetmiyor, uygulama içi hata ve performans verisi gerekiyorsa; kurulumu bu rehbere dahil değil

  Araç rehberi

• 
  Cloudflare isteğe bağlı

  Alan adın zaten Cloudflare'deyse DNS ve koruma ayarlarını gözden geçirirsin

  Alternatif: Yalnızca alan adın Cloudflare üzerinden yönetiliyorsa

  Aracı tanı

• 
  Docker isteğe bağlı

  İsteğe bağlı ve ileri düzey: yalnızca yerel Supabase kopyasında test etmek istersen gerekir

  Alternatif: Erişim testini canlı projede değil yerel bir kopyada yapmak istiyorsan

  Aracı tanı

• 
  Strix isteğe bağlı

  İleri okuma: yalnız kendi uygulamanda ve test ortamında, açık yazılı izinle kullanılan otomatik güvenlik test aracı; bu rehberde kurulmaz

  Alternatif: Temel kontrolü bitirdikten sonra daha derin test düşünüyorsan

  Araç rehberi

• 
  CrowdSec isteğe bağlı

  İleri okuma: bu rehberde kurulmaz

  Alternatif: Temel kontrolü bitirdikten sonra sunucu koruması araştırıyorsan

  Araç rehberi

• 
  NVIDIA SkillSpector isteğe bağlı

  İleri okuma: bu rehberde kurulmaz

  Alternatif: Temel kontrolü bitirdikten sonra ek tarama araçlarını araştırıyorsan

  Araç rehberi

Başlamadan önce

Adım adım kurulum

İşaretlediğin adımlar yalnız bu tarayıcıda kalır; kurulumun çalıştığını doğrulamaz. 0/9 adımı bitirdin.

1. 1. adım · Bir uygulamada

   Neyi kontrol ettiğini ve sorumlu kişiyi yaz

   Bu adımı bitirdim

   Ne için: Bulunan her işin bir sahibi olsun; kontrol belirsiz kalmasın.

   !Burada sen kontrol edersin; sistem bu adımı senin onayın olmadan ilerletmemeli.

   1. Başkasına ait (müşteri) bir depo ya da proje ise önce yazılı izin al. İzinsiz tarama yapma; canlı kullanıcı verisini açma ya da dışa aktarma.
   2. Bir sayfaya şunları yaz: kontrol edilecek depolar, Supabase projesi, alan adı, hosting ve izleme hesabı.
   3. Her madde için bir sorumlu kişi seç ve bulguların yazılacağı düzeltme listesi dosyasının yerini belirle.
   4. Anahtar sızıntısı olduğunda kimin hangi hesapta anahtar yenileyeceğini ve uyarıların hangi e-postaya düşeceğini şimdiden yaz.
   5. Bulguları yazarken anahtarın kendisini değil türünü, dosyasını ve commit numarasını yaz. Anahtar değerini listeye, e-postaya, sohbete, destek formuna ya da yapay zekâ asistanına yapıştırma.

   Doğru yaptığını şuradan anlarsın

   • Tek sayfalık kapsam listesi, sorumlu adları ve uyarı e-postası yazılıdır.
   Takılırsan: bu adıma özgü sorunlar

   • Sorumlu kişi belirsiz, herkes birbirine bırakıyor
     Her bulguya tek isim yaz; anahtar yenileme yetkisi olan kişi listede mutlaka yer alsın.
   • Hangi hesapların hangi anahtarı kullandığı bilinmiyor
     Önce Supabase Dashboard'daki API Keys bölümüne ve hosting panelinin ortam değişkenlerine bak, bulduğunu listeye ekle.
   Dayanak: GitHub Docs: bir depodan hassas veriyi kaldırma, Supabase Docs: API anahtarları
2. 2. adım · Bir uygulamada

   TruffleHog'u belirli bir sürümden indir

   Bu adımı bitirdim

   Ne için: Taramayı kendi bilgisayarında, hesap açmadan çalıştırmak.

   !Burada sen kontrol edersin; sistem bu adımı senin onayın olmadan ilerletmemeli.

   1. TruffleHog GitHub sürüm sayfasında v3.99.2'yi aç. Windows için trufflehog_3.99.2_windows_amd64.tar.gz, macOS ve Linux için ilgili arşivi indir.
   2. Aynı sürüm sayfasındaki checksums dosyasından arşivin SHA256 değerini bul. Windows'ta aşağıdaki Get-FileHash komutuyla kendi dosyanın değerini hesapla ve iki değeri karşılaştır; büyük/küçük harf farkı önemsizdir, harflerin kendisi aynı olmalı (README'deki sha256sum komutu Linux ve macOS içindir).
   3. Bu karşılaştırma dosyanın indirme sırasında bozulmadığını gösterir; yayıncının kimliğini kanıtlamaz, çünkü ikisi aynı sürüm sayfasından gelir. README ayrıca checksums dosyasının imzasını Cosign ile kontrol etmeyi anlatır; bu rehber onu kurmaz.
   4. Arşivi açıp trufflehog programını ayrı bir araçlar klasörüne koy ve terminalden çalıştırabildiğinden emin ol. Kurulum betiği indirip doğrudan çalıştırma yolunu kullanma.
   WindowsKlasör: Arşivi indirdiğin klasör

   › Get-FileHash .\trufflehog_3.99.2_windows_amd64.tar.gz -Algorithm SHA256Kopyala

   Doğru yaptığını şuradan anlarsın

   • Terminalde trufflehog yazınca komut listesi görünür.
   • İndirdiğin dosyanın SHA256 değeri checksums dosyasındakiyle aynıdır (harf büyüklüğü hariç); bu yalnız indirmenin bozulmadığını gösterir.
   Takılırsan: bu adıma özgü sorunlar

   • Windows arşivi açamıyorsun
     Dosya .tar.gz biçiminde; bunu açabilen bir arşiv programı kullan ya da destek iste. Docker ile çalıştırma yolu README'de var ama Docker kurulumu gerektirir.
   • Terminal trufflehog komutunu bulamıyor
     Programın bulunduğu klasörden tam yol vererek çalıştır ya da klasörü sistem yoluna ekle.
   Dayanak: TruffleHog README, TruffleHog v3.99.2 sürümü, Microsoft Learn: Get-FileHashBu adımda yardım al →
3. 3. adım · Terminalde

   Deponun geçmişini ve yayın dosyalarını gizli anahtar için tara

   Bu adımı bitirdim

   Ne için: Kodda, eski kayıtlarda ya da yayın çıktısında kalmış anahtar ve şifreleri aramak.

   !Burada sen kontrol edersin; sistem bu adımı senin onayın olmadan ilerletmemeli.

   1. ÇALIŞTIRMADAN ÖNCE: Varsayılan komutlar (1. ve 3.), bulunan anahtarı doğrulamak için ilgili hizmetin API'sine bağlanır (README'de AWS için GetCallerIdentity çağrısı örneği var). Yani bulunan gerçek bir anahtar bilgisayarından o sağlayıcıya denenir ve sağlayıcının kaydında iz bırakabilir; 3. komut .env dosyasını taradığı için projedeki canlı anahtarlar da buna dahildir. Başkasına ait bir depoda bunu yapma.
   2. Anahtarların dışarı denenmesini istemiyorsan 2. ve 4. komutu kullan (ikisinde de --no-verification var).
   3. 1. komut (git geçmişi) ve 3. komut (dosyalar) ayarsız çalışır: doğrulanmış, doğrulanmamış ve bilinmeyen sonuçların hepsini gösterir. 2. ve 4. komut doğrulamayı kapatır; bu durumda bulguların hepsi 'doğrulanmamış' görünür, bu normaldir. Doğrulamasız komutları --results=verified,unknown ile birleştirme: doğrulama kapalıyken bulgular filtreye takılıp çıktı boş görünebilir ve 'temiz' sanabilirsin.
   4. Sonuç türleri: verified, anahtarın hizmette geçerli ve etkin olduğunu gösterir (en acil olanlar); unverified, anahtar gibi bir değer bulundu ama TruffleHog geçerliliğini sağlayıcıya onaylatamadı (geçersiz de olabilir, gerçek de olabilir, tek tek incele); unknown, doğrulama ağ ya da API hatasıyla yapılamadı (tekrar dene ve incele).
   5. 3. ve 4. komut git geçmişini değil, commit edilmemiş dosyaları ve yayın çıktısını tarar (örneğin .env ve build klasörü). Git taraması bu dosyaları görmez. Klasör adlarını kendi projene göre değiştir.
   6. Terminal çıktısı anahtarın tam değerini ekrana basar. Çıktıyı, ekran görüntüsünü ya da anahtarı hiç kimseyle (destek, sohbet, yapay zekâ dahil) paylaşma. Listeye yalnızca türünü, dosyasını ve commit numarasını yaz. Gördüğün her gerçek anahtarı ifşa olmuş say ve yenile.
   7. Boş çıkması 'sızıntı yok' demek değildir; tarama her türü yakalayamaz.
   Windows · macOS · LinuxKlasör: Taranacak proje klasörü

   › trufflehog git file://.Kopyala

   Windows · macOS · LinuxKlasör: Taranacak proje klasörü

   › trufflehog git file://. --no-verificationKopyala

   Windows · macOS · LinuxKlasör: Taranacak proje klasörü

   › trufflehog filesystem .env distKopyala

   Windows · macOS · LinuxKlasör: Taranacak proje klasörü

   › trufflehog filesystem .env dist --no-verificationKopyala

   Doğru yaptığını şuradan anlarsın

   • Terminal tarama bitince bulguları listeler ya da bulgu yoksa özet gösterir.
   • Çıkan bulguları türüne göre ayırıp anahtar değerini yazmadan listene ekledin.
   Takılırsan: bu adıma özgü sorunlar

   • Hiç bulgu çıkmadı ama bir anahtarı bir zamanlar koyduğunu biliyorsun
     O anahtarı yine de yenile; tarama her türü yakalayamaz. Ayrıca 3. ya da 4. komutla commit edilmemiş dosyalara ve yayın çıktısına bak.
   • Çok sayıda bulgu çıktı
     Önce verified, sonra unverified ve unknown sonuçlarını incele; test ve örnek dosyalardaki sahte değerleri listede 'sorun değil' diye not et ama silme.
   • 3. ya da 4. komut dosya bulunamadı diyor
     Komuttaki .env ve dist adlarını projendeki gerçek dosya ve yayın klasörü adlarıyla değiştir; README filesystem komutuna bir ya da daha çok yol verilebildiğini gösterir.
   Dayanak: TruffleHog READMEBu adımda yardım al →
4. 4. adım · Tarayıcıda

   GitHub'daki gizli anahtar uyarılarına ve push protection'a bak

   Bu adımı bitirdim

   Ne için: Yeni sızıntıların nerede görüneceğini ve hangi korumanın seninkine uygulandığını bilmek.

   !Burada sen kontrol edersin; sistem bu adımı senin onayın olmadan ilerletmemeli.

   1. Deponun herkese açık mı özel mi olduğuna bak. Herkese açıksa gizli anahtar taraması otomatik ve ücretsiz çalışır; uyarıları depodaki 'Security and quality' sekmesinde görürsün. Depo zaten herkese açıksa, içine girmiş her anahtarı ifşa olmuş say. GitHub'ın taraması geçmiş sızıntıyı geri almaz ve TruffleHog taramasının yerine geçmez.
   2. Özel depon bir kuruluşa aitse GitHub Secret Protection'ın açık olup olmadığına bak; belgeye göre özel depoda tarama bu ürünle gelir ve Team ya da Enterprise planı ister. Belgeye göre kişisel hesaba ait özel depolarda gizli anahtar taraması yalnızca Enterprise Cloud'da Enterprise Managed Users ile (ya da Enterprise Server'da Secret Protection açıksa) vardır; sıradan kişisel özel depoda yoktur.
   3. Kişisel hesaptaki özel depoda GitHub taraması yoktur; bu depoda yalnız kendi TruffleHog taramana dayanırsın, o da her anahtarı yakalamaz.
   4. Kişisel hesap düzeyindeki push protection ile depo düzeyindeki push protection ayrı özelliklerdir: kişisel olan varsayılan açıktır ve herkese açık depolara anahtar göndermeni engeller; depo düzeyindeki ise Secret Protection ister ve varsayılan kapalıdır.

   Doğru yaptığını şuradan anlarsın

   • Depon için uyarıların hangi ekranda göründüğünü ve hangi korumanın açık olduğunu not ettin.
   Takılırsan: bu adıma özgü sorunlar

   • Deponda gizli anahtar bölümü yok
     Depo özel ve Secret Protection kapalı ya da hesabın bu özelliğin kapsamında olmayabilir; bu durumda TruffleHog taramasını düzenli çalıştır ve satın alma kararını verecek kişiye bildir.
   • Push protection'ı aşıp 'sonra düzeltirim' dedin
     Belgeye göre bu seçim açık bir uyarı oluşturur; uyarıyı kapatmadan anahtarı yenile.
   Dayanak: GitHub Docs: gizli anahtar taraması, GitHub Docs: push protection, GitHub Changelog: ücretsiz kullanıcılar için push protection (29 Şubat 2024), GitHub Docs: GitHub Advanced Security (Secret Protection satın alma koşulu)Bu adımda yardım al →
5. 5. adım · Tarayıcıda

   Bir anahtar sızdıysa onu yenile, sadece silmekle yetinme

   Bu adımı bitirdim

   Ne için: Sızan anahtarın artık hiçbir işe yaramaması.

   !Burada sen kontrol edersin; sistem bu adımı senin onayın olmadan ilerletmemeli.

   1. Sızan anahtarın hangi hizmete ait olduğunu belirle. Sızıntının nedenini (yanlış dosya, açık depo) kapat; yoksa yeni anahtar da sızar.
   2. Sıra: 1) hizmetin panelinde yeni anahtar oluştur, 2) kullanılan her yerde (sunucu, hosting ortam değişkenleri, otomasyonlar) yenisiyle değiştir, 3) her bileşenin yeni anahtarla çalıştığını kontrol et, 4) ancak ondan sonra eski anahtarı iptal et ya da sil. Yeni anahtar çalışmadan eskisini kapatma.
   3. GitHub belgesine göre ilk adım anahtarı iptal etmek ya da yenilemektir; Git geçmişini silmek yeterli değildir, çünkü başkalarının kopyaları ve çatallar (fork) duruyor.
   4. Supabase'de secret key sızdıysa aynı sıra geçerli; eski JWT tabanlı service_role anahtarı için ise eski anahtarları aynı bölümde devre dışı bırakırsın (geri açılabilir).
   5. Sızan anahtarın hizmetteki kullanım ve erişim kayıtlarına bakmak mantıklıdır, ama Supabase belgesi sızıntı sonrası nerede bakılacağını anlatmıyor. Hizmetin kayıt ya da kullanım ekranını bulamazsan veya şüpheli bir şey görürsen uzmana göster. Kayıtta bir şey görmemek 'sorun yok' demek değildir.

   Doğru yaptığını şuradan anlarsın

   • Eski anahtar hizmet panelinde iptal edildi (Supabase eski JWT anahtarlarında bu, geri alınabilir devre dışı bırakmadır; silme değil).
   • Site ve uygulama yeni anahtarla çalışmaya devam eder.
   Takılırsan: bu adıma özgü sorunlar

   • Eski anahtarı silince sitenin bir kısmı çalışmayı bıraktı
     Yenileme sırasında bir bileşeni atladın demektir; Supabase belgesi eski anahtarları silmeden önce hepsinin yeni anahtara geçtiğini kontrol etmeyi söyler. Bu yüzden legacy anahtarı önce devre dışı bırakıp geri açılabilir durumda tut.
   • Anahtar zaten herkese açık bir depoda uzun süredir duruyor
     Kullanıldığını varsay; yenilemeden sonra hizmetin kayıt ekranını bulabiliyorsan bak, bulamıyorsan ya da olağan dışı bir şey görürsen uzman incelemesi iste. Kayıt görünmemesi güvende olduğun anlamına gelmez.
   Dayanak: GitHub Docs: bir depodan hassas veriyi kaldırma, Supabase Docs: API anahtarlarıBu adımda yardım al →
6. 6. adım · Tarayıcıda

   Kullanıcı verisinin Supabase'deki durumunu listele (güvenlik kanıtı değildir)

   Bu adımı bitirdim

   Ne için: Durumu görüp listelemek: hangi tabloda RLS kapalı, gizli anahtar nerede duruyor, hangi bulgu uzmana gösterilecek.

   !Burada sen kontrol edersin; sistem bu adımı senin onayın olmadan ilerletmemeli.

   1. Supabase Dashboard'da Settings içindeki API Keys bölümüne bak. Tarayıcıya ya da mobil uygulamaya yalnızca yayımlanabilir anahtar (sb_publishable_ ile başlar) girmeli; sb_secret_ ile başlayan gizli anahtar sadece sunucuda durmalı. Eski anahtarlarda anon ve service_role ikisi de uzun JWT'dir ve eyJ ile başlar; bu yüzden değere bakarak hangisi olduğunu gözle ayırt edemezsin.
   2. Hangisinin hangisi olduğunu Dashboard'daki eski anahtar listesinde etiketinden (anon ya da service_role) oku.
   3. Sitenin yayın dosyalarında eyJ ile başlayan bir değer bulursan Dashboard'daki eski anahtar listesindeki değerlerle birebir karşılaştır; service_role ya da sb_secret_ istemcide olmamalı, anon ve sb_publishable_ olması normaldir. Hangisi olduğunu çıkaramazsan değeri kimseye yapıştırmadan uzmana göster.
   4. Dashboard'da Güvenlik Danışmanı'nı (Security Advisor) aç ve çıkan her bulguyu tek tek oku. Ne anlama geldiğini anlamadan bulguyu kapatma.
   5. Aşağıdaki salt okunur sorguyu SQL Editor'da çalıştır: public şemasındaki TÜM tabloları listeler; rowsecurity sütunu false olanlar satır düzeyi güvenliği (RLS) kapalı tablolardır, true yazanlar yalnız RLS'nin açık olduğunu söyler. RLS kapalı bir tablo, erişim izni olan her rol tarafından okunabilir ve yazılabilir. Kullanıcı verisi tutan tabloları listeye yaz; API'ye açılmış başka şemalar varsa onları da ara.
   6. Sorgu bölümlenmiş (partition) ve yabancı tabloları ve zorunlu RLS (FORCE) durumunu göstermez.
   7. Bu sorgu neyi göstermez: RLS açık olması her satırın korunduğu anlamına gelmez. Gevşek bir politika (örneğin anon rolüne her satırı okutan bir kural), RLS'yi atlayan görünümler (view), fonksiyonlar ve Storage kovaları bu sorguda görünmez ve bu rehberin kapsamı dışındadır. Riskli gördüğün her tabloyu ve politikayı uzmana göster.
   8. Canlı veritabanında değişiklik yapma ve canlıya test kullanıcısı ya da test kaydı ekleme. Düzeltmeyi uygulamayı yazan kişiye bırak.
   9. Rehberin önerdiği (Supabase belgesinde adım adım anlatılmayan) iki kullanıcılı deneme, uygulamayı yazan kişiyle ayrı bir test projesinde yapılır. Test projesinin kurulumu bu rehberin kapsamı dışındadır, onu uygulamayı yazan kişi yapar: aynı tablo ve politikaları (migration dosyalarıyla) ayrı bir Supabase test projesine kurar; migration dosyası yoksa bu yol hazır değildir.
   10. Gerçek kullanıcı verisini test projesine kopyalama. Supabase CLI kullanılıyorsa, bir şey göndermeden önce hangi projeye bağlı olduğunu kontrol et; yanlışlıkla canlı projeye bağlıyken değişiklik göndermek canlıyı bozar. Test projesinde iki test kullanıcısı oluştur, birincisiyle kayıt ekle, ikincisiyle ve oturumsuz istekle o kaydı okumayı ve değiştirmeyi dene. Bu deneme yalnızca denediğin senaryoyu gösterir.
   11. Deneme geçse bile bu sistemin güvenli olduğunu göstermez. Yerel Supabase kopyası da kullanılabilir ama ileri düzeydir ve Docker ister.
   rls-durumu.sql (salt okunur sorgu) · sqlKopyala

   select schemaname, tablename, rowsecurity
   from pg_tables
   where schemaname = 'public'
   order by tablename;

   Yalnızca okur. public şemasındaki tüm tabloları listeler; rowsecurity sütunu false olan satırlar satır düzeyi güvenliği kapalı tablolardır.

   Doğru yaptığını şuradan anlarsın

   • Kullanıcı verisi tutan her tablonun RLS durumunu ve riskli gördüklerini listene yazdın.
   • Test projesinde denediğin senaryoların sonucunu 'denenen senaryo' olarak yazdın.
   Takılırsan: bu adıma özgü sorunlar

   • Yerel test için Supabase yığınını kurmak istiyorsun ama Docker yok
     Bu yol isteğe bağlı ve ileri düzeydir: belgeye göre yerel yığın Docker kapsayıcılarında çalışır. Docker Desktop kurmadan önce şirket boyutunun lisans koşuluna uyduğuna bak (250 çalışandan az ve 10 milyon dolardan az gelirli küçük işletmeler için ücretsiz tanımlı) ya da testi ayrı bir Supabase test projesinde yap.
   • RLS açık ama tabloya hiçbir veri gelmiyor
     Belgeye göre RLS açıldığında politika yazılana kadar API üzerinden veri gelmez; bu beklenen davranıştır, politikayı uygulamayı yazan kişi tanımlar.
   Dayanak: Supabase Docs: Row Level Security, Supabase Docs: API anahtarları, Supabase Docs: veritabanı testi, PostgreSQL belgesi: pg_tables görünümü, Supabase Docs: CLI ile yerel geliştirmeBu adımda yardım al →
7. 7. adım · Tarayıcıda

   Yayın ayarlarını gözden geçir (Cloudflare yalnız ihtiyacın varsa)

   Bu adımı bitirdim

   Ne için: Anahtarların doğru yerde durduğunu ve alan adı korumasının uygulamayı bozmadığını görmek.

   !Burada sen kontrol edersin; sistem bu adımı senin onayın olmadan ilerletmemeli.

   1. Hosting panelinde ortam değişkenlerine bak: gizli anahtarlar yalnızca sunucu tarafında ve ortam değişkeni olarak durmalı; kaynak koduna, CI betiklerine ya da tarayıcıya giden dosyalara girmemeli.
   2. Anahtarları sohbette, e-postada ya da SMS ile paylaşmadığını kontrol et; Supabase belgesi bunu açıkça yasaklar.
   3. Alan adın zaten Cloudflare'de ise (bu rehber alan adını Cloudflare'e taşımayı anlatmaz; taşıyacaksan Cloudflare'in kendi belgesini oku ve önce mevcut DNS kayıtlarını dışa aktar): Free plan kişisel ve iş açısından kritik olmayan projeler için tanımlı; ticari site için plan seçimini Cloudflare'den değerlendir. Planlar sayfasında Free planda DDoS koruması, WAF ve 'simple bots' bot koruması listelenir.
   4. Bot Fight Mode'u açmadan önce mevcut ayarı not et. Açarsan JavaScript Detections otomatik açılır ve kapatılamaz; Content Security Policy kullanıyorsan Cloudflare'in /cdn-cgi/challenge-platform/ yoluna izin vermen gerekir. Belgeye göre JavaScript Detections, nonce'u <meta> etiketiyle verilen CSP'de desteklenmez. Mod API ya da mobil trafiği zorlayabilir ve WAF kurallarıyla atlanamaz.
   5. Açtıktan sonra giriş, form, ödeme dönüşü, webhook, Supabase fonksiyon çağrıları ve e-posta bağlantılarını dene.
   6. Sorun çıkarsa Cloudflare panelinde Security > Settings sayfasına gidip 'Bot traffic' ile filtrele ve Bot Fight Mode'u kapatıp önceki ayara dön.
   7. Cloudflare kullanmıyorsan bu adımın Cloudflare kısmını atla; başlangıç kontrolü Cloudflare gerektirmez.

   Doğru yaptığını şuradan anlarsın

   • Gizli anahtarların yerleri listende yazılı ve kaynak kodunda hiç gizli anahtar yok.
   • Cloudflare kullanıyorsan Bot Fight Mode durumu ve uygulamanın hâlâ çalıştığı not edildi.
   Takılırsan: bu adıma özgü sorunlar

   • Cloudflare açıldıktan sonra uygulama API çağrıları, webhook'lar ya da ödeme dönüşü reddediliyor
     Belgeye göre Bot Fight Mode API ve mobil trafiği zorlayabilir ve WAF kuralıyla atlanamaz. Önce modu kapatıp sorunun geçtiğini gör; daha ayrıntılı kontrol için Cloudflare Bot Management for Enterprise'ı önerir, yani Free planda ince ayar yoktur.
   • Anahtarın hangi ortam değişkeninde olduğunu bilmiyorsun
     Hosting panelinde ortam değişkenleri bölümünü aç ve adlara bak; kimin yazdığını bulamıyorsan anahtarı yenile ve değişkeni yeniden yaz.
   Dayanak: Supabase Docs: API anahtarları, Cloudflare: Ağ ve CDN planları, Cloudflare Docs: Bot Fight ModeBu adımda yardım al →
8. 8. adım · Tarayıcıda

   Erişilebilirlik denetimi yap ve açık/kapalı izleme kur

   Bu adımı bitirdim

   Ne için: Sitenin kullanılabilirlik sorunlarını görmek ve kapanırsa haberin olması.

   !Burada sen kontrol edersin; sistem bu adımı senin onayın olmadan ilerletmemeli.

   1. Chrome'da sitenin önemli sayfalarını aç, DevTools'u açıp Lighthouse sekmesinden Accessibility kategorisini çalıştır. Çıkan sorunları listeye yaz; Lighthouse ayrıca elle bakman gereken 'manual checks' maddeleri de listeler, onlara ayrıca bak.
   2. Better Stack'te Monitors bölümünden Create monitor seç, sitenin adresini yaz ve HTTP durum kodu kontrolü kur (belge 2XX başarı kodu beklendiğini söylüyor). Belge yönlendirme davranışını anlatmıyor; alarm geliyorsa monitörün gösterdiği durum kodunu kontrol et, gerekirse nihai adresi gir. 'How should we escalate incidents?' bölümünde uyarı seçeneğini belirle.
   3. Uyarı kanalı olarak e-posta ya da Slack seç (ücretsiz planda 'Slack & e-mail alerts' listelenir). Uyarının gideceği kişi, kapsam sayfasındaki sorumlu olmalı.
   4. Uyarı testi için canlı monitörün adresini bozma: ayrı bir geçici test monitörü oluştur, var olmayan bir adres ver, uyarının sorumluya geldiğini gör, sonra test monitörünü sil.
   5. Uygulama içi hata ve performans verisi toplamak istiyorsan SigNoz'u ileri okuma olarak değerlendir; başlangıç kontrolü bunu gerektirmez.

   Doğru yaptığını şuradan anlarsın

   • Lighthouse erişilebilirlik raporunun sonuçları listene eklendi.
   • Better Stack'te aktif bir monitör var ve test uyarısı sorumlu kişiye ulaştı.
   Takılırsan: bu adıma özgü sorunlar

   • Better Stack ücretsiz planı iş sitesi için uygun mu belli değil
     Fiyat sayfası ücretsiz planı kişisel projeler için tanımlıyor; işletme kullanımı için Better Stack'e sor ya da ücretli planı seç.
   • Uyarı e-postası gelmedi
     Önce spam klasörüne bak, sonra Better Stack'te monitörün uyarı kanalını ve e-posta adresini kontrol et.
   • Sitenin yönlendirmesi var ve monitör alarm veriyor
     Belge yönlendirme davranışını anlatmıyor; monitörün gösterdiği durum kodunu kontrol et, gerekirse yönlendirme sonrası nihai adresi gir.
   Dayanak: Chrome for Developers: Lighthouse genel bakış, Better Stack Docs: izlemeye başlama, Better Stack fiyatlandırmaBu adımda yardım al →
9. 9. adım · Bir uygulamada

   Bulguları sorumlusu ve tarihi olan bir düzeltme listesine çevir

   Bu adımı bitirdim

   Ne için: Kontrolün sonunda yapılacak işler ve sınırlar belli olsun.

   !Burada sen kontrol edersin; sistem bu adımı senin onayın olmadan ilerletmemeli.

   1. Önceki adımlardaki bulguları tek listede topla: bulgu, nerede, öncelik (sızan ve hâlâ geçerli anahtar en üstte), sorumlu kişi ve hedef tarih.
   2. Listeye anahtarın kendisini yazma; türünü, yerini ve commit numarasını yaz. Listeyi, bulguları ya da terminal çıktısını destek hizmetiyle paylaşırken anahtar değeri içermediğinden emin ol.
   3. Düzeltilemeyen ya da emin olmadığın her madde için 'uzman incelemesi gerekiyor' yaz.
   4. Listenin en altına şu notu yaz: 'Bu bir temel yayın kontrolüdür. Güvenlik sertifikası ya da sızma testi değildir ve sistemin güvenli olduğunu göstermez.'
   5. Kontrolü yayından önce ve büyük değişikliklerden sonra tekrarla; tarihini listeye ekle.

   Doğru yaptığını şuradan anlarsın

   • Tek sayfalık listede her bulgunun sorumlusu ve tarihi var.
   • Listenin sonunda sınır notu yazılı.
   Takılırsan: bu adıma özgü sorunlar

   • Liste çok uzun, nereden başlayacağın belli değil
     Önce geçerli anahtar sızıntıları, sonra herkese açık kalmış kullanıcı verisi, sonra izleme ve erişilebilirlik sorunlarını al.
   • Bir bulgunun gerçek risk olup olmadığından emin değilsin
     Kendin kapatma; ilgili hizmetin belgesini oku ya da uzman incelemesi iste ve listede 'incelemede' olarak işaretle.
   Dayanak: GitHub Docs: bir depodan hassas veriyi kaldırma, Supabase Docs: API anahtarlarıBu adımda yardım al →

Neye para ödenir

Kalemler ayrıdır ve toplam değildir; hangilerinin sana gerektiği kurduğun yola bağlıdır. Fiyatlar değişir, her kalemin kaynağına bak.

• Ücret yokTruffleHog

  AGPL-3.0 açık kaynak; kullanmak için ücret kalemi belgede yok. kaynak

• AbonelikGitHub Secret Protection

  Özel depodaki kuruluş projelerinde gizli anahtar taraması bu ürünle gelir ve GitHub Team ya da Enterprise planı ister; fiyatı GitHub'ın faturalandırma sayfasında. kaynak

• AbonelikGitGuardian ggshield (alternatif)

  Fiyat sayfasında Starter plan 0 ABD doları, en fazla 25 geliştirici ve ayda 10 bin API çağrısı olarak listelenir. Karşılaştırma tablosunda ggshield CLI için 'Limited' yazar; hangi plan sütununa ait olduğunu sayfadan kesin çıkaramadık. Kişisel/ticari kullanım koşulu sayfada belirtilmemiş. (17 Ekim 2026) kaynak

• AbonelikBetter Stack izleme

  Ücretsiz plan 10 monitör ve nabız izleyici, Slack ve e-posta uyarısı içerir ve kişisel projeler için tanımlıdır; işletme için plan koşullarını Better Stack'ten kontrol et. kaynak

• AbonelikCloudflare (yalnız alan adın orada ise)

  Free plan 0 ABD doları, kişisel ya da iş açısından kritik olmayan projeler için tanımlı; daha üst planlar ücretlidir. (17 Ekim 2026) kaynak

• AbonelikDocker Desktop (yalnız yerel Supabase testi için)

  Ücretsiz kullanım koşulu: 250 çalışandan az ve 10 milyon dolardan az yıllık gelirli küçük işletme; daha büyükler ücretli plan ister. (17 Ekim 2026) kaynak

• Kurulum hizmetiYapılandırma ve düzeltme desteği

  Bulunan konuları düzeltme ve ayarları yapılandırma için DijiKoçum'dan destek alabilirsin. Bağımsız sızma testi ve uzman güvenlik incelemesi bu hizmetin kapsamında değildir; gerekirse ayrı bir uzmana yönlendirilirsin.

• AbonelikAyrı Supabase test projesi (yalnız iki kullanıcılı deneme için)

  Ücretsiz planın proje sayısı sınırı ya da ücreti burada yazılı değil; test projesi açmadan önce Supabase'in plan ve fiyat sayfasını kontrol et. kaynak

Kaynaklar

• GitHub Docs: gizli anahtar taraması · Resmî belge · okundu 17 Ekim 2026
• GitHub Docs: push protection · Resmî belge · okundu 17 Ekim 2026
• GitHub Changelog: ücretsiz kullanıcılar için push protection (29 Şubat 2024) · Üretici sayfası · okundu 17 Ekim 2026
• GitHub Docs: GitHub Advanced Security (Secret Protection satın alma koşulu) · Resmî belge · okundu 17 Ekim 2026
• GitHub Docs: bir depodan hassas veriyi kaldırma · Resmî belge · okundu 17 Ekim 2026
• TruffleHog README · Kaynak kod · okundu 17 Ekim 2026
• TruffleHog v3.99.2 sürümü · Kaynak kod · okundu 17 Ekim 2026
• GitGuardian fiyatlandırma · Üretici sayfası · okundu 17 Ekim 2026
• ggshield README · Kaynak kod · okundu 17 Ekim 2026
• Supabase Docs: Row Level Security · Resmî belge · okundu 17 Ekim 2026
• Supabase Docs: API anahtarları · Resmî belge · okundu 17 Ekim 2026
• Supabase Docs: veritabanı testi · Resmî belge · okundu 17 Ekim 2026
• Supabase Docs: CLI ile yerel geliştirme · Resmî belge · okundu 17 Ekim 2026
• PostgreSQL belgesi: pg_tables görünümü · Resmî belge · okundu 17 Ekim 2026
• Cloudflare: Ağ ve CDN planları · Üretici sayfası · okundu 17 Ekim 2026
• Cloudflare Docs: Bot Fight Mode · Resmî belge · okundu 17 Ekim 2026
• Docker Docs: Docker Desktop lisansı · Resmî belge · okundu 17 Ekim 2026
• Chrome for Developers: Lighthouse genel bakış · Resmî belge · okundu 17 Ekim 2026
• Better Stack fiyatlandırma · Üretici sayfası · okundu 17 Ekim 2026
• Better Stack Docs: izlemeye başlama · Resmî belge · okundu 17 Ekim 2026
• Strix README · Kaynak kod · okundu 17 Ekim 2026
• Microsoft Learn: Get-FileHash · Resmî belge · okundu 17 Ekim 2026