SaaS Güvenlik Kontrol Listesi: Yayından Önce Çalıştırdığımız 40 Kontrol (2026)

SaaS Güvenlik Kontrol Listesi: Yayından Önce Çalıştırdığımız 40 Kontrol (2026)

Bir SaaS güvenlik kontrol listesi, henüz sahip olmadığınız bir yığın uyumluluk rozetinden daha değerlidir. Rahatsız edici gerçek şu: çoğu yayın kontrol listesi neyi güvence altına almanız gerektiğini söyler, nasıl yapacağınızı hiç göstermez. Bu liste kodu da verir. Biz Next.js ve Supabase üzerine inşa ediyoruz; eksik tek bir tenant_id filtresinin bir test hesabına başka bir müşterinin verisini okutturduğunu gördük ve IBM'in 2024 Veri İhlali Maliyeti Raporu küresel ortalamayı $4.88M olarak belirledi. Yayına çıkmak için SOC 2'ye ihtiyacınız yok. Aşağıdaki, gruplanmış, çalıştırılabilir ve OWASP ile NIST'e eşlenmiş uygulama katmanı temeline ihtiyacınız var.

Öne Çıkan Noktalar

• Yayına çıkmak için SOC 2'ye ya da pentest'e ihtiyacınız yok. Aşağıdaki uygulama katmanı temeline ihtiyacınız var.
• En tehlikeli yayın hatası, eksik bir tenant_id kontrolünden kaynaklanan tenant'lar arası veri sızıntısıdır.
• Kendi auth'unuzu asla sıfırdan kurmayın. Auth.js, Clerk veya Supabase Auth kullanın.
• Dağıtım yapmadan önce NEXT_PUBLIC_ ön eklerini denetleyin. Bir secret'ı sızdırmanın en hızlı yolu bu.

Bu temel, OWASP ASVS 5.0 ile NIST Güvenli Yazılım Geliştirme Çerçevesi (SSDF)'ye eşlenir; Google'ın bu konuda en çok güvendiği iki kaynak ve dikkat çekici biçimde, en üst sıradaki rehberlerin hiçbirinin zahmet edip atıfta bulunmadığı iki kaynak.

Yayın Öncesi Güvenlik Kontrol Listeniz (Hızlı Sürüm)

Bunlar, yayına çıkmadan önce karşılamanız gereken asgari güvenlik gereksinimleridir; altı kategoriye ayrılmıştır. Kırk madde. Yukarıdan aşağıya çalıştırın, kod bölümlerini geliştiricinize verin ve aşağıdaki öncelik tablosunda P0 olarak işaretlenen her şeyi yayın engelleyici olarak ele alın.

Secrets ve Yapılandırma

1. .env, ilk commit'ten itibaren .gitignore içinde ve hiç commit edilmedi.
2. Her NEXT_PUBLIC_ ve VITE_ ön eki denetlendi; hiçbir gizli bilgi tarayıcıya gitmiyor.
3. Sunucu secret'ları repo'da değil bir yöneticide (platform env değişkenleri, AWS Secrets Manager, Vault) tutuluyor.
4. Git geçmişine bir kez bile değmiş her anahtar, yayından önce döndürüldü.
5. Loglarda, hata yanıtlarında veya istemci paketinde hiçbir secret görünmüyor.
6. Derlenen paketi canlı anahtarlar için grep'lediniz (grep -r "sk_live" .next/).

Auth ve Erişim

1. Auth, sıfırdan yazılmadı; bir kütüphane (Auth.js, Clerk veya Supabase Auth) üzerine kuruldu.
2. Hesaplarda MFA (çok faktörlü kimlik doğrulama) mevcut.
3. Oturum çerezleri Secure, HttpOnly ve SameSite ayarlarını taşıyor.
4. Hiçbir JWT ya da oturum token'ı localStorage'da saklanmıyor.
5. RBAC ve en az ayrıcalık ilkesine dayalı roller yalnızca arayüzde gizlenmiyor, sunucu tarafında uygulanıyor.
6. Şifreler Argon2 veya bcrypt ile hash'leniyor (yalnızca auth'u kendiniz yönetiyorsanız geçerli).
7. Şifre sıfırlama ve e-posta doğrulama akışları kötüye kullanıma karşı test edildi.

