Browser tarafından görülebilir; secret koymayın

Netlify güvenli mi? Platform; yönetilen HTTPS, ağ seviyesinde DDoS azaltma, erişim rolleri, secret kontrolleri, rate limiting ve çeşitli güvenlik sertifikaları sunuyor. Ancak bu özellikler, Netlify üzerinde çalışan her uygulamanın otomatik olarak güvenli olduğu anlamına gelmez. Kimlik doğrulama, uygulama kodu, veri sınıflandırması, cache politikası, environment variables, form verisi ve Deploy Preview erişimi hâlâ proje sahibinin sorumluluğundadır.

Doğru değerlendirme “güvenli” veya “güvensiz” etiketi koymak değil, paylaşılan sorumluluk modelini gerçek iş yüküne uygulamaktır. Bir statik portföyün riskleri ile sağlık verisi işleyen, üçüncü taraf API’lere bağlanan bir uygulamanın gereksinimleri aynı değildir.

Öne Çıkanlar

• Netlify, deploy edilen domain’ler için yönetilen HTTPS sertifikaları sağlayabilir ve ağ trafiğinde en az TLS 1.2 kullandığını belirtir.
• Platform, Layer 3/4 ve Layer 7 DDoS azaltma kontrolleri sunduğunu açıklar; uygulama düzeyinde rate limit yine ayrıca tasarlanmalıdır.
• Yeni kredi tabanlı projeler private başlayabilir, ancak production ve non-production görünürlüğü ayrı ayrı kontrol edilmelidir.
• Environment variable’ın browser bundle’ına eklenmesi, değeri secret olmaktan çıkarır.
• Deploy Preview URL’si, tahmin edilmesi zor olduğu için güvenli kabul edilmemelidir.
• AI Gateway prompt ve çıktıları varsayılan akışta saklamadığını belirtir; Agent Runner oturum logları ise görüntüleme ve audit amacıyla tutulur.
• Sertifika veya platform compliance’ı, müşterinin kendi uygulamasına otomatik olarak aynı kapsamı kazandırmaz.

Netlify Güvenliği Hangi Katmanlardan Oluşur?

Netlify güvenli mi sorusunu yanıtlamak için dört katmanı ayırmak gerekir:

1. Platform ve ağ: Edge ağı, DDoS azaltma, altyapı yamaları, şifreleme ve servis operasyonu. 2. Hesap ve ekip: 2FA, roller, repository izinleri, audit bilgisi ve proje erişimi. 3. Deploy ve çalışma zamanı: Build zinciri, Functions, Edge Functions, cache, environment variables ve preview ortamları. 4. Uygulama ve veri: Authentication, authorization, input validation, PII, business logic, üçüncü taraf servisler ve incident response.

Netlify, altyapı şifrelemesi, ağ güvenliği, altyapı vulnerability yönetimi ve denetim gibi alanları kendi sorumluluğu olarak tanımlar. Uygulama mimarisi, veri işleme, authentication ve yanlış cache nedeniyle özel verinin paylaşılması gibi riskler müşteriye aittir.

Bu ayrım önemlidir. Örneğin Netlify TLS sertifikasını doğru biçimde sağlayabilir; fakat uygulamadaki bir Function, yetki kontrolü yapmadan müşteri kaydı döndürüyorsa bağlantının şifreli olması veri ihlalini engellemez.

HTTPS ve SSL Nasıl Sağlanır?

Netlify, deploy edilen alan adlarında Let’s Encrypt üzerinden ücretsiz HTTPS sertifikası sağlayabilir; uygun plan ve yapılandırmalarda özel sertifika yükleme seçenekleri de bulunur. Platformun güvenlik sayfası ağ trafiğinde en az TLS 1. 2 ve altyapıdaki hassas veriler için aktarımda ve saklamada şifreleme kullandığını bildirir.

Özel domain bağlandıktan sonra şu kontroller yapılmalıdır:

