Solo kurucu için güvenlik temelleri

Tek başına ürün yaparken güvenlik genelde "büyüyünce bakarım" listesine giriyor. Güvenlik ekibin yok, denetim yok, kimse kodunu incelemiyor. Ama saldırganlar ürününün kaç kullanıcısı olduğuna bakmıyor. İnternette açık bir veritabanı ya da sızmış bir anahtar arayan otomatik tarayıcılar, küçük bir projeyi de büyük bir şirketi de aynı hızla buluyor.

İyi haber şu: solo kurucuların başına gelen olayların çoğu karmaşık saldırılar değil. Unutulmuş bir anahtar, kapatılmamış bir veritabanı, hiç denenmemiş bir yedek. Bunlar birkaç saatlik bir düzenle büyük ölçüde önlenebilir.

Bu yazı, OWASP'ın listesi, Hacker News'te tartışılan gerçek olaylar ve Troy Hunt gibi güvenlik alanında yazan kişilerin deneyimleri üzerine kurulu bir temel hijyen listesi. Yapay zekâyla kod yazarken düşülen hatalar için Rehber'deki Yapay zekâyla geliştirirken 5 hata yazısına bak. Burada araçtan bağımsız temellere odaklanıyoruz.

OWASP listesi neden önemli?

OWASP (Open Worldwide Application Security Project), web uygulamalarındaki en yaygın güvenlik risklerini düzenli olarak listeleyen kâr amacı gütmeyen bir topluluk. En güncel sürüm OWASP Top 10:2025. Listenin ilk sıralarında şunlar var:

A01 Bozuk erişim kontrolü: Kullanıcının görmemesi gereken veriyi görebilmesi.
A02 Güvenlik yapılandırma hataları: Varsayılan ayarlarla bırakılmış ya da yanlış açılmış servisler.
A03 Yazılım tedarik zinciri hataları: Kullandığın paketlerden ve araçlardan gelen riskler.
A07 Kimlik doğrulama hataları: Zayıf giriş, oturum ve şifre yönetimi.

Bu yazıdaki maddelerin çoğu bu dört başlığın solo kurucu ölçeğindeki karşılığı. Listenin tamamını owasp.org'da okuyabilirsin. Her şeyi bir haftada öğrenmen gerekmiyor, ama ilk dört başlığı tanıman iyi bir başlangıç.

1. Gizli anahtarlar: koda değil, ortam değişkenine

API anahtarları, veritabanı şifreleri ve ödeme sağlayıcısı anahtarları en sık sızan şeyler. Mayıs 2026'da Hacker News'te tartışılan bir haber, ABD'nin siber güvenlik ajansı CISA'da çalışan bir yöneticinin AWS anahtarlarını GitHub'a sızdırdığını anlatıyordu. Başlıktaki yorumlardan biri iyi bir hatırlatma: burada yapay zekâya gerek yoktu, sıradan insan hatası hâlâ yeterince güçlü. Bir başka yorumcu da .env dosyalarındaki gizli bilgilerin kod asistanları tarafından okunup dışarı gönderilebileceği konusunda uyarıyor.

OWASP'ın gizli bilgi yönetimi rehberi temel kuralları şöyle sıralıyor:

Anahtarları kodun ya da yapılandırma dosyalarının içine yazma.
Kodu göndermeden önce, örneğin bir pre-commit kontrolüyle, sızmış anahtar taraması yap.
Her anahtara sadece ihtiyacı olan yetkiyi ver.
Anahtarları düzenli olarak yenile.

GitHub kullanıyorsan, kişisel hesaplarda varsayılan olarak açık gelen bir koruma var: herkese açık bir depoya gizli anahtar içeren kod göndermeye çalıştığında gönderimi engelliyor. Ama bu bir emniyet kemeri, asıl çözüm değil. Gizli dosyalarını baştan .gitignore'a ekle.

Sızdırırsan ne yapacaksın? OWASP'ın sırası net: anahtarı hemen iptal et, yenisini üret, eski anahtarı kod geçmişinden ve loglardan temizle. Sadece dosyadan silmek yetmez, git geçmişinde kalır. Ücretli API'lerde harcama limiti tanımlamak da sızıntının bedelini sınırlar.

2. Veritabanı: internete açık mı, kurallar yerinde mi?

2017'nin ilk günlerinde Hacker News'te açılan "Unsecured MongoDBs taken hostage" başlığı, şifresiz ve internete açık bırakılmış yüzlerce MongoDB veritabanının silindiğini, yerine fidye notu bırakıldığını anlatıyordu. Başlığı açan araştırmacı, kayıtlara göre verinin yedeğinin bile alınmadığını, yani fidye ödemenin işe yaramayacağını yazıyordu. Yorumlarda biri, birçok veritabanının varsayılan olarak sadece kendi makinesinden bağlantı kabul ettiğini, internete açmanın ayrıca bir ayar gerektirdiğini hatırlatıyor.

