// docs / security guides / pre-launch SaaS

SaaS lansman öncesi güvenlik kontrol listesi: 35+ madde

Cursor, Claude Code, Lovable veya Bolt ile oluşturulmuş bir SaaS ürününü piyasaya sürmenize günler kaldı. Bu kontrol listesi, AI araçlarının sürekli gözden kaçırdığı ve hızlı teslimat yapan kurucuların müşteri parasını almadan önce ele alması gereken güvenlik yüzeylerini kapsayan bir go/no-go denetimidir. Sekiz bölüm, 35'ten fazla öğe, her biri 30-90 dakika içinde çözülebilir. Yazdırın, üstünü çizin ve güvenle dağıtın.

Aşağıdaki her öğe önemlidir. Yeşil, sevk edildiği ve doğrulandığı anlamına gelir; kırmızı, çözülmemiş ve başlatmanın engellendiği anlamına gelir. Kod parçacıkları ve gerçek hata modelleri ile her kategorinin daha uzun bir açıklaması için bkz. How to secure an app built with AI coding tools ve The vibe coding security checklist.

Müşteri verileri izolasyonu

Çok kiracılı bir SaaS'ta ilk güvenlik sınırınız veri yalıtımıdır. Her müşterinin verileri, uygulama katmanında değil, veritabanı katmanında zorunlu kılınan diğer tüm müşteriler tarafından erişilemez olmalıdır.

ALTER TABLE public.table_name ENABLE ROW LEVEL SECURITY; ALTER TABLE public.table_name FORCE ROW LEVEL SECURITY; ile her Supabase tablosunda Satır Düzeyinde Güvenliği (RLS) etkinleştirin. FORCE tablo sahibinin tabloyu atlamasını engeller.
Her RLS ilkesi için, yüklem kapsamlarını kimliği doğrulanmış kullanıcı veya kuruluşa doğrulayın. Örnek: CREATE POLICY "users_see_own" ON public.items FOR SELECT USING (auth.uid() = user_id);. Verilerin yalıtılmış durumda kaldığını doğrulamak için ikinci bir kullanıcı hesabıyla test yapın.
Firebase / Firestore kullanılıyorsa kuralların kiracı modelinizle eşleşmesi gerekir. allow read, write: if true; veya zamana bağlı test kurallarını kullanmayın. allow read, write: if request.auth.uid == resource.data.owner_uid; veya eşdeğer kuruluş kapsamlı eşleştirmeyi kullanın.
Dosya erişimi için imzalı URL'ler veya kısa ömürlü belirteçler kullanın; herkese açık paketler kullanmayın. Supabase Depolama: objects tablosunda ENABLE ROW LEVEL SECURITY'yi ayarlayın ve dosya erişimini kimliği doğrulanmış kullanıcıya kadar belirleyen politikalar yazın. İndirmeleri farklı kullanıcılar olarak test edin.
API katmanınızda her isteğin auth.uid() veya kuruluş kimliği bağlamını içermesi gerekir. Her veritabanı sorgusu bu bağlama göre filtrelemelidir. Örnek: hayır SELECT * FROM items WHERE id = $1; her zaman SELECT * FROM items WHERE id = $1 AND user_id = auth.uid().

Faturalandırma ve ödeme

Stripe entegrasyonu, müşteri güveninin finansal güvenlikle buluştuğu yerdir. Buradaki yanlış yapılandırma, çalınan ödemeler, geri ödeme döngüleri veya eksik gelir anlamına gelir.

Üretimde live Stripe keys kullanın. Aşamalandırmada ayrı bir test modu anahtarıyla test edin. Son canlı mod taraması olmadan asla testten canlıya geçiş yapmayın.
Her gelen etkinlikte webhook imzasını doğrulayın: const event = stripe.webhooks.constructEvent(req.body, sig, webhookSecret);. İmza başarısız olursa atın. Webhook sırrını yalnızca bir ortam değişkeninde saklayın, asla kodda saklayın.
event.id tarafından anahtarlanan bir veritabanı tablosu kullanarak web kancası işleyicilerinde bağımsızlığı uygulayın. Aynı webhook iki kez gelirse (ki gelecektir), ikinci çalıştırma işlem yapılmaz. İdempotency satırını durum değişikliğiyle aynı işlemde yazın.
customer.subscription.updated ve customer.subscription.deleted'de erişimi derhal iptal edin. Bir cron beklemeyin. Stripe Dashboard'da bir aboneliği iptal ederek ve kullanıcının 5 saniye içinde kilitlendiğini doğrulayarak test edin.
Veritabanınızda yalnızca Stripe müşteri ID ve aboneliği ID saklayın; kartın tamamını veya API anahtarını asla saklayın. Her kimlik doğrulama sınırında Stripe adresinden canlı abonelik durumunu alın (sayfa yükleme, API çağrı, cron kontrolü). Abonelik durumunu 1 dakikadan uzun süre önbelleğe almayın.

Kimlik doğrulama ve oturumlar

