WordPress güvenlik başlıkları: CSP, HSTS ve diğerleri

Başlık notu düşük çıkan çoğu WordPress sitesi bir saatten kısa sürede düzeltilebilir. Bugün dört düşük riskli başlık ekleyin: HSTS, X-Content-Type-Options, Referrer-Policy ve Permissions-Policy. Content-Security-Policy'yi ise yavaş yavaş, önce yalnızca rapor modunda devreye alın. Bu rehber, her bir WordPress güvenlik başlığı için güvenli başlangıç değerlerini, bunları nereden yapılandıracağınızı ve hangilerinin editörünüzü ya da gömülü içeriklerinizi bozabileceğini anlatıyor.

WordPress güvenlik başlıkları ne yapar, ne yapmaz

Güvenlik başlıkları, sunucunuzun ziyaretçinin tarayıcısına gönderdiği talimatlardır. Tarayıcıya yalnızca HTTPS kullanmasını, dosya türlerini tahmin etmemesini, başka sitelerin sayfalarınızı çerçeve içine almasına izin vermemesini ve hangi betikleri çalıştırabileceğini söylerler. Böylece HTTPS'ten HTTP'ye düşürme (downgrade) saldırıları, MIME sniffing, clickjacking ve siteler arası betik çalıştırma (XSS) saldırılarının etkisi azalır.

Güvenlik açığı bulunan bir eklentiyi yamalamazlar, parola deneme saldırısını durdurmazlar, sunucunun kendisini de korumazlar. Saldırgan sunucunuza PHP dosyası yazabiliyorsa hiçbir başlık işe yaramaz. Başlıkları tarayıcı tarafında bir sertleştirme katmanı olarak görün; bir güvenlik düzeltmesi yerine koymayın.

Eksik başlıklar, OWASP Top 10 listesindeki güvenlik yapılandırma hatalarının klasik bir örneğidir. Ayrıca ucuz ve iyi belgelenmiş önlemlerdir; bu yüzden GDPR (AB Genel Veri Koruma Tüzüğü) Madde 32 kapsamında dikkate almanız beklenen "teknolojinin güncel durumunun" (state of the art) bir parçası sayılırlar.

Temel ayar: her başlık için güvenli başlangıç değerleri

Bu değerler bilerek temkinli seçildi. Tipik bir WordPress sitesini bozmamaları gerekir; sıkılaştırmayı sonra yapabilirsiniz.

HSTS, RFC 6797 ile tanımlanmıştır. Beş dakikayla (max-age=300) başlayın ve hiçbir şeyin bozulmadığını doğrulayın. Ardından bir güne (86400), sonra bir haftaya, en sonunda da bir yıla (31536000) çıkarın. includeSubDomains ifadesini ancak tüm alt alan adlarının HTTPS ile çalıştığını kontrol ettikten sonra ekleyin.

Referrer-Policy için strict-origin-when-cross-origin, diğer sitelere tam URL yerine yalnızca alan adınızı gönderir. WordPress'te bu önemlidir; çünkü URL'lerde sıklıkla arama terimi, sipariş numarası ya da kampanya parametresi gibi sorgu dizeleri bulunur ve bunların üçüncü taraflara gitmesini istemezsiniz.

Permissions-Policy, sayfalarınız ve gömülü çerçeveler için kamera, mikrofon ve konum erişimini kapatır. Konum erişimi isteyen bir mağaza bulucu kullanıyorsanız geolocation ifadesini listeden çıkarın.

Çerçeve koruması artık CSP içinde frame-ancestors 'self' olarak yer alır. X-Frame-Options: SAMEORIGIN başlığını yalnızca eski tarayıcılar için yedek olarak tutun. Sadece frame-ancestors içeren küçük bir CSP'yi zorunlu modda şimdiden yayına almak güvenlidir. Tam CSP daha sonra gelir.

X-XSS-Protection kullanımdan kalkmıştır. Etkinleştirmeyin. Modern tarayıcıların kaldırdığı bir XSS filtresini kontrol ediyordu; üstelik filtrenin kendisi, başka türlü güvenli olan sayfalarda yeni sorunlar çıkarmak için kötüye kullanılabiliyordu. 1; mode=block ayarı size hiçbir şey kazandırmaz. Yerini CSP almıştır.

Güvenlik başlıkları nereden ayarlanır: sunucu, eklenti veya CDN

Her başlık için tek bir yer seçin. Sunucu, bir güvenlik eklentisi ve CDN aynı anda Strict-Transport-Security gönderirse yinelenen ya da çelişen değerler ortaya çıkar ve hangisinin geçerli olduğunu kimse hatırlamaz.