Bugün aynı hata farklı bir kılıkta dönüyor. Aralık 2025'te "Your Supabase is public if you turn off RLS" başlıklı bir yazı HN'de tartışıldı. Yazar, bir arkadaşının yeni SaaS ürününü incelerken tarayıcının ağ sekmesinde Supabase adresini ve herkese açık anahtarı bulduğunu anlatıyor. Satır düzeyinde güvenlik (RLS) kapalı bir kullanıcı tablosunda isimler, e-postalar ve şifre özetleri görünüyordu. Yazar, RLS olmadan bu anahtarın "a master key to your entire database" olduğunu söylüyor: veritabanının tamamına açılan bir ana anahtar. Bunu üçüncü kez gördüğünü de ekliyor. HN yorumlarında Firebase'de de insanların izinleri yanlış ayarladığı hatırlatılıyor.

Kontrol listen:

Veritabanın doğrudan internete açık mı? Açık olması gerekmiyorsa kapat.
Supabase ya da Firebase kullanıyorsan, her tabloda erişim kuralı tanımlı mı? Özellikle sonradan eklediğin tablolarda.
Giriş yapmamış bir kullanıcıyla ve başka bir kullanıcının hesabıyla kendi verine ulaşmayı dene. Bu, OWASP'ın A01 başlığının en basit testi.

Konya'da halı yıkama firmalarına sipariş takip aracı yapan bir kurucu düşün. Müşteri adresleri ve telefonları bu tabloda duruyor. Bir firmanın kullanıcısı adres çubuğundaki numarayı değiştirerek başka bir firmanın siparişlerini görebiliyorsa, sorun kodun güzelliğinde değil, erişim kuralında.

3. Yedek: almak yetmez, geri yüklemeyi dene

GitLab'ın 31 Ocak 2017 olayı, yedek konusunda en çok anlatılan hikâyelerden biri. GitLab'ın kendi yayımladığı olay sonrası rapora göre, bir mühendis yanlış sunucuda komut çalıştırdı ve canlı veritabanından yaklaşık 300 GB veri sildi. Site yaklaşık 18 saat kapalı kaldı.

Asıl ders sonrasında çıktı. Günlük alınması gereken yedekler boştu, çünkü yedekleme aracı veritabanının sürümüyle uyumsuzdu. Hata e-postaları da bir e-posta ayarı yüzünden kimseye ulaşmamıştı. Raporda kök nedenlerden biri açıkça yazıyor: yedeklerin çalıştığını test etmek kimsenin sorumluluğunda değildi. GitLab sonunda altı saatlik bir anlık görüntüden geri döndü ve tahminen binlerce projeye ait veriyi kaybetti.

Solo kurucu için ders basit: yedeklerin sorumlusu sensin ve bir yedeği geri yüklemeyi denemediysen elinde yedek olduğunu bilemezsin.

Barındırma sağlayıcının otomatik yedeklerinin açık olduğunu kontrol et.
Ayda bir, yedeği ayrı bir test ortamına geri yükle ve verinin yerinde olduğunu gör.
Yedeklerin bir kopyasını farklı bir yerde tut. Aynı hesap ele geçirilirse hepsini kaybetmemek için.

4. Hesaplarında iki adımlı doğrulama, mümkünse anahtar ya da passkey

Ürünün sadece kodundan ibaret değil. Alan adı kayıt firması, e-posta, barındırma, ödeme sağlayıcısı ve GitHub hesabın da ürününün parçası. Bunlardan biri ele geçirilirse kod ne kadar iyi olursa olsun fark etmez.

Have I Been Pwned'in kurucusu güvenlik araştırmacısı Troy Hunt, Mart 2025'te kendisinin bir oltalama saldırısına düştüğünü açıkça yazdı. Yorgun ve jet lag'liyken sahte bir Mailchimp giriş sayfasına şifresini ve tek kullanımlık kodunu girdi. Saldırgan bu bilgileri anında gerçek siteye aktardı ve yaklaşık 16 bin kayıtlık e-posta listesini dışarı aktardı. Şifre yöneticisinin otomatik doldurmaması bir uyarıydı, ama Hunt bunu gözden kaçırdı.

Hunt'ın çıkardığı ders şu: SMS ya da uygulama kodu gibi tek kullanımlık kodlar iyidir ama bu tür canlı aktaran oltalama saldırılarında atlatılabilir. Passkey ya da donanım güvenlik anahtarı ise sadece gerçek alan adında çalıştığı için bu saldırıyı engeller. Hunt, özellikle alan adı kayıt firması gibi kritik hesaplar için bunu öneriyor.

Pratik sıra:

Bütün kritik hesaplarda iki adımlı doğrulamayı aç.
Destekleyenlerde passkey ya da güvenlik anahtarı ekle.
Kurtarma kodlarını şifre yöneticinde ya da çevrimdışı güvenli bir yerde sakla.
Şifre yöneticin bir sitede otomatik doldurmuyorsa, adres çubuğuna iki kez bak.

5. Kullanıcı girişi: kendin yazma