Auth, SaaS'ta ikinci dereceden saldırgan hedefidir. Kullanıcı hesabı, verilere ve ödeme yöntemlerine yönelik bir vektördür.

Korunan her rotada supabase.auth.getUser() kullanın, asla getSession() kullanmayın. getSession() doğrulanmamış bir çerezi okur; getUser(), JWT sunucu tarafını doğrular. Next.js içinde: const { data: { user } } = await supabase.auth.getUser(); korumalı içeriği sunmadan önce.
Kimlik doğrulama çerezlerinde SameSite=Lax ayarlayın (Supabase Kimlik doğrulama bunu varsayılan olarak yapar). DevTools → Uygulama → Çerezler'de doğrulayın. SameSite=None görürseniz, oturum yapılandırmanıza sameSite: 'Lax' ekleyin.
Kendi yönetici hesabınızda MFA özelliğini etkinleştirin. Kullanıcıya yönelik MFA için, lansmandan önce uçtan uca test edin: kaydolun, bir TOTP cihazını kaydedin, oturumu kapatın, TOTP belirteciyle tekrar oturum açın, çalıştığını doğrulayın.
Magic-link belirteçlerinin geçerliliğinin 15 dakika içinde sona ermesi gerekir. Parola sıfırlama belirteçlerinin geçerliliğinin 1 saat içinde sona ermesi gerekir. Oturum belirteçleri (JWTs) daha uzun süre dayanabilir (24 saat-7 gün) ancak her kullanımda doğrulanmaları gerekir. Kimlik doğrulama sağlayıcınızın varsayılanlarını kontrol edin.
Oturum kapatmanın tamlığını test edin: Kullanıcı oturum kapatmayı tıkladıktan sonra tarayıcı kimlik doğrulama oturumunu siler, sunucu tüm belirteçleri iptal eder ve kullanıcı korumalı sayfalara erişemez. Supabase'da: await supabase.auth.signOut()'yi arayın ve bir sonraki istekte JWT'nin artık geçerli olmadığını doğrulayın.

PII ve uyumluluk

E-posta, ad, ödeme bilgileri veya herhangi bir PII topluyorsanız yasal yükümlülükleriniz vardır: veri minimizasyonu, güvenli depolama, talep üzerine silme ve DPA hazırlığı.

Bir gizlilik politikası yazın ve yayınlayın (bağımsız SaaS için bile isteğe bağlı değildir). Hangi verileri, neden topladığınızı, ne kadar süreyle sakladığınızı ve kullanıcı haklarını (erişim, düzeltme, silme) belirtin. Termly veya benzeri bir şablon kullanın ancak özelleştirin.
Veritabanından PII temizleyen bir hesap silme API uç noktası uygulayın. Test edin: bir hesap oluşturun, veri ekleyin, hesabı silin, verilerin kaybolduğunu doğrulayın (doğrudan veritabanı incelemesini kullanın).
GDPR / CCPA uyumluluğu için, veri sahibinin taleplerine (erişim / düzeltme / silme) 30 gün içinde yanıt verin. Sürecinizi belgeleyin. Uygulamanız EU-tabanlıysa veya EU kullanıcılarına hizmet veriyorsa, Stripe, Supabase ve herhangi bir işlemciyi içeren bir Processing Eki (DPA) gereklidir.
Kullanımda olmayan hassas alanları şifreleyin (şifreler kimlik doğrulama sağlayıcınız tarafından karma hale getirilir; ancak kredi kartı şifrelemesi, API anahtarları, sırlar pgcrypto veya harici bir kasa kullanmalıdır). Hiçbir zaman düz metin kredi kartı numaralarını saklamayın (bunun yerine Stripe simgeleştirmeyi kullanın).

Operasyonel hazırlık

Güvenlik süreklidir. Olay müdahalesi, izleme ve runbook'lar birinci günden önce başlar.

Bir durum sayfası oluşturun (Statuspage.io, Uptime Robot veya basit bir index.html). Müşterilerin bir kesinti yaşayıp yaşamadığınızı bilmesi gerekir. Her olayda güncelleyin.
Çağrı üzerine rotasyonun belgelenmesini ve test edilmesini sağlayın. Kim sabahın 2'sinde alarmla uyanır? Dağıtım anahtarları kimde? Güvenliği ihlal edilmiş bir jetonu kim iptal edebilir? Bunu belgeleyin ve fırlatmadan önce bir yangın tatbikatı yapın.
Bir güvenlik olayı müdahale runbook'u yazın: Bir müşteri bir ihlal bildirdiğinde, bir anahtarı kaybederseniz veya bir hizmet arızalanırsa ne yapmalısınız? Ekibinize dağıtın. Planın işe yaradığını doğrulamak için bir senaryoyu (e.g., önemli bir sızıntıyı simüle edin) test edin.
Yedekleme ve geri yükleme prosedürleri teorik değil test edilmelidir. Yedeklerden geri yükleme yapabilir misiniz? Zaman ayır. Supabase: otomatik yedeklemeleri etkinleştirin (ücretsiz olarak 7 günlük saklama, ücretli olarak 30 gün saklama). Üç ayda bir ayrı bir projeye geri yükleme işlemini test edin.
Ayrıcalıklı işlemler için denetim günlüğünü etkinleştirin: Stripe kontrol paneli oturum açma işlemleri, Supabase yönetici API çağrıları, veritabanı şeması değişiklikleri, ödeme mutabakatı. Araçlar: CloudTrail (AWS), Supabase denetim günlükleri, PostgreSQL pgaudit uzantısı.