Veri ve Tenant Yönetimi

1. Her sorgu bir tenant_id filtresi taşıyor.
2. Tenant kapsamlaması her sorguda hatırlanmıyor; ORM ya da repository katmanında zorunlu kılınıyor.
3. Satır düzeyinde güvenlik (RLS) etkin ve başarısızlık senaryoları biliniyor.
4. Her nesne-ID endpoint'inde bir sahiplik kontrolü çalışıyor (bu IDOR'u ortadan kaldırır).
5. tenant_id, önbellek anahtarlarına ve nesne depolama yollarına dahil ediliyor.
6. Veriler hem bekleme hâlinde hem de aktarım sırasında şifreleniyor.
7. Ödeme ve webhook imzaları (Stripe vb.) sunucu tarafında doğrulanıyor.

Bağımlılıklar ve Tedarik Zinciri

1. npm audit veya pnpm audit, yüksek ve kritik bulgulardan temiz (ya da açıkça triyaj edilmiş).
2. Dependabot veya Renovate etkinleştirildi.
3. Snyk veya Socket, daha derin SCA'nın yanı sıra kötü amaçlı yazılım ve lisans kontrollerini çalıştırıyor.
4. Kilit dosyası (lockfile) commit edildi.
5. Kritik yol üzerinde terk edilmiş veya bakımsız hiçbir paket yok.
6. Docker kullanıyorsanız container imajları taranıyor.

Ağ ve Aktarım

1. HTTPS her yerde HSTS preload ile zorunlu kılınıyor.
2. Bir Content-Security-Policy ayarlandı (önce report-only, sonra zorunlu).
3. X-Content-Type-Options: nosniff ve X-Frame-Options/frame-ancestors ayarlandı.
4. Referrer-Policy ve Permissions-Policy ayarlandı.
5. CORS bir izin listesi kullanıyor; credentials ile asla * kullanılmıyor.
6. Hız sınırlama, auth ve maliyetli endpoint'leri koruyor.
7. Her endpoint, girdiyi bir şema ile doğruluyor (Zod veya benzeri).

İzleme ve Müdahale

1. Merkezi denetim günlükleri kimin neye ne zaman eriştiğini kaydediyor.
2. Hata yönetimi kullanıcılara asla stack trace sızdırmıyor.
3. Auth anormalliklerinde (başarısız giriş sıçramaları, imkânsız seyahat) uyarılar tetikleniyor.
4. Otomatik yedeklemeler çalışıyor ve bir geri yükleme testi yapıldı.
5. Bir olay müdahale kişisi ve tek sayfalık bir runbook mevcut.
6. Çalışma süresi ve hata izleme (Sentry veya benzeri) devrede.
7. Bir pentest'e ne zaman başvuracağınızı biliyorsunuz.

Önce Düzeltilecekler: Öncelik Sırası

Her madde yayını engellemez. Bu triyaj tablosu, temeli "atlanırsa verdiği zarara" göre sıralar; böylece bir kurucu neyin pazarlık konusu olmadığını bilir. P0 = yayından önce düzelt, P1 = ilk hafta düzelt, P2 = çeyrek içinde düzelt.

Secrets ve Yapılandırma: İstemci Paketinize Sızan Bir Anahtar Var mı?

Yayında secret hijyeni, hiçbir kimlik bilgisinin tarayıcıya ulaşmaması demektir. Next.js'teki NEXT_PUBLIC_ ön eki (ve Vite'daki VITE_) değeri her ziyaretçiye gönderir; bu yüzden tek bir yanlış ön ek bir anahtarı sızdırır. .env'i git'in dışında tutun, sunucu secret'larını bir yöneticiye koyun ve dağıtımdan önce derleme çıktınızı grep'leyin.