• Sertifika doğru domain ve alt alan adlarını kapsıyor mu?
• HTTP istekleri HTTPS’e yönleniyor mu?
• Sayfada HTTP üzerinden yüklenen mixed content var mı?
• Eski veya yanlış DNS kaydı başka bir hedefe gidiyor mu?
• CAA kaydı sertifika üretimini engelliyor mu?
• HSTS kullanılacaksa alt domain ve preload etkileri anlaşıldı mı?

Basit bir header kontrolü:

``bash curl -I https://example.com/ ``

TLS ayrıntıları için OpenSSL kullanılabilir:

``bash openssl s_client -connect example.com:443 -servername example.com ``

Bu komutların çıktısı tek başına tam güvenlik testi değildir. Sertifika zinciri, son kullanma tarihi, protokol desteği ve redirect davranışı ayrı incelenmelidir. Üçüncü taraf güvenlik tarayıcılarına hassas veya henüz public olmaması gereken domain göndermeden önce veri politikasını kontrol edin.

DDoS ve Edge Seviyesinde Koruma Hakkında Ne Bilinir?

Netlify, trafik anomalilerini ve ani artışları izlediğini; Layer 3/4 TCP tabanlı saldırılar ile Layer 7 DDoS saldırıları için azaltma mekanizmaları kullandığını belirtiyor. Platform ayrıca WAF, firewall traffic rules ve rate limiting gibi ürünler sunuyor; bunların kapsamı plan ve yapılandırmaya göre farklılaşabilir.

Bu koruma, uygulama seviyesinde sınırsız güvence değildir. Aşağıdaki durumlar ayrıca ele alınmalıdır:

• Pahalı bir AI endpoint’ine çok sayıda geçerli görünümlü istek,
• Login veya şifre sıfırlama akışına credential stuffing,
• Form endpoint’ine spam,
• Function’ın dış API’yi her istekte tekrar çağırması,
• Büyük dosya indirme URL’sinin kötüye kullanılması,
• Cache bypass eden sorgu parametreleri.

DDoS azaltma servisi siteyi ayakta tutsa bile kullanım kredileri, üçüncü taraf API faturası veya uygulama verisi etkilenebilir. Uygulama düzeyinde kullanıcı/IP/anahtar temelli rate limit, maliyet üst sınırı, timeout ve circuit breaker tasarlayın. Gerçek kullanıcıları engellememek için limit kararını erişim modeli ve trafik dağılımıyla test edin.

Team Rolleri ve Erişim Sınırları Nasıl Yönetilir?

En sık güvenlik açığı platformun kriptografisinden değil, gereğinden fazla yetkiden çıkar. Netlify team üyelerini ve Git provider erişimlerini minimum yetki ilkesiyle yönetin.

Temel kontroller:

• Her kullanıcı kendi hesabını kullansın; ortak şifre paylaşılmasın.
• Tüm yetkili hesaplarda 2FA etkinleştirilsin.
• Ayrılan çalışan veya yüklenicinin Netlify ve Git erişimi aynı gün kapatılsın.
• Owner rolü yalnız faturalandırma ve team yönetimi gerçekten gereken kişilere verilsin.
• Public ve private repository yetkileri ayrı incelensin.
• Personal access token’lar süreli, dar kapsamlı ve isimlendirilmiş olsun.
• Production deploy yetkisi ile yalnız preview inceleme yetkisi ayrıştırılsın.

Plan tablosunda bazı gelişmiş rol, audit, SSO, SCIM ve project-level access seçenekleri Enterprise veya belirli planlarla sınırlı olabilir. “Netlify access control var” demek yerine satın alacağınız planda tam olarak hangi rolün hangi işlemi yapabildiğini doğrulayın.

GitHub bağlantısı da threat model’in parçasıdır. Netlify GitHub App’e yalnız gerekli repository erişimini verin. Organizasyonun tamamını açmak kolay olabilir; ancak ele geçirilen entegrasyonun etki alanını genişletir.

Environment Variables ve Secrets Nasıl Saklanmalıdır?

