WordPress’te .htaccess ile Güvenlik Başlıkları: HSTS, CSP ve Daha Fazlası

Bir güvenlik taramasının önerilerini olduğu gibi .htaccessdosyasına eklemek, puanı yükseltirken siteyi bozabilir. Katı bir CSP ödeme iframe’ini veya editör betiklerini engelleyebilir; erken açılan includeSubDomainsise HTTPS’e hazır olmayan bir alt alanı erişilemez hâle getirebilir.

Güvenlik başlıkları ancak sitenin gerçek kaynakları, alt alanları ve proxy/CDN yapısı bilindiğinde güvenle uygulanabilir. Bu rehberde HSTS, CSP ve diğer yaygın başlıkları ne işe yaradıklarına göre ayırıyor; değişiklikleri aşamalı biçimde yayınlayıp tarayıcıya ulaşan son yanıtı doğrulamayı ele alıyoruz.

Güvenlik başlıkları ne işe yarar?

HTTP güvenlik başlıkları, tarayıcının bir yanıtı nasıl işleyeceğini belirtir. Strict-Transport-Security(HSTS) belirli bir süre boyunca yalnızca HTTPS kullanılmasını ister. Content-Security-Policy(CSP) betik, stil, görsel, font, frame ve bağlantı kaynaklarını sınırlar. X-Content-Type-Options, Referrer-Policyve Permissions-Policyise sırasıyla MIME türü yorumlama, yönlendiren adres bilgisi ve tarayıcı özellikleri üzerinde denetim sağlar.

Bu başlıklar uygulama açığını otomatik olarak düzeltmez. Tarayıcının davranışını daraltarak bazı saldırıların etkisini azaltır. Değerler sitenin gerçek kullanımına uymuyorsa giriş, ödeme, medya, analiz veya editör işlevleri de engellenebilir.

Gerçekçi bir WordPress örneği

Bir WooCommerce sitesi, hazır bir şablondan HSTS ile zorunlu CSP başlıklarını aynı anda ekliyor. CSP, ödeme sağlayıcısının iframe’ini ve çerez yönetim aracını engelliyor. HSTS içindeki includeSubDomainsseçeneği de sertifikası bulunmayan eski bir destek alt alanını erişilemez hâle getiriyor.

Ekip önce değişikliği geri alıyor, ardından CSP’yi Content-Security-Policy-Report-Onlyolarak yayımlıyor. Tarayıcı konsolu ve raporlar üzerinden ödeme, analitik, font ve CDN kaynaklarını çıkarıyor. HSTS ise yalnızca ana alan ve bütün ilgili alt alanların kalıcı HTTPS kullandığı doğrulandıktan sonra kısa bir süreyle başlatılıyor.

Hangi başlık ne zaman kullanılmalı?

CSP, sayfanın yüklemesine izin verilen kaynakları açıkça tanımlamak istediğinizde kullanılır. Envanter hazırlamadan yalnızca tarama sonucuna bakarak uygulanmamalıdır. script-src, style-src, img-src, font-src, connect-srcve frame-srcdeğerleri sitenin kullandığı gerçek hizmetlerle eşleşmelidir. Başka sitelerin sizin sayfanızı iframe içinde açmasını sınırlamak içinse frame-ancestorsgerekir.

HSTS, HTTP erişimini HTTPS’e kalıcı biçimde zorlamak için etkilidir; ancak tarayıcı kararı belirlenen süre boyunca hatırlar. Dosyayı geri almak, daha önce alınmış HSTS kararını hemen silmez. includeSubDomainsbütün alt alanları kapsar; preloadise ayrıca uzun vadeli ve dışarıdan yönetilen bir taahhüttür. Bu seçenekler yalnızca kapsam içindeki her hostun HTTPS’e hazır olduğu kanıtlandıktan sonra düşünülmelidir.

Referrer-Policyseçilirken ödeme dönüşleri, satış ortaklığı ölçümü ve üçüncü taraf entegrasyonları kontrol edilmelidir. Permissions-Policykamera, mikrofon veya konum gibi özellikleri sınırlar; gerçekten kullanılan gömülü hizmetleri istemeden devre dışı bırakmamalıdır. CORS başlıkları ise farklı bir amaç taşır ve güvenlik taraması için gelişigüzel eklenmemelidir.