Kimlik doğrulamayı sıfırdan yazmak, OWASP'ın A07 başlığındaki hataların çoğuna kapı açar. Şifre saklama, oturum süresi, şifre sıfırlama bağlantılarının süresi ve deneme sınırı gibi ayrıntıların her biri ayrı bir risk. Solo kurucu için daha güvenli yol, kullandığın çatının ya da barındırma platformunun hazır kimlik doğrulamasını kullanmak ve ayarlarını gözden geçirmek.

Kontrol etmen gerekenler: giriş denemelerinde bir sınır var mı, şifre sıfırlama bağlantıları bir süre sonra geçersiz oluyor mu, yönetici paneline giriş ayrı bir yetkiyle mi korunuyor?

6. Bağımlılıklar: güncellemeyi rutin yap

OWASP 2025 listesinde tedarik zinciri hataları üçüncü sırada. Kullandığın her paket, kodunun bir parçası. Açığı bulunan eski bir sürümü aylarca güncellememek, kapıyı açık bırakmak gibi.

GitHub'ın Dependabot özelliği, deponda açığı bilinen bir bağımlılık tespit ettiğinde güncellemeyi yapan bir değişiklik isteğini otomatik açabiliyor. Bursa'da muhasebe bürolarına belge paylaşım aracı yapan bir kurucu düşün. Haftada bir 20 dakikasını bu güncellemeleri gözden geçirmeye ayırırsa, birikip korkutucu hâle gelmelerini önler.

Yeni paket eklerken de iki soru sor: Bu paket gerçekten gerekli mi? Bakımı yapılıyor mu?

Bu hafta yapılacak

Kod deponda gizli anahtar taraması yap ve .env dosyalarının .gitignore'da olduğunu doğrula.
Veritabanındaki her tabloyu listele ve her birinde erişim kuralı olduğunu kontrol et. Başka bir test hesabıyla kendi verine ulaşmayı dene.
Son yedeğini ayrı bir ortama geri yükle ve verinin yerinde olduğunu gör.
Alan adı, e-posta, barındırma, ödeme ve GitHub hesaplarında iki adımlı doğrulamayı aç, mümkünse passkey ekle.
Dependabot ya da benzeri bir bağımlılık uyarısını aç ve bekleyen güncellemeleri gözden geçir.

Sık sorulanlar

Henüz 10 kullanıcım var, bunlar şart mı?

Evet, çünkü otomatik tarayıcılar kullanıcı sayına bakmıyor. Bu listedeki adımların çoğu birkaç saatlik iş. Kullanıcı verisi tutmaya başladığın an bu adımları atmış olman gerekir.

Anahtarımı yanlışlıkla GitHub'a gönderdim, dosyayı silsem yeter mi?

Hayır. Anahtar git geçmişinde kalır ve birileri çoktan kopyalamış olabilir. OWASP'ın önerdiği sırayla önce anahtarı iptal et, sonra yenisini üret, sonra geçmişi temizle.

Herkese açık (anon) anahtarın tarayıcıda görünmesi sorun mu?

Supabase gibi servislerde bu anahtar zaten herkese açık olacak şekilde tasarlandı. Sorun, erişim kuralları olmadan kullanıldığında başlıyor. Asıl kontrol etmen gereken, her tablonun kuralı.

Güvenlik testini kime yaptırabilirim?

Kullanıcı verisi ya da ödeme bilgisi tutuyorsan, yayına almadan önce bu alanda deneyimli birine bakış attırmak iyi bir yatırım. Kişisel veri işliyorsan KVKK yükümlülüklerin için kvkk.gov.tr'deki resmi rehberlere bak ve bir hukukçuya danış. Bu yazı hukuki tavsiye değildir.

Dayanak

OWASP Top 10:2025 — OWASP: En yaygın web uygulaması riskleri ve 2025 sıralaması.
Secrets Management Cheat Sheet — OWASP: Anahtarları koddan ayırma, tarama, en az yetki ve sızıntı sonrası adımlar.
CISA Admin Leaked AWS GovCloud Keys on GitHub — Hacker News tartışması: Sızan anahtarlar, .env dosyaları ve kod asistanları üzerine yorumlar.
Unsecured MongoDBs taken hostage — Hacker News: İnternete açık, şifresiz veritabanlarının silinip fidye istenmesi.
Your Supabase is public if you turn off RLS — Skilldeliver: RLS kapalı tabloda açığa çıkan kullanıcı verisi ve öneriler.
Your Supabase is public if you turn off RLS — Hacker News tartışması: Supabase ve Firebase'de yanlış ayarlanan izinler üzerine yorumlar.
Postmortem of database outage of January 31 — GitLab: Silinen veri, çalışmayan yedekler ve yedek testinin sahipsiz kalması.
Postmortem of database outage of January 31 — Hacker News tartışması: GitLab olay raporu üzerine topluluk tartışması.
A Sneaky Phish Just Grabbed my Mailchimp Mailing List — Troy Hunt: Tek kullanımlık kodu aşan oltalama ve passkey önerisi.
About push protection — GitHub Docs: Herkese açık depolara gizli anahtar gönderimini engelleyen varsayılan koruma.
About Dependabot security updates — GitHub Docs: Açığı bilinen bağımlılıklar için otomatik güncelleme istekleri.