En iyi yer genellikle web sunucusudur. Sunucu kuralları; görseller, CSS dosyaları ve tam sayfa önbelleğinden sunulan sayfalar dahil her yanıta uygulanır. Çoğu paylaşımlı hosting'in kullandığı Apache'de, WordPress kök dizinindeki .htaccess dosyasında # BEGIN WordPress bloğunun üstüne şunu ekleyin. mod_headers modülü gerekir:

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=300"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header always set Content-Security-Policy "frame-ancestors 'self'"
  Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>

nginx'te eşdeğer satırları HTTPS sitenizin server bloğuna koyun ve yeniden yüklemeden önce nginx -t çalıştırın:

add_header Strict-Transport-Security "max-age=300" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "frame-ancestors 'self'" always;
add_header X-Frame-Options "SAMEORIGIN" always;

nginx'te bir tuzağa dikkat edin. Kendi add_header satırı olan bir location bloğu, server düzeyindeki hiçbir add_header satırını devralmaz. /wp-content/uploads/ için eklenen bir cache-control başlığı, o dosyalardaki tüm güvenlik başlıklarınızı fark ettirmeden silebilir. Başlıkları o blokta tekrarlayın ya da her yerde include ettiğiniz bir parçaya taşıyın.

WordPress'in send_headers kancasını kullanan eklentiler ve kodlar yalnızca PHP sayfayı oluştururken çalışır. Statik dosyalar PHP'den hiç geçmez. Tam sayfa önbelleğinden sunulan sayfalar da, önbelleğin başlıkları nasıl sakladığına ve yeniden gönderdiğine bağlı olarak PHP'yi atlayabilir. CDN veya uç (edge) kuralları iyi bir alternatiftir; çünkü CDN'den geçen her şeyi kapsar. Yönetilen hosting sağlayıcıları çoğu zaman kontrol panelinde kendi başlık ayarlarını sunar. Sizinki sunuyorsa o paneli kullanın, aynı kuralları .htaccess içinde yinelemeyin.

WordPress'i bozmadan Content-Security-Policy

CSP, en büyük faydayı sağlayan ama en riskli başlıktır. Tarayıcıya hangi kaynaklardan betik, stil, görsel, yazı tipi ve çerçeve yüklenebileceğini söyler. WordPress bunu zorlaştırır. Çekirdek ve blok editörü satır içi betik ve stil üretir; sayfa oluşturucular bunlara yenilerini ekler. Analitik araçları, YouTube ve harita gömmeleri, çerez bannerları ve ödeme bileşenlerinin her biri başka alan adlarından kod yükler. Bunlardan herhangi birini engelleyen katı bir politika ödeme adımını bozabilir ya da editörü boş ekranla baş başa bırakabilir.

Rapor modunda başlayın. Tarayıcı bu modda hiçbir şeyi engellemeden ihlalleri kaydeder:

Content-Security-Policy-Report-Only: default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'

Ana sayfa türlerinizi açın: ana sayfa, bir blog yazısı, gömülü içerik barındıran bir sayfa, sepet ve ödeme. Ardından tarayıcının geliştirici araçlarında her biri için Konsol'u kontrol edin. Her ihlal, engellenen kaynağı ve ihlal edilen yönergeyi belirtir. Bu listeyi, sitenizin yaptığı üçüncü taraf isteklerinin envanteri olarak görün. Çoğu zaman kimsenin eklediğini hatırlamadığı şeyler çıkar; eski bir sohbet bileşeni ya da Google'dan yüklenen yazı tipleri gibi. Bunlarla nasıl başa çıkacağınızı Google Fonts yazımızda anlattık.

Gerçekten ihtiyaç duyduğunuz kaynakları ekleyin, gerekmeyenleri çıkarın ve Konsol'u yeniden kontrol edin. Başlık adını Content-Security-Policy olarak yalnızca tüm önemli sayfalarda ihlaller bittiğinde değiştirin. Bu tam politikaya frame-ancestors 'self' ifadesini de ekleyin: tarayıcılar rapor modunda frame-ancestors yönergesini yok sayar ve tam başlık, daha önce koyduğunuz küçük başlığın yerini alacaktır. Zor kısım satır içi betiklerdir: 'unsafe-inline' izni XSS korumasının büyük bölümünü ortadan kaldırır; nonce veya hash kullanımı ise tema ya da eklenti desteği gerektirir. Tüm yönergeler MDN CSP başvurusunda belgelenmiştir.

En azından başlangıçta wp-admin'i katı politikanın dışında tutmayı düşünün. nginx'te ön yüz CSP'sini tüm server bloğuna değil, herkese açık siteyi sunan location'lara yerleştirin.