Environment variable, bir değeri Git deposundan ayırmak için yararlıdır; tek başına secret olma garantisi vermez. Değerin nerede kullanıldığı belirleyicidir.

Client ve server ayrımı

Vite’ta VITE_ önekli değişkenler client bundle’a dahil edilir. Next. js’te NEXT_PUBLIC_ benzer biçimde browser’a açılır. Bu değerler API’nin public tanımlayıcısı olabilir; private key, database password veya servis hesabı token’ı olmamalıdır.

```env

Browser tarafından görülebilir; secret koymayın

VITE_PUBLIC_ANALYTICS_ID=public-value

Yalnız server-side Function/SSR kodunda kullanılmalı

PAYMENT_PROVIDER_SECRET=dummy-example ```

Build sırasında private değişkeni yanlışlıkla statik HTML veya JavaScript içine yazarsanız dashboard’da secret olarak saklanmış olması sonucu değiştirmez. Üretilen deploy dosyalarını ve source map’leri tarayın.

Scope ve context

Secret’ı yalnız gereken scope’a açın: build, Functions, runtime veya belirli deploy context. Production anahtarını Deploy Preview’da kullanmak, dış katkıcının açtığı pull request’in canlı servise erişmesine yol açabilir. Preview için sandbox hesabı veya düşük yetkili ayrı credential tercih edin.

Rotation ve sızıntı müdahalesi

Secret Git geçmişine girdiyse dosyayı silmek yeterli değildir. Anahtarı sağlayıcı tarafında iptal edin, yenisini üretin, logları inceleyin ve Git geçmişini uygun biçimde temizleyin. Smart secret detection faydalı bir kontrol olabilir; tüm gizli değer formatlarını yakalama garantisi yoktur.

Deploy Previews Hangi Riskleri Taşır?

Deploy Preview, pull request değişikliğini production’dan önce göstermesi nedeniyle güvenliği güçlendirebilir. Aynı zamanda geçici ortamların unutulması, yanlış secret kullanımı ve public erişim nedeniyle yeni risk yüzeyi oluşturur.

Şu varsayımlardan kaçının:

• “URL uzun, kimse bulamaz.”
• “Preview olduğu için arama motorları kesinlikle görmez.”
• “Production veritabanına bağlansa da yalnız ekip kullanır.”
• “Pull request açan kodu build etmek her zaman güvenlidir.”

Preview görünürlüğünü team login, password veya planın sunduğu erişim politikalarıyla yönetin. Production ve non-production erişiminin farklı ayarlanabildiğini kontrol edin. Dış katkıcının pull request’i build sırasında çalışıyorsa dependency script’leri ve build loglarında secret sızıntısı riskini ayrıca değerlendirin.

Preview ortamına ideal olarak şunlar verilmelidir:

• Production’dan ayrı test verisi,
• Sandbox API anahtarları,
• Gerçek e-posta göndermeyen veya allowlist kullanan servis,
• Gerçek ödeme almayan test modu,
• Kısa saklama süresi,
• Açık owner ve silme/retention politikası.

Form Verilerinde Riskler Nelerdir?

Netlify Forms ayrı backend yazmadan submission almayı kolaylaştırabilir. Fakat ad, e-posta, telefon, sağlık bilgisi veya dosya yüklemesi PII olabilir. Formu kuran ekip şu kararları vermelidir:

• Hangi alan gerçekten gerekli?
• Kullanıcıya amaç ve saklama süresi açıklandı mı?
• Dashboard’a kim erişebilir?
• Bildirim e-postasında hassas veri taşınacak mı?
• Submission ne zaman silinecek?
• Spam ve otomatik kötüye kullanım nasıl sınırlandırılacak?
• Dosya yüklemesi malware ve yetkisiz erişim açısından nasıl ele alınacak?

Form submission’ın plan içinde ücretsiz olması, sınırsız kişisel veri toplanmasının doğru olduğu anlamına gelmez. Veri minimizasyonu uygulayın ve hassas iş yükünde hukuk/güvenlik ekipleriyle gerçek gereksinimi doğrulayın.