Yeni başlayanlar için güvenli uygulama

1. Origin ve CDN üzerinden gelen mevcut yanıt başlıklarını ayrı ayrı kaydedin. Aynı başlığın birden fazla katmanda tanımlanıp tanımlanmadığını belirleyin.
2. Etkin .htaccessdosyasını yedekleyin; hosting paneli veya FTP üzerinden WordPress dışında erişebileceğiniz bir geri dönüş yolu hazırlayın.
3. Önce X-Content-Type-Optionsgibi kapsamı daha kolay doğrulanabilen bir başlıkla başlayın.
4. CSP’yi zorunlu moda almadan önce report-only olarak çalıştırın. Giriş, editör, form, medya, ödeme, analitik, callback ve gömülü içerik akışlarını sınayın.
5. HSTS için kısa bir max-ageile başlayın. Bütün alt alanlar doğrulanmadan includeSubDomainsveya preloadkullanmayın.
6. Temiz bir tarayıcı oturumunda hem ön yüzü hem yönetim panelini kontrol edin; CDN önbelleğini temizledikten sonra son başlıkları yeniden inceleyin.

İleri teknik yaklaşım

Gelişmiş yapılandırmada her başlığın tek bir sorumlusu olmalıdır. Apache, WordPress eklentisi, reverse proxy ve CDN aynı başlığı farklı değerlerle eklerse tarayıcı beklenenden daha katı davranabilir. Özellikle birden fazla CSP başlığı birbirinin alternatifi sayılmaz; tüm politikalar birlikte uygulanır.

• CSP raporlarını gerçek sayfa ve kullanıcı akışlarıyla ilişkilendirin. Her engellemeyi geniş bir wildcard ile açmak yerine gerekli kaynağı veya entegrasyonu düzeltin.
• Satır içi betikler için kalıcı unsafe-inlineizni vermek yerine uygulama desteği varsa nonce veya hash kullanın.
• Origin, CDN ve farklı coğrafi edge noktalarında başlıkları karşılaştırın. Eski önbellek, yeni politikayı yalnızca bazı ziyaretçilere gösterebilir.
• Yönetici oturumu, anonim ziyaretçi, WooCommerce ödeme, parola sıfırlama, REST API, webhook ve sosyal giriş gibi kritik yolları ayrı test edin.
• HSTS kapsamındaki hostların DNS, sertifika ve yönlendirme durumunu envanterleyin. Kullanılmayan ancak hâlâ DNS’te bulunan alt alanları da dahil edin.

Riskler, sık hatalar, yedek ve rollback

Sözdizimi hatalı bir .htaccessdeğişikliği 500 hatasına yol açabilir. Sözdizimi geçerli olsa bile aşırı katı CSP yalnızca belirli JavaScript işlevlerini bozabilir; bu yüzden ana sayfanın açılması yeterli kabul testi değildir.

• Dosya değişikliğinden önce bağımsız yedek alın ve son çalışan sürüme nasıl döneceğinizi doğrulayın.
• CSP zorunlu moda geçmeden önce report-only verisini yeterli süre boyunca inceleyin.
• HSTS geri dönüşünün anlık olmadığını unutmayın; tarayıcı daha önce aldığı süreyi saklar.
• CDN üzerinde tanımlanan başlığı origin tarafında tekrar eklemeyin. Tek bir yayın katmanı seçin.
• Rollback sonrasında kritik kullanıcı akışlarını ve tarayıcıya ulaşan gerçek başlıkları yeniden sınayın.

İlgili AIOWS yazıları

• WordPress’te .htaccess ile Dizin Listeleme Nasıl Kapatılır?
• wp-config.php Dosyası .htaccess ile Nasıl Korunur?
• WordPress’te .htaccess ile Tarayıcı Önbellek Başlıkları Nasıl Eklenir?

Sonuç ve önerilen yol

Başlıkları tek seferde değil, etkisi ölçülebilecek küçük adımlarla yayımlayın. CSP’yi report-only verisiyle olgunlaştırın; HSTS kapsamını ise bütün hostlar kalıcı HTTPS’e hazır olmadan genişletmeyin.

Resmî kaynaklar

• MDN Content Security Policy rehberi
• MDN HSTS referansı