En sık gördüğümüz tuzak şu: NEXT_PUBLIC_ "herkese açık bilgi" anlamına gelmez. "Bunu kelimenin tam anlamıyla her ziyaretçinin tarayıcısına gönderiyorum" anlamına gelir. Bir Stripe secret'ını ya da bir service-role anahtarını bu şekilde önekleyin; DevTools'u açan herkes için pakette canlı hâle gelir.

# .env.local (hata)
NEXT_PUBLIC_STRIPE_SECRET=sk_live_51H...   # KÖTÜ: her tarayıcıya gider
STRIPE_SECRET_KEY=sk_live_51H...           # İYİ: yalnızca sunucu

# Herkese açık (paylaşılması güvenli) vs yalnızca sunucu
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ...       # anon anahtarın herkese açık olması amaçlanmıştır
SUPABASE_SERVICE_ROLE_KEY=eyJ...           # buna asla NEXT_PUBLIC_ eklemeyin

# Dağıtmadan önce sızmış bir anahtarı yakalayın
grep -r "sk_live" .next/    # herhangi bir eşleşme, istemci paketinizde bir secret olduğu anlamına gelir

Secret temelinin geri kalanı sıkıcı ve pazarlık konusu değil: ilk commit'ten itibaren .gitignore içinde .env, repo yerine bir yöneticide sunucu secret'ları ve git geçmişine bir kez bile değmiş her anahtarın döndürülmesi (bir commit'i silmek onu sızdırılmamış hâle getirmez). Sızmış bir dağıtım token'ı, tam olarak Vercel olayı gibi ihlallerin başladığı yerdir; bu yüzden her token'ı sanki birinin izleme listesindeymiş gibi ele alın.

Auth ve Erişim: Kendi Auth'unuzu mu Kurmalısınız, Kütüphane mi Kullanmalısınız?

Kendi auth'unuzu mu kurmalısınız yoksa bir kütüphane mi kullanmalısınız? Neredeyse her zaman bir kütüphane kullanın. Auth.js, Clerk ve Supabase Auth, aksi hâlde üretimde yeniden keşfedeceğiniz yılların uç durumlarını (oturum sabitleme, token iptali, sıfırlama akışı kötüye kullanımı) zaten çözmüş durumda. Kendi başınıza kurmak, yalnızca bir güvenlik mühendisiniz ve hiçbir sağlayıcının uymadığı bir nedeniniz varsa savunulabilir; bu da nadirdir.

Kendi auth'unuzu sıfırdan kurmak, ayda $25 tasarruf etmenin en pahalı yoludur. İşte dürüst seçeneklerin karşılaştırması.

Bir kütüphane seçip yapılandırmayı atlayan ekipleri batıran iki tuzak var. Birincisi, JWT iptali gerçekten zor; bu yüzden çalınan bir token süresi dolana kadar geçerli kalır. Token ömürlerini kısa tutun ve hassas her şey için sunucu taraflı oturumları tercih edin. İkincisi, localStorage'daki token'lar herhangi bir XSS payload'ı tarafından çalınabilir; bu yüzden oturumları Secure ve SameSite ile httpOnly çerezlerde saklayın. RBAC'ı arayüzde düğmeleri gizleyerek değil, sunucuda uygulayın.

SaaS'ınız bir yapay zeka ya da LLM özelliği sunuyorsa, model girdisini de güvenilmeyen bir auth sınırı olarak ele alın. Prompt injection'ı önleme rehberimize bakın; çünkü araç erişimi olan jailbreak edilmiş bir asistan, sohbet penceresi giymiş bir erişim kontrolü sorunudur.

Veri ve Tenant Yönetimi: Bir Tenant'ın Diğerinin Verisini Okumasını Nasıl Engellersiniz?

Tenant izolasyonu, her sorgunun, önbellek anahtarının ve depolama yolunun mevcut tenant'a kapsamlandığı anlamına gelir. Eksik bir tenant_id filtresi, bir müşterinin başka birinin verisini okumasına izin verir; bu, var olan en tehlikeli yayın hatasıdır. Satır düzeyinde güvenlik (RLS) yardımcı olur ama bir emniyet kemeridir, güç alanı değil; bu yüzden her nesne-ID endpoint'ine de sahiplik kontrolleri ekleyin.

Bu, hiçbir rakibin kod olarak ele almadığı bölüm ve tenant'lar arası sızıntıların üretime sızmasının nedeni tam olarak bu. Düzeltme, bir ID'ye tek başına asla güvenmemekle başlar. Her okumayı çağıranın tenant'ına kapsamlayın ve bunu veri katmanında zorunlu kılın ki kimse her sorguda bunu hatırlamak zorunda kalmasın.

// KÖTÜ: tenant kapsamı yok. Geçerli her id, herhangi bir tenant'ın satırını döndürür.
const order = await db.order.findFirst({ where: { id } });

// İYİ: her okumada çağıranın tenant'ına kapsamlanmış.
const order = await db.order.findFirst({
  where: { id, tenantId: session.tenantId },
});

İlgili hata IDOR'dur (güvensiz doğrudan nesne referansı); OWASP API Security Top 10 listesi bunu API1: Broken Object Level Authorization başlığı altına koyar. Bir test hesabı URL'deki bir ID'yi artırır ve asla görmemesi gereken bir kaydı okur. PortSwigger'ın Web Security Academy'si, saldırganların bunları nasıl bulduğuna dair tam bir anlatım sunuyor. Düzeltme tek bir sahiplik kontrolüdür.

// GET /api/invoices/1234, bir test hesabı id'yi artırır
// ve başka bir tenant'ın faturasını okur. Klasik BOLA.
const invoice = await db.invoice.findUnique({ where: { id } });

// Düzeltme: herhangi bir şey döndürmeden önce sahipliği doğrulayın.
if (invoice.tenantId !== session.tenantId) {
  return res.status(403).json({ error: "Forbidden" });
}

Sizi dürüst tutan çerçeve şu: her IDOR bir tenant izolasyonu hatasıdır ama her tenant izolasyonu hatası bir IDOR değildir. Postgres satır düzeyinde güvenliği bunların çoğunu veritabanında yakalar ama ona güvenmeden önce bilmeye değer sessiz başarısızlık senaryoları vardır.

-- Postgres RLS: bir emniyet kemeri, güç alanı değil.
alter table orders enable row level security;

create policy tenant_isolation on orders
  using (tenant_id = current_setting('app.tenant_id')::uuid);
-- Sessiz başarısızlık tuzağı: havuzlanmış bir bağlantıda app.tenant_id'yi
-- SET etmeyi unutun; politika ÖNCEKİ isteğin tenant'ını okur.

Bağlantı havuzu kirlenmesi, async-context sızıntıları ve paylaşılan önbellek zehirlenmesi hepsi RLS'yi sessizce alt eder; bu yüzden OWASP Multi-Tenant Security Cheat Sheet, önbellek anahtarlarını ve depolama yollarını da tenant ile öneklemenizi söyler. OWASP ASVS 5.0'un erişim kontrolü bölümü ve Supabase RLS dokümantasyonu, burada baştan sona okunmaya değer iki kaynaktır.

Bağımlılıklar ve Tedarik Zinciri: node_modules İçinde Neler Saklanıyor?

Uygulamanız yalnızca en zayıf geçişli bağımlılığı kadar güvenlidir. CI'da npm audit veya pnpm audit çalıştırın ve yayından önce yüksek ya da kritik bulgularda derlemeyi başarısız kılın. Otomatik güncellemeler için Dependabot veya Renovate, daha derin kötü amaçlı yazılım ve lisans kontrolleri için Snyk veya Socket ekleyin.

Tuzak, denetimi bir kez elle çalıştırıp yeşili görmek ve bir daha hiç çalıştırmamaktır. Bunu CI'a bağlayın ki dokunmadığınız bir pakette yeni bir CVE bile merge'i engellesin.

# .github/workflows/ci.yml: yüksek/kritik bulguda merge'i engelle
- name: Audit dependencies
  run: npm audit --audit-level=high    # sıfır olmayan çıkış kodu job'ı başarısız kılar

npm audit dokümantasyonu, önem seviyelerini ve yalnızca dev bulgularını yok saymak isterseniz --production bayrağını ele alır. Ancak otomatik tarama asgari koşuldur; bir bağımlılık tarayıcısının kaçırdığı kod kokularını ve enjeksiyon yollarını yakalayan daha derin statik analiz için SonarQube değerlendirmemize bakın. Kilit dosyanızı commit edin, yıllardır sürüm yayınlamamış paketleri bırakın ve Docker kullanıyorsanız container imajınızı tarayın.

Ağ ve Aktarım: Bir SaaS Gerçekte Hangi Güvenlik Header'lere İhtiyaç Duyar?

Bir SaaS hangi güvenlik header'lere ihtiyaç duyar? HTTPS artı HSTS ve kısa bir header seti, istismarı en kolay boşlukları kapatır. Bir Content-Security-Policy, joker karakter yerine bir CORS izin listesi ve auth ile maliyetli endpoint'lerde hız sınırları ekleyin. Kötü payload'ların iş mantığınıza asla ulaşmaması için her girdiyi Zod gibi bir şema ile doğrulayın.

Bugüne kadar icat edilmiş her header'a ihtiyacınız yok. Bu kısa listeye ihtiyacınız var ve MDN güvenlik-header'ları referansı her birini derinlemesine açıklıyor.

Header'ları edge'de bir kez ayarlayın ve bir script'in giriş rotanızı bütün gece brute-force edememesi için bir hız sınırlayıcı ekleyin.

// next.config.js: her yanıtta güvenlik header'ları
const securityHeaders = [
  { key: "Strict-Transport-Security", value: "max-age=63072000; includeSubDomains; preload" },
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "X-Frame-Options", value: "DENY" },
  { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
];
// Auth rotalarını hız sınırlayın (Upstash örneği)
const { success } = await ratelimit.limit(ip);
if (!success) return new Response("Too many requests", { status: 429 });

Kendi uygulamanızı bozmamak için CSP'nizi report-only ile başlatın, birkaç gün ihlal raporlarını izleyin, sonra zorunlu moda geçirin. CORS'u adlandırılmış bir izin listesiyle sınırlayın ve *'ı asla credentials ile eşleştirmeyin.

İzleme ve Müdahale: İhlale Uğradığınızı Nasıl Anlarsınız?

Göremediğiniz bir şeye müdahale edemezsiniz. Yayından önce merkezi denetim günlükleri, başarısız giriş sıçramaları gibi auth anormalliklerinde uyarılar, test edilmiş geri yüklemesi olan otomatik yedeklemeler ve tek sayfalık bir olay runbook'u kurun. Test edilmemiş bir yedek bir umuttur, yedek değil; runbook'u yazma zamanı şimdi, bir olayın ortasında değil.

IBM verileri, bir ihlali tespit edip kapsam altına almanın ortalama süresini 258 gün olarak veriyor; ve günlükleriniz kimin neye dokunduğunu kaydetmiyorsa bu sayıyı küçültemezsiniz. Onları merkezileştirin, önemli anormalliklerde (başarısız giriş sıçramaları, imkânsız seyahat girişleri, ani dışa aktarım hacmi) uyarın ve hata işleyicinizin, iç yapınızı ifşa eden bir stack trace yerine temiz bir mesaj döndürdüğünden emin olun.

Modern ihlal tespiti, statik kurallardan çok anomali izlemeye dayanır; bunun gerçekte nasıl çalıştığı hakkında daha fazlasını yapay zekanın veri ihlallerini nasıl önlediği yazımızda bulabilirsiniz. Çerçeve desteği için NIST SSDF (SP 800-218), müdahale-ve-izleme pratiklerini sade bir dille ortaya koyar. Bir geri yüklemeyi veritabanınız kaybolduktan sonra değil, yayından önce test edin.

Kendi Yayınlarımızı İncelerken Gerçekte Ne Buluyoruz?

Ekibimiz bir derleme üzerinde yayın öncesi güvenlik geçişi yaptığında, kendi ürünümüz olsun ya da bir müşterininki olsun, iki eksik her şeyden daha sık ortaya çıkıyor. Birincisi: bir NEXT_PUBLIC_ ön eki üzerinden tarayıcıya binen bir secret, genellikle birinin istemci taraflı bir çağrıyı çalıştırmak için önekleyerek eklediği üçüncü taraf bir API anahtarı. İkincisi: en az bir endpoint'in tenant_id kapsamının ya da sahiplik kontrolünün eksik olması.

Tenant kapsamı eksikliği korkutucu olandır çünkü uygulama gayet iyi görünür. Her sayfa yükleniyor. Hata yalnızca biri URL'deki bir ID'yi değiştirdiğinde ortaya çıkar. Bir incelemede, GET /api/orders/:id giriş yapmış herhangi bir kullanıcıya herhangi bir siparişi döndürüyordu; bir test hesabı, sayıyı artırarak başka bir tenant'ın siparişlerini okudu. Düzeltme iki satırdı: döndürmeden önce order.tenantId'yi session.tenantId ile karşılaştırmak.

Burada size uydurma bir yakalama oranı söylemeyeceğiz. Dürüst ve tekrarlanabilir olan şu: NEXT_PUBLIC_ sızıntısı ve eksik tenant kapsamı, neredeyse her ilk-geçiş incelemede bulduğumuz iki şey ve ikisi de nereye bakacağınızı bildiğinizde düzeltmesi ucuz. Kontrol listesinin bunları P0 olarak en öne koymasının nedeni tam olarak bu.

Bu geçişi yayın gününden önce sizin için bir ekibin yapmasını tercih ederseniz, yaptığımız iş tam olarak bu. Yayın öncesi güvenlik incelemesi alın →

Sıkça Sorulan Sorular

Bir SaaS güvenlik kontrol listesinde neler olmalı?

Altı kategori: secrets ve yapılandırma (anahtarları istemci paketinin dışında tutun), auth ve erişim (bir kütüphane kullanın, MFA ekleyin), veri ve tenant yönetimi (tenant_id kapsamlaması artı sahiplik kontrolleri), bağımlılıklar (CI'da npm audit), ağ ve aktarım (HTTPS, HSTS, CSP, hız sınırları) ve izleme ile müdahale (denetim günlükleri, test edilmiş yedekler, bir runbook).

SaaS'ım yayına çıkacak kadar güvenli mi?

P0 temeli tamamlandığında hazırsınız demektir: secret'lar istemci paketinin dışında, her sorguda tenant izolasyonu, bir kütüphane üzerinde auth, güvenlik header'larıyla HTTPS ve temiz bir bağımlılık taraması. Mükemmellik burada ölçüt değil. Temeli karşılayan, yayınlanmış ve izlenen bir uygulama, hiç yayınlanmayan "mükemmel" bir uygulamayı her zaman geçer.

Bir SaaS'ı yayınlamadan önce sızma testine ihtiyacım var mı?

Yasal olarak yayınlamak için gerekmez. Ödeme veya kişisel veri işliyorsanız, kurumsal alıcıları hedefliyorsanız ya da bir denetçi veya yatırımcı istiyorsa önceliklendirin. MVP aşamasında o çabayı önce uygulama katmanı temeline ve OWASP Top 10'a harcayın. Bariz IDOR ve header boşlukları zaten kapatıldığında bir pentest daha fazlasını bulur.

Bir SaaS'ı yayınlamak için SOC 2'ye ihtiyacım var mı?

Hayır. Geçen hafta yayınlanmış bir startup'tan hiçbir müşteri SOC 2 beklemez. Bu bir yayın kapısı değil, kurumsal satış anahtarıdır ve aylar sürer. Uygulama katmanı temeliyle yayınlayın, sonra gerçek bir kurumsal anlaşma bunu gerektirdiğinde, öncesinde değil, SOC 2 sürecine başlayın.

Kendi kimlik doğrulamamı mı kurmalıyım yoksa Auth.js, Clerk ya da Supabase Auth gibi bir kütüphane mi kullanmalıyım?

Neredeyse her zaman bir kütüphane kullanın. Auth.js, Clerk ve Supabase Auth, çoğu kendin-yap auth hatasına neden olan oturum, token ve sıfırlama akışı uç durumlarını zaten çözdü. Kendi başınıza kurmak yalnızca bir güvenlik mühendisiniz ve hiçbir sağlayıcının karşılamadığı katı bir gereksiniminiz varsa savunulabilir; bu da gerçekten nadirdir.

Secret'ları istemci paketimin dışında nasıl tutarım?

Her NEXT_PUBLIC_ ve VITE_ ön ekini denetleyin; çünkü bu ön eki taşıyan her şey tarayıcıya gider. .env'i ilk commit'ten itibaren git'in dışında tutun, sunucu secret'larını bir yöneticide saklayın ve sızmış bir anahtarı yakalamak için dağıtımdan önce derlenen paketinizi grep'leyin (grep -r "sk_live" .next/).

Çok tenant'lı bir SaaS'ta tenant verisini nasıl izole ederim?

Her sorguya bir tenant_id filtresi koyun ve bunu otomatik olması için ORM ya da repository katmanında zorunlu kılın. Satır düzeyinde güvenliği etkinleştirin ve başarısızlık senaryolarını (havuz kirlenmesi, async sızıntıları) öğrenin. IDOR'u kapatmak için her nesne-ID endpoint'ine bir sahiplik kontrolü ekleyin ve önbellek anahtarlarını, depolama yollarını tenant'a göre kapsamlayın.

Bir SaaS yayından önce hangi güvenlik header'lere ihtiyaç duyar?

En az: Strict-Transport-Security (HSTS), bir Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options ya da frame-ancestors, Referrer-Policy ve Permissions-Policy. CSP'nizi report-only ile başlatın, ihlalleri gözden geçirin, sonra zorunlu kılın. MDN güvenlik-header'ları dokümantasyonu her biri için önerilen değerleri listeler ve yukarıdaki header tablosu her birinin neyi engellediğini özetler.

npm audit veya Snyk gibi otomatik tarama yeterli mi?

Gerekli ama yeterli değil. npm audit, Snyk ve Socket gibi araçlar bilinen CVE'leri ve kötü amaçlı paketleri yakalar ama IDOR ya da eksik bir tenant kapsamı gibi iş mantığı ve erişim kontrolü hatalarını bulamaz. Bunlar bir insan, bir test hesabı ve açık bir sahiplik kontrolü gerektirir. İkisini de çalıştırın: tarayıcıyı ve elle bir geçişi.

Özetle: Gerçekten Yayınlayabileceğiniz Bir SaaS Güvenlik Kontrol Listesi

Yayınlamak için mükemmel olmanıza gerek yok. Temele ihtiyacınız var. Önce P0 maddelerini kapatın: secret'lar paketin dışında, her sorguda tenant izolasyonu, her nesne endpoint'inde bir sahiplik kontrolü, bir kütüphane üzerinde auth ve header'larla HTTPS. Cuma günkü yayından önce tek bir şeyi düzeltecekseniz, bunu tenant izolasyonu yapın; çünkü sıfır uyarıyla bir müşterinin verisini sızdıran hata bu.

Buradaki her şey bugün çalıştırılabilir ve hiçbiri bir uyumluluk bütçesi gerektirmez. 40 kontrolü baştan sona işleyin, kod bölümlerini geliştiricinize verin ve yayınlayın. Yayına çıkmadan önce ikinci bir göz ister misiniz? Ücretsiz danışmanlık alın ve listeyi sizinle birlikte gözden geçirelim.