Dış saldırı yüzeyi

API sınırınız sürekli saldırgan taraması altındadır. Kötü amaçlı trafik gelmeden önce onu kilitleyin.

Her genel uç noktaya hız sınırı koyun. Örnek: Kayıt sırasında IP başına dakikada 100 istek, şifre sıfırlamada dakikada 10 istek. Vercel KV, Redis veya benzerlerini kullanın. 429 (Çok Fazla İstek) ile başarısız olun.
Kaydolmak için CAPTCHA (hCaptcha veya reCAPTCHA) ekleyin ve botları alt etmek için uç noktaların şifresini sıfırlayın. İsteği kabul etmeden önce belirtecin sunucu tarafını doğrulayın.
Varsa bir WAF (Web Uygulaması Güvenlik Duvarı) kullanın: Cloudflare, Vercel Web Uygulaması Güvenlik Duvarı veya AWS WAF. Bilinen kötü amaçlı IP'leri ve kalıpları otomatik olarak engelleyin.
Açık API uç noktalarını tarayın. Üretim alanınızda aylık olarak pasif bir FixVibe taraması yapın. Açığa çıkan hata ayıklama yolları, GraphQL iç gözlem, API anahtar sızıntısı veya yapılandırmanın açığa çıkmasıyla ilgili bulguları inceleyin.
Kimlik bilgilerini (API anahtarları, OAuth belirteçleri, veritabanı şifrelerini) üç ayda bir değiştirin. Rotasyon prosedürünü belgeleyin ve mümkün olduğunda otomatikleştirin.

Gözlemlenebilirlik ve günlük kaydı

İşler ters gittiğinde, günlükler sizin adli kayıtlarınızdır. Bunları ilk günden itibaren ayarlayın.

Günlükleri merkezileştirin: Supabase Günlükler, Vercel Günlükler, uygulama günlükleri ve kimlik doğrulama günlükleri tek bir kontrol panelinde (Datadog, LogRocket veya kendi kendine barındırılan ELK). Aranabilir, en az 90 gün boyunca saklanır.
Güvenlik olayları hakkında uyarı: tekrarlanan başarısız oturum açma işlemleri (olası hesap ele geçirme), olağandışı API kullanımı (olası kazıma), hata artışları (olası saldırı veya meşru olay). Eşikleri ve Slack entegrasyonlarını ayarlayın.
Her ayrıcalıklı işlem için denetim günlükleri yayınlayın: kullanıcı rolü değişiklikleri, yeni yönetici hesabı oluşturma, ödeme yöntemi eklemeleri, API anahtarlarındaki kapsam değişiklikleri. Bunları değişmez saklama özelliğiyle uygulama günlüklerinden ayrı olarak saklayın.

Son doğrulama

Duyurmadan önce tam bir FixVibe taraması yapın ve bulguları bir güvenlik gözüyle inceleyin.

Üretim alanınızda FixVibe Pro aktif tarama çalıştırın. Etkin test için alanınızı yapılandırın (DNS TXT veya HTTP dosya doğrulaması). Taramaya izin verin ve her bulguyu (özellikle kritik ve yüksek önem derecesine sahip) gözden geçirin. Her birini açıkça düzeltin veya kabul edin.
Planlanmış yeniden taramaları etkinleştirin: Pro plan → 3 saat, 6 saat, 12 saat veya günlük. Unlimited plan → 6 saat, 12 saat, günlük, 2 günde bir veya haftalık. Doğrulanmış alan adınızda active IDOR walking, SQL injection ve reflected XSS onaylarıyla eşleştirin.
Web kancalarını yapılandırın: FixVibe'yi Slack'e bağlayın veya e-postayla gönderin, böylece kritik bulgular gerçek zamanlı olarak uyarıları tetikler. Kurulum için /docs/webhooks adresine bakın.
/docs/security-guides/ai-generated-code-security-scanner'deki önemli noktalara odaklanan son bir manuel kod incelemesi yapın: paketlerdeki sırlar, RLS/rules, kimlik doğrulama sınırları, CSP, ara yazılım yerleşimi. İnceleme şablonu olarak vibe coding security checklist kullanın.

Lansman günü

Kontrol listesini temizlediniz. Güvenle dağıtın. Başlattıktan sonra aktif olarak izleyin: ilk hafta boyunca her gün FixVibe bulgularını kontrol edin, uyarılara 1 saat içinde yanıt verin ve tarama programını çalışır durumda tutun. Kod parçacıkları içeren adım adım sağlamlaştırma kılavuzu için bkz. How to secure an app built with AI coding tools.