Güncellenecek Eklenti Yok, Hacklenecek Panel Yok: Statik Sitenin Güvenlik Farkı Gerçekte Ne Kadar?
Statik site kapıyı kaldırır, anahtarları değil. Panel, eklenti ve veritabanı gider; alan adı, hosting hesabı, scriptler ve formlar sizin sorumluluğunuzda kalır.
Kısa cevap: Statik site, WordPress tipi bir sitedeki en büyük risk katmanını, yani eklentileri, temaları, herkese açık yönetim panelini ve veritabanını tamamen ortadan kaldırır. Ama sitenizi hacklenemez yapmaz. Alan adı ve DNS hesabı, hosting/Git hesabı, sayfaya eklenen üçüncü taraf scriptler, form ve API uç noktaları ve build bağımlılıkları hâlâ sizin sorumluluğunuzdadır. Kısacası statik site kapıyı kaldırır, anahtarları değil.
Mandalium'da siteleri statik olarak kuruyoruz ve müşterilerimizden en sık duyduğumuz cümle şu: "Artık güvenlik derdimiz yok, değil mi?" Cevabımız her zaman aynı: dert küçülür, şekil değiştirir, ama bitmez. Bu yazı, farkın gerçekte ne kadar olduğunu kaynaklı rakamlarla ve abartmadan anlatıyor. Kurumsal site, e-ticaret vitrini, kişisel portfolyo veya B2B katalog fark etmez; aşağıdaki çerçeve hepsinde aynı şekilde işler. Sitenizin güvenilir görünmesi de ayrı bir konu; onu güven sinyalleri rehberinde anlattık.
Yönetim paneli, eklenti ve tema kodu, veritabanı, her istekte çalışan sunucu kodu.
Alan adı, DNS, hosting ve Git hesabı. Ele geçirilirse kod hacklenmeden site el değiştirir.
Chat widget, pixel, CDN'den çekilen kod ve build sırasında kurulan npm paketleri.
Formları ve dinamik veriyi taşıyan API'ler. Sitenin "dinamik" kalan tek parçası.
AEO cümlesi: Statik site, sayfaları önceden HTML dosyası olarak üretip sunan; ziyaret anında veritabanı sorgusu, eklenti kodu veya herkese açık yönetim paneli çalıştırmayan bir web sitesidir. Bu yapı, WordPress tipi sitelerdeki açıkların büyük çoğunluğunu oluşturan eklenti ve tema katmanını ortadan kaldırır; alan adı, hosting hesabı, üçüncü taraf script, form ve build bağımlılığı riskleri ise kalır.
Rakamlar: dinamik bir CMS'te risk nereden geliyor?
WordPress güvenliği üzerine en kapsamlı yıllık veriyi yayımlayan kaynaklardan biri Patchstack. Şubat 2026'da güncellenen State of WordPress Security in 2026 raporunun 2025 verileri, riskin nerede toplandığını çok net gösteriyor (Patchstack: State of WordPress Security in 2026):
- 11.334 yeni açık. 2025'te WordPress ekosisteminde bulunan yeni açık sayısı; 2024'e göre %42 artış.
- %91 eklentilerde, %9 temalarda. WordPress çekirdeğinde yalnızca 6 açık raporlandı ve hepsi düşük öncelikliydi. Yani risk çekirdekte değil, üstüne eklenen katmanda.
- %46'sı duyurulduğunda yamasızdı. Açıkların neredeyse yarısı, kamuya duyurulduğu anda geliştiricisinden düzeltme almamıştı. Güncelleme yapmak istemeniz yetmez; ortada güncelleme olmayabilir.
- 5 saat. Yoğun saldırı alan açıklarda, duyurudan ilk saldırı girişimine kadar geçen ağırlıklı medyan süre. "Hafta sonu güncellerim" planı bu hıza yetişmez.
- %12 ve %26. Patchstack'in 2025'te barındırma firmalarında yaptığı iki sızma testinde, standart ağ ve sunucu katmanı korumaları WordPress'e özgü saldırıların yalnızca %12'sini, daha geniş test setinde ise toplam saldırıların %26'sını engelledi.
Bu rakamlardan çıkan sonuç basit: WordPress tipi bir sitede güvenlik riskinin büyük kısmı, sitenin her istekte çalıştırdığı eklenti ve tema kodundan geliyor. Not: Bunlar raporlanan açık sayılarıdır, başarılı saldırı sayıları değil; ve Patchstack bir güvenlik firmasıdır. Yine de farklı kaynaklar aynı yönü gösteriyor: eklenti katmanı ekosistemin en zayıf halkası.
Statik site neyi gerçekten ortadan kaldırıyor?
Statik sitede sayfalar yayından önce bir kez üretilir ve sunucu yalnızca hazır HTML, CSS, JavaScript ve görsel dosyalarını gönderir. Ziyaretçinin isteğiyle çalışan bir uygulama yoktur. Bu, dört katmanı tamamen siler:
- Herkese açık yönetim paneli. /wp-admin gibi bir giriş sayfası yoksa, parola deneme (brute force) ve çalıntı parolayla giriş saldırılarının hedefi de yoktur.
- Eklenti ve tema kodu. Yukarıdaki açıkların neredeyse tamamının (%91 eklenti, %9 tema) yaşadığı katman. Statik sitede "güncellenmeyi bekleyen 14 eklenti" uyarısı yoktur.
- Veritabanı. Sorgu yoksa SQL enjeksiyonu da yoktur; çalınacak bir kullanıcı tablosu da yoktur.
- Her istekte çalışan sunucu kodu. PHP sürümü, sunucu eklentileri ve dosya yükleme açıkları gibi bir çalışma zamanının (runtime) getirdiği bakım yükü kalkar. Bir bonus: aynı yapı hız için de iyidir.
Pratikte en büyük kazanç bakım takviminin değişmesidir. Dinamik bir CMS'te güvenlik, her hafta yapılması gereken bir iştir. Statik sitede ise birkaç ayda bir yapılan bir kontrol ve birkaç kalıcı ayara dönüşür. Aşağıdaki beş risk tam da bu ayarlarla ilgilidir.
Statik site neyi ortadan kaldırmıyor? 5 anahtar
Bunlara 5 anahtar diyoruz, çünkü hepsi sitenize başka bir kapıdan girmenin anahtarıdır. Statik sitede de, WordPress'te de aynı ölçüde geçerlidirler.
1. Alan adı ve DNS hesabı
Sitenin en tepesindeki anahtar budur. Alan adınızın kayıtlı olduğu firmadaki (registrar) veya DNS sağlayıcınızdaki hesabı ele geçiren biri, tek bir kaydı değiştirerek ziyaretçilerinizi kendi sunucusuna yönlendirebilir, e-postanızın MX kaydını değiştirebilir ve alan adınız için geçerli bir SSL sertifikası bile alabilir; ziyaretçinin tarayıcısı hiçbir uyarı göstermez. ABD siber güvenlik ajansı CISA, 2019'daki DNS altyapısı saldırı kampanyasının ardından yayımladığı acil direktifte tam bu senaryoyu anlatıyor ve DNS kaydını değiştirebilen tüm hesaplarda parola yenilemeyi, çok faktörlü doğrulamayı (MFA) ve tercihen SMS yerine oltalamaya dayanıklı yöntemleri (güvenlik anahtarı gibi) öneriyor. Registrar'ınız MFA sunmuyorsa önerisi açık: MFA sunan bir firmaya taşıyın (CISA: ED 19-01, Mitigate DNS Infrastructure Tampering).
Yapılacaklar: registrar ve DNS hesabında 2FA, transfer kilidi (registrar lock), alan adının şirketin kendi hesabında olması (ajansın veya eski çalışanın kişisel hesabında değil), otomatik yenileme ve güncel bir iletişim e-postası.
2. Hosting ve Git hesabı
Statik sitede "panel" ortadan kalkmaz, yer değiştirir: artık sitenizin yönetim paneli Git deponuz (GitHub, GitLab) ve hosting hesabınızdır (Cloudflare, Netlify, Vercel, Azure vb.). Depoya yazma yetkisi olan biri, bir commit ile siteyi değiştirebilir; hosting hesabına giren biri farklı bir sürümü yayına alabilir veya alan adını kendi projesine bağlayabilir. Bu hesaplarda 2FA, en az yetki ilkesi (herkes yönetici olmasın), ana dala doğrudan push yerine inceleme isteği (pull request) ve ayrılan çalışanların erişiminin aynı gün kapatılması temel kurallardır. Mandalium'da kendi sitemizde de ana dala değişiklik yalnızca incelenmiş bir PR ile girer.
3. Üçüncü taraf scriptler
Sayfaya eklediğiniz her harici script (chat widget, reklam pikseli, analiz aracı, A/B test aracı, CDN'den çekilen bir kütüphane), ziyaretçinin tarayıcısında sizin sitenizin yetkisiyle çalışır. O script'in sahibi değişirse veya ele geçirilirse, siteniz statik bile olsa ziyaretçiniz kötü amaçlı kodu sizin alan adınızdan alır. En bilinen örnek 2024'teki polyfill.io olayı: alan adı ve GitHub hesabı yeni bir firmaya satıldıktan sonra cdn.polyfill.io, bu script'i kullanan 100 binden fazla siteye, özellikle mobil ziyaretçileri dolandırıcılık sitelerine yönlendiren kod enjekte etmeye başladı (Sansec: Polyfill supply chain attack hits 100K+ sites). O sitelerin çoğunun kendi kodunda tek satır değişmemişti.
Yapılacaklar: script envanteri çıkarın ve kullanılmayanı silin; mümkünse kütüphaneyi kendi sitenizde barındırın; harici dosyalarda Subresource Integrity (SRI) kullanın; Content-Security-Policy (CSP) ile hangi alan adlarından script yüklenebileceğini sınırlayın. Scriptler hız tarafında da maliyetlidir; JavaScript'e bağımlı içeriğin AI botlarına ulaşmayabileceğini View Source testi yazısında anlattık.
4. Formlar ve API uç noktaları
Statik site form verisini kendisi işleyemez; form, bir API'ye veya form servisine gönderilir. Mandalium sitelerinde de iletişim formu ve dinamik içerik, sitenin dışında duran küçük bir API servisi (örneğin json.mandalium.com tipi bir uç nokta) üzerinden çalışır. Bu, sitenin "dinamik" kalan tek parçasıdır ve bir web uygulaması gibi korunmalıdır: girdiyi sunucu tarafında doğrulamak, hız sınırı ve bot koruması (Turnstile, reCAPTCHA veya honeypot), yalnızca kendi alan adınızdan gelen isteklere izin veren CORS ayarı ve API anahtarlarının asla tarayıcıya giden koda konmaması. OWASP Top 10:2025 listesinin ilk sırasında hâlâ Bozuk Erişim Kontrolü (Broken Access Control) var; küçük bir form API'si bile bu listeye göre test edilmelidir (OWASP Top 10:2025).
5. Build bağımlılıkları
Statik site üretilirken (build) npm gibi paket yöneticilerinden onlarca, bazen yüzlerce paket kurulur. Bu kod yayındaki sitede çalışmaz, ama build makinesinde çalışır ve ürettiği dosyalara müdahale edebilir. OWASP, 2025 listesinde bu riski yeni bir kategori olarak 3. sıraya taşıdı: A03:2025 Software Supply Chain Failures. Kategori, topluluk anketinde katılımcıların tam %50'si tarafından 1 numaralı risk olarak seçilmiş ve CVE verilerinde en yüksek ortalama istismar ve etki puanlarına sahip (OWASP: A03:2025 Software Supply Chain Failures).
Yapılacaklar: lock dosyasını (package-lock.json) depoya koyun ve build'de npm ci kullanın; GitHub Dependabot gibi bir uyarı servisini açın; az paket kullanın; build'i kişisel bilgisayar yerine kayıtlı bir CI ortamında çalıştırın ve OWASP'ın önerdiği gibi kimsenin tek başına kodu inceleme olmadan yayına alamayacağı bir akış kurun.
Karar çerçevesi: hangi site için hangisi?
Statik site her ihtiyaca doğru cevap değil. Dürüst karar, sitenin ne yaptığına göre verilir:
| Durumunuz | Öneri | Neden |
|---|---|---|
| Kurumsal site, hizmet sitesi, portfolyo, katalog | Statik | İçerik ayda birkaç kez değişir; panel ve eklenti riski taşımak için bir sebep yok. |
| Blog veya haber, haftada birkaç yazı | Statik veya statik çıktı alan headless CMS | Yazı paneli herkese açık siteden ayrılır; editör rahatı korunur. |
| Formlar, teklif, randevu | Statik + küçük, ayrı bir API | Dinamik kısım tek bir uç noktada toplanır ve orada korunur. |
| Çok editörlü, günlük yayın, üyelik, karmaşık e-ticaret | Dinamik platform (hazır SaaS veya yönetilen CMS) | Statik ile zorlamak maliyetli olur. Bunun yerine eklentiyi azaltın, 2FA, otomatik güncelleme ve sanal yama bütçeleyin. |
| Mevcut WordPress, 20+ eklenti, kimse güncellemiyor | Önce sadeleştirin, sonra statiğe geçişi değerlendirin | En yüksek risk profili: Patchstack'e göre açıkların neredeyse yarısı duyurulduğunda yamasız. |
Kural: Sitenizin her ziyarette bir şey hesaplaması gerekmiyorsa, her ziyarette kod çalıştırmasına da gerek yoktur.
Statik site güvenlik kontrol listesi
Bu listeyi yılda iki kez ve her ekip değişikliğinde gözden geçirin. Bir satır "hayır" ise o anahtar açıktadır.
| Anahtar | Kontrol | Sıklık |
|---|---|---|
| Alan adı | Alan adı şirketin hesabında mı, 2FA ve transfer kilidi açık mı, otomatik yenileme aktif mi? | 6 ayda bir |
| DNS | Tüm kayıtlar (A, CNAME, MX, NS) bilinen ve kullanılan hedefleri mi gösteriyor? | 6 ayda bir |
| Hosting | Hosting hesabında 2FA var mı, yalnızca gereken kişiler yönetici mi? | Ekip değişince |
| Git | Organizasyonda 2FA zorunlu mu, ana dal korumalı mı (PR + inceleme)? | Ekip değişince |
| Erişim | Ayrılan çalışan ve eski ajans erişimleri kapatıldı mı? | Ayrılış günü |
| Scriptler | Sayfadaki her harici script'in sahibi ve amacı biliniyor mu, kullanılmayan silindi mi? | 3 ayda bir |
| CSP / SRI | Content-Security-Policy tanımlı mı, harici dosyalarda SRI var mı? | Script eklenince |
| Güvenlik başlıkları | HTTPS zorunlu mu (HSTS), X-Content-Type-Options ve çerçeveleme koruması var mı? | Yılda bir |
| Formlar | Sunucu tarafı doğrulama, hız sınırı ve bot koruması var mı? | Form değişince |
| API anahtarları | Tarayıcıya giden kodda gizli anahtar var mı? (View Source ile arayın.) | Her yayında |
| Bağımlılıklar | Lock dosyası depoda mı, Dependabot veya benzeri uyarılar açık ve okunuyor mu? | Aylık |
| Geri dönüş | Bir önceki sürüme tek tıkla dönülebiliyor mu? | Yılda bir deneyin |
İpucu: Son satır statik sitenin gizli avantajıdır. Her yayın sabit bir dosya kümesi olduğu için bir sorun olduğunda önceki sürüme saniyeler içinde dönülebilir. Dinamik bir sitede temizlik çoğu zaman günler sürer.
Yaygın yanılgılar
Kod hacklenmeden de site el değiştirebilir: DNS kaydı, Git hesabı veya bir script yeterlidir.
Eklenti saldırıları otomatiktir; site seçmez, açığı arar. Hedef siz değil, kullandığınız sürümdür.
Bir eklenti daha, güncellenecek bir kod daha demektir. Riski azaltan şey eklenti eklemek değil, eklenti sayısını azaltmaktır.
Alan adı her zaman şirketin kendi hesabında olmalı. Ajans yetkili kullanıcı olabilir, sahip olmamalı.
Hiç yoktan iyidir ama CISA, kritik hesaplarda oltalamaya dayanıklı yöntemleri (güvenlik anahtarı) öneriyor.
Servis kendi altyapısını korur; hangi alandan istek kabul edildiği ve anahtarın nerede durduğu sizin ayarınızdır.
Sonuç: risk küçülür, sorumluluk netleşir
Kısa cevap: Statik site, WordPress tipi sitelerde açıkların %91'inin bulunduğu eklenti katmanını, yönetim panelini ve veritabanını ortadan kaldırarak saldırı yüzeyini belirgin biçimde küçültür; kalan risk, 5 anahtarın (alan adı, hosting/Git, scriptler, formlar, bağımlılıklar) korunmasıdır. Haftalık yama koşusu, yılda iki kez yapılan bir kontrol listesine dönüşür. Bu fark gerçek, ama kendiliğinden gelmez.
İlgili rehberler: güven sinyalleri, View Source testi, ilk web sitenizde olması gereken 8 sayfa, B2B: katalog mu, dönüşüm odaklı site mi?, llms.txt rehberi.
Mandalium olarak siteleri statik kuruyor, formları ayrı ve korumalı bir API'ye bağlıyor ve teslimde alan adı, hosting ve Git erişimlerini sizin hesabınıza devrediyoruz. Sitenizin 5 anahtarını birlikte kontrol edelim →
Kaynaklar: Patchstack — State of WordPress Security in 2026 (güncelleme: 25.02.2026); CISA — ED 19-01: Mitigate DNS Infrastructure Tampering; Sansec — Polyfill supply chain attack hits 100K+ sites (25.06.2024); OWASP Top 10:2025; OWASP — A03:2025 Software Supply Chain Failures.
Sık sorulan sorular
Statik site hacklenebilir mi?
Evet, ama farklı yollardan. Statik sitede giriş paneli, eklenti ve veritabanı olmadığı için WordPress tipi sitelere yönelik otomatik eklenti saldırıları hedef bulamaz. Buna karşılık alan adı ve DNS hesabı, hosting veya Git hesabı, sayfaya eklenen üçüncü taraf scriptler, form ve API uç noktaları ve build bağımlılıkları hâlâ saldırıya açıktır.
Statik site WordPress'ten ne kadar daha güvenli?
Tek bir yüzde vermek dürüst olmaz, ama risk dağılımı net. Patchstack'e göre 2025'te WordPress ekosisteminde 11.334 yeni açık bulundu ve bunların %91'i eklentilerde, %9'u temalardaydı; çekirdekte yalnızca 6 düşük öncelikli açık vardı. Statik site bu eklenti ve tema katmanını, yönetim panelini ve veritabanını tamamen ortadan kaldırır. Kalan riskler hesap ve tedarik güvenliğidir.
WordPress kullanıyorsam eklentileri güncellemek yeterli mi?
Gerekli ama yetersiz. Patchstack'in 2026 raporuna göre açıkların %46'sı kamuya duyurulduğu anda geliştiricisinden düzeltme almamıştı ve yoğun saldırı alan açıklarda ilk saldırı girişimine kadar geçen ağırlıklı medyan süre 5 saatti. Güncellemeye ek olarak eklenti sayısını azaltmak, yönetim paneline 2FA eklemek ve sanal yama (virtual patching) sunan bir koruma kullanmak gerekir.
Statik sitede en büyük güvenlik riski nedir?
Çoğu zaman hesaplardır. Alan adı, DNS, hosting veya Git hesabını ele geçiren biri, sitenin kodunu hiç hacklemeden ziyaretçiyi başka bir sunucuya yönlendirebilir veya sahte içerik yayınlayabilir. CISA, DNS kaydını değiştirebilen tüm hesaplarda parola yenilemeyi ve tercihen oltalamaya dayanıklı çok faktörlü doğrulamayı öneriyor.
Statik sitede iletişim formu güvenli olur mu?
Olur, ama form artık ayrı bir servistir ve onun güvenliği ayrıca düşünülmelidir. Form verisini alan uç nokta (kendi API'niz veya bir form servisi) sunucu tarafında doğrulama, hız sınırı, bot koruması ve gizli anahtarların tarayıcıya hiç gönderilmemesi gibi kurallarla korunmalıdır.
Statik siteye geçmek için WordPress'i bırakmak şart mı?
Şart değil. İçeriği WordPress veya başka bir CMS'te yönetip siteyi statik olarak üretmek (headless/statik çıktı) mümkündür. Bu durumda yönetim paneli herkese açık siteden ayrılır; ama panelin kendisi hâlâ korunması ve güncellenmesi gereken bir sistemdir.
Tugay Mandal
Mandalium’un kurucusu. Mandalium kendi ürünlerini yapan bir yazılım stüdyosu. Web ürünü, kurumsal site ve site denetimi alanında 6+ yıllık deneyimi var.
Hakkımızda
