Kısaca: security.txt, RFC 9116'da tanımlanan, /.well-known/security.txt adresinde bulunan düz metin bir dosyadır ve güvenlik araştırmacılarına sitenizdeki bir güvenlik açığını tam olarak nasıl bildireceklerini söyler. Eklemesi yaklaşık beş dakika sürer, ve AB Siber Dayanıklılık Yasası gibi düzenlemelerdeki güvenlik açığı bildirim beklentilerini karşılamanın standart yolu.
security.txt Gerçekte Ne
security.txt, RFC 9116'da tanımlanan ve sitenizde bir güvenlik açığı bulan herkese bunu nasıl bildireceğini tam olarak söyleyen düz bir metin dosyasıdır. Tahmin edilebilir bir konumda yaşar — /.well-known/security.txt — böylece güvenlik araştırmacıları ve otomatik tarayıcılar iletişim sayfanızı kazmak veya bir e-posta adresi tahmin etmek zorunda kalmaz.
Minimal bir örnek şöyle görünür:
Contact: mailto:security@example.com
Expires: 2027-01-01T00:00:00.000Z
Preferred-Languages: tr
Bu, formatın tamamı: her biri kendi satırında küçük bir düz metin alan seti. JSON yok, XML yok, karmaşık bir şey yok.
Bunun "Olsa İyi Olur"un Ötesinde Neden Önemli Olduğu
Bir security.txt dosyası olmadan, WordPress sitenizde bir güvenlik açığı bulan bir araştırmacının seçenekleri sınırlıdır: iletişim formunuzu kazımak, bir e-posta adresi tahmin etmek, veya — makul hiçbir şey bulamazsa — size önce düzeltme şansı vermeden güvenlik açığını herkese açık şekilde paylaşmak. Bu sonuçların hiçbiri sizin için iyi değil.
Bir de düzenleyici açı var. AB'de satılan dijital öğeli ürünlere uygulanan AB Siber Dayanıklılık Yasası, üreticilerin belgelenmiş bir güvenlik açığı işleme ve bildirim sürecine sahip olmasını gerektiriyor. security.txt uyumluluk gerekliliğinin tamamı değil, ama bu süreci kamuya keşfedilebilir kılmanın standart, beklenen yolu. WordPress siteniz AB kullanıcılarına hizmet veriyorsa veya dijital ürün satıyorsa, bir tane edinmek bu daha geniş beklentiye yönelik küçük, düşük çabalı bir adım. Bu tek dosyanın ötesinde CRA'nın tam olarak neyi beklediğine dair daha geniş resim için WordPress için AB Siber Dayanıklılık Yasası uyumluluğu rehberimize bak.
Dosyaya Gerçekte Hangi Alanlar Ait
RFC, hepsi gerekli olmayan birkaç alan tanımlıyor. İşte her birinin ne yaptığı:
Contact (gerekli, en az bir): Size nasıl ulaşılacağı. Bir e-posta (mailto:), bir rapor formu URL'si veya ikisi olabilir. Birden fazla bildirim kanalınız varsa birden fazla Contact satırı listeleyebilirsiniz.
Expires (gerekli): ISO 8601 zaman damgası. Bu, dosyayı periyodik olarak gözden geçirip yeniden onaylamanızı zorlar — yıllarca güncel olmayan iletişim bilgileriyle eski bir security.txt, hiç olmamasından tartışmalı olarak daha kötü. Gerçekçi bir şeye ayarlayın, mesela bir yıl sonrasına, ve süresi dolduğunda güncelleyin.
Encryption (opsiyonel): Araştırmacıların hassas detaylar içeren raporları göndermeden önce şifrelemesini istiyorsanız bir PGP anahtarına link.
Acknowledgments (opsiyonel): Sorunları sorumlu şekilde bildiren araştırmacıları takdir eden bir sayfaya link — bazı araştırmacıların herkese açık olarak ifşa etmek yerine bildirmeye karar vermeden önce özellikle aradığı küçük bir teşvik.
Preferred-Languages (opsiyonel): Raporları hangi dillerde okuyabildiğiniz.
Canonical (opsiyonel): Dosyanın kendisinin yetkili URL'si, siteniz birden fazla domain üzerinden erişilebilirse kullanışlı.
Policy (opsiyonel): Kapsamı, beklenen yanıt sürelerini ve araştırmacıların sizden ne bekleyebileceğini açıklayan tam güvenlik açığı bildirim politikanıza link.
| Alan | Gerekli mi? | Amacı |
|---|---|---|
| Contact | Evet | Size nasıl ulaşılacağı (e-posta veya URL) |
| Expires | Evet | Periyodik gözden geçirmeyi zorlayan ISO 8601 tarihi |
| Encryption | Hayır | Bir PGP anahtarına link |
| Acknowledgments | Hayır | Sorumlu bildirim yapan araştırmacıları takdir eder |
| Preferred-Languages | Hayır | Raporları okuyabildiğiniz diller |
| Canonical | Hayır | Birden fazla domain'den erişilebiliyorsa yetkili URL |
| Policy | Hayır | Tam bildirim politikanıza link |
WordPress'e security.txt Ekleme
WordPress'in "Ayarlar → Kalıcı Bağlantılar" yapısı çoğu URL'yi PHP üzerinden işlediğinden, /.well-known/security.txt'te statik bir dosyanın yaşaması için iki yaklaşımdan biri gerekiyor:
Seçenek A — Dosyayı doğrudan FTP/dosya yöneticisi üzerinden yükleyin. Yukarıdaki içerikle security.txt adlı bir dosya oluşturun ve sitenizin web kökündeki .well-known dizinine yükleyin (yoksa dizini oluşturun). Bu neredeyse her hostta çalışır ve WordPress'e hiç bağlı değildir, ki bu gerçekten bir avantaj — tema veya eklenti değiştirseniz bile çalışmayı sürdürür.
Seçenek B — Sizin için yöneten bir eklenti kullanın. Statik bir dosyayı manuel olarak sürdürmek, Expires alanını yıllık olarak güncellemeyi hatırlamak ve değişirlerse iletişim bilgilerini senkronize tutmak demektir. Erdo CRA Compliance, Siber Dayanıklılık Yasası'nın beklediği diğer belgelerin (güvenlik açığı bildirim politikası, SBOM) yanında, daha geniş AB uyumluluk taramasının bir parçası olarak bir security.txt dosyası üretir ve sunar — böylece üç yıl önceden unutulmuş statik bir dosya yerine tek bir yerde sürdürülür.
Ne Kadar Sürer
Elle eklemek gerçekten beş dakika sürer: bir metin editöründe dosyayı oluştur, Contact ve Expires alanlarını doldur, FTP veya dosya yöneticisi üzerinden .well-known dizinine yükle. Karmaşık bir yapılandırma, veritabanı değişikliği veya kod yazma gerekmez — bu, WordPress site sahiplerinin genellikle "bir gün yaparım" diye erteledikleri ama gerçekte hiç zaman almayan görevlerden biri.
Kimler İçin Özellikle Önemli
Bir WordPress eklentisi veya teması satıyorsan, security.txt neredeyse zorunlu — kullanıcıların güvenlik açığı bulduğunda seni bulabilmesi gerekiyor, ve bir eklenti deposu üzerinden dağıtım yapıyorsan bile kendi sitende ayrıca bir tane bulundurmak profesyonel bir sinyal. Bir ajans olarak müşteri siteleri yönetiyorsan, her müşteri sitesine ayrı ayrı eklemek yerine tek bir merkezi süreçten hepsini kapsamak zaman kazandırır — bu da statik dosya yerine bir eklentinin neden genellikle daha sürdürülebilir olduğunun bir başka nedeni — özellikle her müşteri sitesinin farklı bir kişi tarafından yönetildiği, merkezi takibin zor olduğu ve zamanla unutulmuş, güncelliğini yitirmiş dosyaların birikme riski taşıdığı durumlarda — bu tür bir dağınıklık fark edildiğinde genellikle çoktan bir yıl, hatta bazen daha da fazlası geçmiş olur.
Yaygın Hatalar
Dosyayı ekledikten sonra kontrol etmeye değer birkaç şey:
- Expires'ı güncellemeyi unutmak. Süresi dolmuş bir security.txt, olmamasından daha fazla ihmal sinyali verir. Bir takvim hatırlatıcısı koyun, veya bunu sizin için yöneten bir araç kullanın.
- Kimsenin izlemediği bir iletişim adresi kullanmak. security@domaininiz.com kimsenin kontrol etmediği bir gelen kutusuna yönlendiriyorsa, keşfedilebilirlik sorununu çözmüş ve yeni bir çıkmaz sokak oluşturmuşsunuz demektir.
- Sadece domain köküne koymak. /.well-known/security.txt mevcut standart konumdur. Kök seviyesinde bir /security.txt, eski tarayıcılar için yedek olarak izin verilir, ama sadece ona güvenmeyin.
- Bunu uyumluluk hikayesinin tamamı olarak görmek. security.txt bildirim kanalınızı keşfedilebilir kılar; bir rapor geldiğinde gerçek bir triyaj sürecine sahip olmanın yerini almaz.
- Policy alanını atlamak. Daha kapsamlı bir bildirim politikasına link olmadan, araştırmacılar beklenen yanıt sürenizi veya kapsamı bilemez — Policy alanı opsiyoneldir ama bu boşluğu hızlıca kapatır.
Özetle
security.txt, orantısız bir faydası olan beş dakikalık bir düzeltme: "sitenizde bir hata buldum, şimdi ne olacak?"ı bir çıkmaz sokaktan belgelenmiş bir sürece dönüştürür. Statik bir dosya olarak manuel ekleseniz de, bir uyumluluk aracının diğer AB belgelerinizle birlikte sürdürmesine izin verseniz de, bu, bir WordPress sitesinin benimseyebileceği en düşük çaba, en yüksek etkili güvenlik uygulamalarından biri.