AI Gateway ve Agent Runners İçin Veri Güvenliği

Netlify’nin 6 Ağustos 2026 güncellemeli AI güvenlik dokümanı, Netlify üzerinden kullanılan üçüncü taraf sağlayıcıların gelen girdilerle model eğitmesine izin verilmediğini belirtiyor. Ancak bu ifade, hiçbir verinin hiçbir yerde işlenmediği anlamına gelmez; inference için veri seçilen sağlayıcıya yönlendirilir.

AI Gateway varsayılan olarak prompt veya model çıktısını saklamadığını; içerik taşımayan request metadata’sı tuttuğunu ve müşteri talebiyle gelişmiş logging açılabildiğini açıklar. Agent Runners ise kod agent’ı oturum loglarını kullanıcıya göstermek, troubleshooting ve audit amacıyla CI sistemindeki politikalara göre kaydeder.

Bu nedenle:

• Prompt’a gereksiz PII veya secret eklemeyin.
• Kullanılan provider ve modelin güncel veri politikasını inceleyin.
• Enhanced logging açıksa kapsamını doğrulayın.
• Agent’ın erişebildiği repository, environment variables ve araçları sınırlayın.
• Kod değişikliğini merge öncesi insan tarafından inceleyin.
• Model çıktısını güvenlik kararı veya yetkilendirme kanıtı olarak kabul etmeyin.

AI özellikleri team düzeyinde kapatılabilir. Enterprise’ta varsayılan davranış diğer planlardan farklı olabilir; dashboard ve sözleşme ayarı kontrol edilmelidir.

Güvenlik Başlıkları Nasıl Eklenir?

Statik sayfa ve uygulama yanıtlarına uygun HTTP security header’ları eklemek saldırı yüzeyini azaltabilir. Örnek netlify. toml başlangıcı:

``toml [[headers]] for = "/*" [headers.values] X-Content-Type-Options = "nosniff" Referrer-Policy = "strict-origin-when-cross-origin" Permissions-Policy = "camera=(), microphone=(), geolocation=()" ``

Content Security Policy daha güçlü ama uygulamaya özeldir. Kopyala-yapıştır sert bir CSP analytics, font, image veya framework script’lerini kırabilir; çok gevşek politika ise anlamlı koruma sağlamaz. Önce Content-Security-Policy-Report-Only ile gözlemleyip gerçek kaynak allowlist’i çıkarın.

HSTS de dikkatli uygulanmalıdır. Alt domain’leri ve preload’u anlamadan uzun max-age kullanmak geri dönüşü zor erişim sorunları yaratabilir. Her header’ı threat model ve test ortamıyla doğrulayın.

Production Öncesi Güvenlik Kontrol Listesi

Alan	Kontrol	Sorumlu
Hesap	2FA, owner sayısı, ayrılan kullanıcılar	Team owner
Git	App izinleri ve branch protection	Repository admin
Domain	HTTPS, DNS, certificate, mixed content	Platform/DNS owner
Secret	Scope, context, rotation, client bundle taraması	Developer/Security
Preview	Visibility, test data, sandbox keys	Tech lead/QA
Function	Auth, input validation, timeout, rate limit	Backend owner
Form	Veri minimizasyonu, spam, retention	Product/Legal
Cache	Private yanıtların public cache’e girmemesi	Developer
AI	Provider, logging, PII, human review	AI feature owner
Incident	Log erişimi, contact tree, rollback ve key revoke	Incident owner

> Editör notu — zorunlu güvenlik testi: Bu taslak hazırlanırken gerçek Netlify projesinde TLS, security headers, preview visibility, role permissions veya dummy secret bundle testi çalıştırılmadı. Yayından önce yalnız sahte değerlerle bir demo proje kurulmalı; curl, browser bundle araması ve iki farklı yetki hesabıyla sonuçlar kaydedilmelidir. Gerçek credential kesinlikle test materyaline konmamalıdır.