İhlalleri merkezi olarak toplamak için bir report-uri veya report-to uç noktası ekleyebilirsiniz. Bu raporlar sayfa URL'lerini ve tarayıcı ayrıntılarını içerir, her biri de ziyaretçinin IP adresiyle birlikte gelir. Üçüncü taraf bir raporlama hizmeti GDPR kapsamında genellikle sizin adınıza veri işleyen (processor) konumundadır; dolayısıyla bir veri işleme sözleşmesi (md. 28) gerekir. Küçük bir site için Konsol'u kendiniz okumak çoğu zaman yeterlidir.

HSTS preload: neden beklemelisiniz

Preload, alan adınızı tarayıcıların beraberinde getirdiği bir listeye ekler. Bu tarayıcılar alan adınız için ilk ziyaretten önce, ayrıca tüm alt alan adlarında HTTPS kullanır. Sorun da tam burada. Yalnızca düz HTTP üzerinden çalışan eski bir webmail sunucusu, bir test sitesi, bir yazıcı arayüzü ya da bir intranet aracı bu tarayıcılarda erişilemez hale gelir.

Bir alan adını listeden çıkarmak mümkündür ama yavaştır. Tarayıcılar kaydı ancak değişiklik tarayıcı güncellemeleriyle kullanıcılara ulaştıktan sonra siler. Kararın kalıcı olduğunu varsayarak plan yapın.

max-age değerini adım adım yükseltin ve yüksek değerlerde bir süre tutun. Kuruluşunuzun kullandığı tüm alt alan adlarını, DNS'te duran ama artık kimsenin ziyaret etmediği kayıtlar dahil listeleyin. Preload'u ancak hepsi HTTPS ile çalışıyorsa düşünün. hstspreload.org gönderim sitesi, başlık için güncel gereksinimleri yayımlar. Blog yazılarından değer kopyalamak yerine onları orada okuyun.

Başlıkları test etmek ve yerinde tutmak

Yapılandırma dosyalarına değil, gerçek yanıtlara bakın. Tarayıcının geliştirici araçlarında Network sekmesini açın, belge isteğine tıklayın ve yanıt başlıklarını okuyun. Terminalden:

curl -sI https://example.com/
curl -sI https://example.com/wp-includes/css/dist/block-library/style.min.css

Herkese açık başlık denetleme siteleri hızlı bir genel bakış verir. OWASP Secure Headers Project, önerilen her başlığın gerekçesini açıklar. En az şu beş yanıtı test edin:

• Ana sayfa
• Oturum kapalıyken açılan, önbellekten sunulan bir sayfa
• Bir statik dosya (CSS, JS veya görsel)
• /wp-login.php
• wp-admin'de bir ekran, blok editörü dahil

Başlıklar çoğu zaman kimse fark etmeden kaybolur. Sık nedenler: .htaccess kurallarınızı düşüren bir hosting taşıması, bir CDN değişikliği ya da kendi değerlerini gönderen yeni bir önbellek veya güvenlik eklentisi. Bu değişikliklerden sonra başlıkları yeniden kontrol edin. Etkin yapılandırmayı ve test tarihini, güvenlik kontrol listesindeki diğer sertleştirme kayıtlarınızla birlikte saklayın. Bir müşteri anketinde ya da denetçiye göstereceğiniz kayıt budur.

secaudit.eu denetim eklentisi bir sertleştirme ve yapılandırma taraması yapar, bulgularını GDPR md. 32 ve NIS2 Direktifi md. 21 ile eşleştirir. Yukarıdaki başlık kontrollerinin yanında kullanın → secaudit.eu

SSS

Güvenlik başlıkları SEO'yu veya sayfa hızını etkiler mi?

Etkisi ihmal edilebilir düzeydedir. Her yanıta birkaç yüz bayt ekler. HSTS ise tekrar ziyaretlerde HTTP'den HTTPS'e yönlendirmeyi ortadan kaldırabilir.

Tüm güvenlik başlıklarını bir eklenti benim için ayarlayabilir mi?

Kısmen. Eklenti PHP'nin oluşturduğu sayfaları kapsar ama statik dosyaları ve önbellekteki sayfaları kaçırabilir. Sunucu veya CDN kuralları daha güvenilirdir.

X-XSS-Protection: 0 göndermeli miyim, yoksa hiç eklememeli miyim?

Hiç eklemeyin; bir anket açık bir değer istiyorsa 0 gönderin. 0, eski filtreyi kapatır. 1; mode=block değerini asla kullanmayın.

HSTS, GDPR tarafından zorunlu mu?

GDPR belirli başlıkları adıyla anmaz. GDPR, teknolojinin güncel durumunu dikkate alan uygun bir güvenlik düzeyi ister. HSTS ile HTTPS'i zorunlu kılmak bu gereklilikle uyumlu, ucuz ve standart bir önlemdir.

Bu makale genel bilgilendirme amaçlıdır ve hukuki danışmanlık değildir.