> Görsel notu: “Netlify sorumluluğu / müşteri sorumluluğu” matrisi, deploy yüzeyi diyagramı ve dummy secret’ın browser bundle’da görünmesini anlatan sansürlenmiş ekran görüntüsü hazırlanmalıdır.

> İç link editör notu: Domain bağlama, environment variables ve Deploy Previews rehberleri yayına girdiğinde ilgili bölümlere doğal bağlantılar eklenmelidir.

Netlify Güvenli mi? Karar Verirken Sorulacak Sorular

1. İşlediğiniz veri sınıfı nedir ve hangi bölgede saklanmalıdır? 2. Planınız gerekli rol, audit, log retention ve access control özelliklerini içeriyor mu? 3. Production ile preview verisi ve secret’ları ayrılmış mı? 4. Uygulama endpoint’leri authentication ve authorization testinden geçti mi? 5. Traffic abuse yalnız platform DDoS korumasına mı bırakıldı? 6. Compliance iddianız sözleşme ve gerçek kapsamla doğrulandı mı? 7. Incident olduğunda secret revoke, deploy rollback ve iletişim sahibi belli mi?

Bu soruların cevabı yoksa platform değiştirmek tek başına çözüm değildir. Önce riskleri, kontrol sahiplerini ve kabul kriterlerini yazılı hâle getirin.

Sık Sorulan Sorular

Netlify otomatik SSL sağlıyor mu?

Uygun biçimde bağlanmış domain’ler için Let’s Encrypt üzerinden yönetilen HTTPS sertifikası sağlayabilir. DNS, domain doğrulama ve mixed-content sorunları yine kontrol edilmelidir.

Netlify DDoS koruması sunuyor mu?

Netlify, Layer 3/4 ve Layer 7 DDoS azaltma kullandığını belirtiyor. Uygulama endpoint’leri için rate limit, authentication ve maliyet kontrolü ayrıca uygulanmalıdır.

Environment variable güvenli midir?

Server-side scope’ta, dar yetkiyle ve doğru erişim politikasıyla daha güvenli saklama sağlar. Client bundle’a eklenen her değer kullanıcı tarafından görülebilir ve secret sayılmamalıdır.

Deploy Preview’lar private mı?

Yeni projelerde private varsayılanları bulunabilir; ancak production ve preview görünürlüğü plan ve ayara göre değişebilir. Her projede erişimi açıkça test edin.

Netlify’nin compliance sertifikası benim uygulamamı compliant yapar mı?

Hayır. Platform sertifikası önemli bir altyapı girdisidir; uygulamanın veri akışı, erişim kontrolü, sözleşmeleri ve operasyonları ayrıca değerlendirilmelidir.

Kaynaklar

• Netlify Security
• HTTPS and SSL
• Environment variables overview
• Deploy Previews
• Forms submissions
• Security and privacy for AI features
• Netlify Trust Center

Sonuç

Netlify güvenli mi sorusunun koşullu cevabı şudur: Netlify güçlü platform ve ağ kontrolleri sunar; fakat güvenli sonuç ancak uygulama, erişim, secret, preview, veri ve incident süreçleri doğru yapılandırıldığında ortaya çıkar. Yönetilen HTTPS ve DDoS azaltma önemli bir temel oluşturur. Buna rağmen client bundle’a sızan anahtarı, yetkisiz Function endpoint’ini veya production verisine bağlanan public preview’ı platform otomatik olarak sizin yerinize düzeltemez. Kararı, gerçek veri sınıfı ve plan kapsamıyla yapılan threat model üzerinden verin.

Netlify’nin güncel güvenlik ve proje ayarlarını bir demo projede incelemek için [ücretsiz hesap oluşturabilirsiniz](https://join. netlify. com/wmkqymu1heo2). Bu bir iş ortaklığı bağlantısıdır; bağlantı üzerinden kayıt olmanız veya ücretli plana geçmeniz halinde Ortak Alan komisyon kazanabilir.