wp-config.php güvenliği, WordPress kurulumunda en hassas yapılandırma dosyasını korumakla başlar. Bu dosya veritabanı bağlantı bilgilerini, kimlik doğrulama anahtarlarını ve çalışma ayarlarını içerebilir. Yanlış izin, herkese açık yedek veya üretimde açık hata günlüğü, tek bir dosyanın ötesinde siteyi etkileyebilir. Güvenli yaklaşım; erişimi sınırlamak, sırları ayrı korumak, değişiklikleri test etmek ve kurtarma planı hazırlamaktır. Aşağıdaki adımlar WordPress’in resmi yönetim ve güvenlik belgeleriyle karşılaştırılmıştır.
wp-config.php nedir, neden korunur?
WordPress çekirdeği siteyi başlatırken wp-config.php dosyasındaki ayarları okur. Genellikle WordPress kurulumunun kök dizinindedir. Veritabanı adı, kullanıcı adı, parola ve sunucu bilgisi burada bulunabilir. Kimlik doğrulama anahtarları ve salt değerleri de kurulumun oturum mekanizmasına katkı sağlar. Dosyanın içeriğini ele geçiren kişi, diğer güvenlik koşullarına bağlı olarak veritabanına erişim veya oturumlara yönelik saldırı için önemli bilgi elde edebilir. Bu yüzden dosyanın kendisi kadar kopyaları ve yedekleri de korunmalıdır.
Tek başına URL’den /wp-config.php isteğinin boş sayfa döndürmesi güvenliğin tamamlandığını ispatlamaz. PHP düzgün çalışırken dosya yorumlanır; yanlış web sunucusu yapılandırması, PHP işleyici arızası veya yanlışlıkla oluşturulmuş .bak, .old, .txt gibi kopyalar kaynak kodu açığa çıkarabilir. Erişim kontrolünü sunucu düzeyinde ve dosya izinleriyle birlikte ele alın. Kaynak kodu görüntüleme testini gerçek sırları dışarı aktarmadan yapın; üçüncü taraf araçlara yapılandırma dosyası yüklemeyin.
Değişiklikten önce yedek ve test ortamı
Bir sözdizimi hatası WordPress’in açılmasını engelleyebilir. Değişiklikten önce dosyanın güvenli bir yedeğini alın ve geri yükleme yolunu test edin. Yedek açık web dizininde veya herkese açık depoda kalmamalıdır. Veritabanı yedeği ayrı bir konudur; yapılandırma dosyasının önceki çalışan sürümü de gerektiğinde geri dönebileceğiniz biçimde saklanmalıdır. Kopyayı e-posta ekiyle veya ekip sohbetine düz metin olarak göndermek gizli bilgileri gereksiz yere çoğaltır.
Mümkünse önce staging ortamında deneyin. Staging dosyasına üretim veritabanı parolasını kopyalamayın; ayrı veritabanı kullanın ve ortamın erişimini sınırlayın. Değişiklik planına uygulanacak satır, beklenen etki, kontrol adımı ve geri dönüş işlemini yazın. Hosting paneli ya da SFTP ile çalışırken doğru site dizinini doğrulayın; aynı hesapta birden çok WordPress kurulumu bulunabilir. Büyük dosya değişiklikleri yerine küçük ve izlenebilir adımlar tercih edin.
Dosya izinleri ve sahiplik
WordPress’in dosya izinleri belgesi wp-config.php için daha sıkı izinler önerir; örnek olarak 400 veya 440 verir. Bu sayılar evrensel bir “yapıştır ve çalıştır” çözümü değildir. PHP işleminin hangi kullanıcı ve grupla çalıştığına göre 400 dosyayı okunamaz hâle getirebilir. Önce mevcut sahipliği, web sunucusu kullanıcısını ve barındırma sağlayıcısının modelini öğrenin. Hedef, dosyayı yalnızca gerekli süreçlerin okuyabilmesi ve gereksiz süreçlerin yazamamasıdır.
777 veya herkese yazılabilir izinler güvenli seçenek değildir. Paylaşımlı hosting, PHP-FPM, container ve yönetilen WordPress hizmetlerinde izin yönetimi farklı olabilir. Sunucu erişiminiz yoksa panelin dosya yöneticisindeki izinleri hosting desteğiyle teyit edin. Bir izin değişikliğinden hemen sonra hem ön yüzü hem yönetim panelini kontrol edin. Hata çıkarsa rastgele izin genişletmek yerine sahiplik ve işlem kullanıcısını inceleyin.
Web üzerinden doğrudan erişimi engelleme
WordPress güvenlik rehberi Apache ve .htaccess kullanılan kurulumlar için wp-config.php erişimini reddeden bir kural örneği verir. Nginx veya başka web sunucusunda Apache kuralı çalışmaz; eşdeğer kısıtlamayı ilgili sunucu yapılandırmasında uygulamak gerekir. Yönetilen hosting zaten koruma sağlıyor olabilir. Dosyayı korumak için sunucu yapılandırmasını değiştirecekseniz önce etkin web sunucusunu ve kuralın uygulandığı dizini doğrulayın.
<Files "wp-config.php">
Require all denied
</Files>Bu örnek yalnızca Apache’nin ilgili yapılandırmayı okuduğu ortam içindir. Kuralı koyduktan sonra başka sayfalarda beklenmedik 403 veya 500 hatası oluşup oluşmadığını test edin. Aynı korumayı yedek dosyaları için de düşünün: wp-config.php.zip veya editörün bıraktığı geçici dosya gibi farklı adlar tek dosyaya yönelik kuraldan kaçabilir. En güvenlisi sır içeren kopyaları web kökünde tutmamaktır.
Dosyayı web kökünün dışına taşımak gerekir mi?
WordPress’in sertleştirme belgesi, dosyanın WordPress kurulumunun bir üst dizininde bulunabileceğini açıklar. Ancak bu her mimaride otomatik olarak daha güvenli değildir. WordPress’in kurulu olduğu dizin ile web sunucusunun public kökü aynı olmayabilir; container ve paylaşımlı hostingte üst dizin başka sitelerle paylaşılabilir. WordPress belgesi de yanlış taşınmanın yeni riskler yaratabileceğini belirtir. Bu adımı yalnızca dizin yapısını ve erişim modelini anladıktan sonra staging ortamında deneyin.
Taşıma öncesi dosyayı kimin okuyacağı, yedekleme yazılımının hangi yolu izleyeceği ve yeni sürüm dağıtımlarında dosyanın nasıl korunacağı belirlenmelidir. Sitede hata oluşursa eski çalışan konuma dönebilmelisiniz. Dosyayı taşımak, zayıf parola, açık eklenti veya herkesin okuyabildiği yedek dosya gibi diğer sorunları ortadan kaldırmaz. Kontroller birbirini tamamlar.
Veritabanı bilgilerini ve sırları koruma
DB_NAME, DB_USER, DB_PASSWORD ve DB_HOST gibi değerler veritabanı bağlantısında kullanılır. Bunları örnek kod paylaşırken gerçek değerlerle göstermeyin. Sürüm kontrolüne alınmış bir repoda dosya yanlışlıkla yayımlandıysa yalnızca son commit’ten silmek yeterli olmayabilir; geçmiş kopyalar ve erişen kişiler değerlendirilmelidir. İfşa edilen parolayı uygun süreçle değiştirin, eski erişimleri kapatın ve uygulamanın yeni bilgiyle bağlandığını doğrulayın. Burada amaç dosyanın adını gizlemekten çok sırların erişimini yönetmektir.
Veritabanı kullanıcısına yalnızca uygulamanın gerektirdiği yetkileri verin. Kurulum veya yükseltme sırasında gereken yetkiler, normal çalışma zamanındaki gereksinimlerden farklı olabilir. Yönetilen hizmette bu ayrımı hosting desteğiyle konuşun. Veritabanı parolasını değiştirirken önce yeni bağlantıyı staging ortamında test edin; üretimde değişiklik penceresi ve geri dönüş planı hazırlayın. Parolanın ekran görüntüsü, destek talebi veya açık günlüklerde bulunmadığını kontrol edin.
Üçüncü taraf API anahtarları da yapılandırma dosyasında tutuluyorsa aynı disiplin geçerlidir. Anahtarların yetkilerini daraltın, mümkünse farklı ortamlar için ayrı anahtar kullanın ve kullanım günlüklerini izleyin. Bir anahtar sızdığında hangi hizmete bağlı olduğunu ve nasıl iptal edileceğini bilmek müdahaleyi hızlandırır. Her sır için aynı değişiklik sırası geçerli olmayabilir; kullanılan hizmetin belgesine göre hareket edin.
Kimlik doğrulama anahtarları ve salt değerleri
WordPress kurulumunda AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY ve ilgili SALT değerleri yer alır. Bunlar tahmin edilebilir örnek dizeler olarak bırakılmamalıdır. Resmi WordPress kaynakları benzersiz değer üretme yaklaşımını açıklar. Mevcut değerlerin sızdığını düşünüyorsanız yenileme planı yapın. Bu değişiklik oturum doğrulamasını etkileyebileceği için kullanıcıların tekrar giriş yapması gerekebilir; özellikle yönetici erişimini ve bakım zamanını hesaba katın.
Anahtarları değiştirirken eski dosyanın güvenli yedeğini ve yeni dosyanın doğru sözdizimini kontrol edin. Değerleri başkasına göndermek veya çevrimiçi rastgele bir dönüştürücüye yapıştırmak doğru değildir. WordPress’in resmi kaynaklarına başvurun. Anahtar yenilemesi güçlü hesap parolaları, çok faktörlü kimlik doğrulama ve güncel eklentilerin yerine geçmez; farklı riskleri azaltan kontrollerdir.
Yönetim panelindeki dosya editörünü kapatma
WordPress yönetim paneli bazı kurulumlarda tema ve eklenti dosyalarını düzenlemeye izin verir. Yönetici hesabı ele geçirilirse bu özellik kod değiştirme yolunu kolaylaştırabilir. Resmi güvenlik belgesi, gerektiğinde DISALLOW_FILE_EDIT sabitini kullanmayı anlatır. Bu ayar paneldeki ilgili dosya editörünü devre dışı bırakır; SFTP veya sürüm kontrolüyle yapılan güncellemeleri kendiliğinden engellemez. Kod değişikliği iş akışınız panel editörüne dayanıyorsa önce alternatif dağıtım yolunu hazırlayın.
define( 'DISALLOW_FILE_EDIT', true );Bu satırı WordPress’in yapılandırma dosyasındaki uygun bölüme, yükleme tamamlanmadan önce ekleyin. Aynı sabiti birden fazla yerde tanımlamayın. Daha geniş bir ayar olan DISALLOW_FILE_MODS, eklenti ve tema kurulum/güncelleme işlevlerini de etkiler. Bunu sırf dosya editörünü kapatmak için gelişigüzel açmayın; bakım ve otomatik güncelleme iş akışınızın sonucu değişebilir. Değişiklik sonrası yönetici panelinde beklenen menü durumunu ve normal güncelleme yolunu doğrulayın.
Hata ayıklama günlükleri üretimde nasıl yönetilir?
WP_DEBUG ve WP_DEBUG_LOG geliştirme ortamında yararlı olabilir. Resmi WordPress belgesi, canlı sitelerde debug araçlarının sürekli açık tutulmasını önermiyor. WP_DEBUG_LOG etkinse varsayılan günlük wp-content/debug.log dosyasına yazılabilir; hata metinleri dosya yolları, sorgular veya başka hassas ayrıntılar içerebilir. WP_DEBUG_DISPLAY kapalı olsa bile log dosyasının webden erişilebilir olup olmadığını ayrıca kontrol edin. Görüntülemeyi kapatmak dosyanın güvenli saklandığı anlamına gelmez.
Kısa süreli sorun giderme gerekiyorsa kontrollü bakım penceresi seçin, günlük erişimini sınırlandırın ve iş bitince debug ayarlarını kapatın. Günlük dosyasını güvenli yerde saklama ve saklama süresi belirleme kararı hosting düzenine bağlıdır. Kamuya açık günlük URL’si tespit edilirse dosyayı erişime kapatın, neyin açığa çıktığını değerlendirin ve gereken sırları değiştirin. Canlı hata mesajını ziyaretçilere göstermemek için PHP’nin kendi görüntüleme ayarlarını da gözden geçirin.
WP_ALLOW_REPAIR neden geçici tutulur?
WP_ALLOW_REPAIR, veritabanı onarım ekranını etkinleştirir. WordPress’in resmi API belgesi, bu ekranın veritabanı bozukken oturum açamama olasılığı nedeniyle giriş gerektirmeden erişilebildiğini belirtir. Bu yüzden kalıcı güvenlik ayarı olarak bırakılmaz. Gerekli bakım tamamlandıktan sonra sabiti kaldırın veya devre dışı bırakın ve URL’nin beklenen şekilde kapandığını doğrulayın. Onarımın tek başına veri yedeği yerine geçmediğini unutmayın.
Yedeklerin ve geçici kopyaların güvenliği
Yapılandırma dosyasının korunan aslı kadar yedekleri de önemlidir. Dosya yöneticisinin oluşturduğu wp-config.php.bak, sıkıştırılmış arşiv, otomatik yedek eklentisinin paketi veya geliştiricinin masaüstündeki kopya erişilebilir olabilir. Açık web dizinindeki bir yedek, asıl PHP dosyasından daha kolay indirilebilir. Eski kopyaları düzenli tarayın; gerekli olanları erişimi sınırlı bir yedek konumuna taşıyın. Yedekleri rastgele silmeden önce geri yükleme zincirini anlayın.
Yedek çözümünde şifreleme, erişim yetkisi, saklama süresi ve geri yükleme testi birlikte değerlendirilir. Hosting panelinde “yedek alındı” mesajı görmeniz dosyanın doğru kopyalandığını veya kullanılabilir olduğunu garanti etmez. Küçük bir geri yükleme denemesi, acil durumda kayıp dosya aramaktan daha değerlidir. Yedek depolama hesabı ele geçirilirse yapılandırma dosyasındaki sırların da ele geçirilebileceğini hesaba katın.
Güvenli değişiklik için adım adım kontrol
İlk adım kurulumun gerçek wp-config.php yolunu bulmaktır. Hosting paneli, SFTP veya dağıtım yapısı üzerinden dosyanın hangi sürüme ait olduğunu doğrulayın. İkinci adım mevcut izin ve sahipliği kaydetmek, dosyayı güvenli konuma yedeklemek ve geri yükleme yolunu test etmektir. Üçüncü adım yapmak istediğiniz tek değişikliği staging ortamında uygulamaktır. PHP sözdizimini uygun araçla kontrol edin; dosyada eksik noktalı virgül veya yanlış tırnak tüm siteyi etkileyebilir.
Dördüncü adım, staging ortamında ön yüz, giriş, yönetim paneli, form gönderimi ve zamanlanmış işlemleri örneklemektir. Önbellek kullanan sitelerde yalnızca önbellekten gelen ana sayfaya bakmayın; WordPress’in gerçekten çalıştığını gösteren bir oturum açma veya yönetim işlemi de deneyin. Beşinci adım canlı ortamda bakım penceresi içinde aynı değişikliği uygulamak ve sonuçları hemen kontrol etmektir. Sorun görülürse önceden kaydettiğiniz önceki çalışan dosyaya dönün.
Son adımda geçici kopyaları ve gereksiz hata ayıklama ayarlarını kaldırın, değişiklik kaydını güncelleyin ve birkaç saat günlükleri izleyin. Güvenlik ayarı uyguladıktan sonra sitenin ayakta kalması kadar amaçlanan kısıtlamanın gerçekten çalışması da önemlidir. Örneğin panel dosya editörünün kapandığını veya yedek URL’sinin erişilemediğini doğrulayın. Yetkisiz kişilerin erişimini test ederken gerçek gizli değerleri çıktı olarak kaydetmeyin.
Yaygın hatalar ve doğru yaklaşım
“400 izni herkese uygundur” varsayımı
Yanlıştır. Dosyayı okuyacak PHP kullanıcısı ve dosyanın sahibi kurulumdan kuruluma değişir. Resmi belgelerde 400 ve 440 örnekleri bulunsa da önce hostingin işlem modelini kontrol edin. Aksi halde site veritabanına bağlanamaz. İzin sıkılaştırma kontrollü test gerektirir.
Dosyayı taşımayı tek başına güvenlik çözümü saymak
Üst dizine taşıma desteklenen bir seçenek olabilir; fakat dizin paylaşımı ve dağıtım yapısı uygunsuzsa risk oluşturur. Erişim yetkileri, yedekler ve web sunucusu kuralları ayrıca incelenmelidir. Taşıma sonrası site çalışsa bile yedekleme ve sürüm değiştirme süreçleri test edilmelidir.
Debug ekranını kapatınca günlüğün güvende olduğunu sanmak
WP_DEBUG_DISPLAY ve WP_DEBUG_LOG farklı konuları yönetir. Ziyaretçiye hata göstermemek, log dosyasının webden indirilemeyeceği anlamına gelmez. Logun konumunu, dosya izinlerini ve erişim kurallarını ayrı doğrulayın.
Parolayı repodan silince sızıntının bittiğini düşünmek
Geçmiş commit, çatallanmış depo, CI kaydı veya indirilen arşiv aynı değeri saklıyor olabilir. Gerçek bir ifşa durumunda parolayı ve ilgili anahtarları uygun sırayla yenileyin; erişim günlüklerini gözden geçirin. Kodu temizlemek ve sırrı döndürmek birbirini tamamlar.
Sık sorulan sorular
wp-config.php silinirse ne olur?
WordPress temel yapılandırmasını bulamaz ve site düzgün çalışmayabilir. Dosyayı güvenli yedekten geri yükleyin. Yeni dosya oluştururken veritabanı ve güvenlik anahtarlarını doğrulayın; gerçek sırları destek forumuna yapıştırmayın.
Dosyanın adını değiştirmek güvenliği artırır mı?
WordPress’in beklediği yapılandırma akışını bozabileceğinden dosya adını rastgele değiştirmeyin. Etkili koruma doğru konum, erişim sınırı, izinler ve güvenli yedeklerden gelir. Gizleme tek başına güvenlik denetimi sayılmaz.
wp-config.php hangi dizinde olmalı?
Normalde WordPress kurulumunun kök dizinindedir. Resmi belge, bir üst dizini de desteklenen olasılık olarak açıklar. Web kökü ile uygulama kökü farklıysa doğru yol kuruluma göre değişir. Dosyayı taşımadan önce staging testi yapın.
DISALLOW_FILE_EDIT güncellemeleri engeller mi?
Bu ayar panel içi tema ve eklenti dosya editörünü hedefler. Daha geniş DISALLOW_FILE_MODS ayarı kurulum ve güncelleme işlevlerini etkileyebilir. İkisini karıştırmayın; bakım iş akışınızı kontrol edin.
Güvenlik anahtarları ne zaman değiştirilir?
Sızıntı şüphesi, yetkisiz erişim veya planlı güvenlik bakımı sırasında değerlendirilebilir. Değişim oturumları etkileyebilir; kullanıcıları bilgilendirmek ve yönetici erişimini test etmek gerekir. Tek başına anahtar yenilemek olay incelemesini bitirmez.
Sonuç
wp-config.php güvenliği tek bir satır ayardan ibaret değildir. Dar dosya izinleri, web erişim engeli, sırların korunması, güvenli yedek ve kontrollü dağıtım birlikte çalışır. Önce kurulumun gerçek yapısını anlayın, değişiklikleri staging ortamında deneyin, canlıda etkisini doğrulayın ve geri dönüş yolunu hazır tutun. Böylece hem dosyanın ifşa riskini azaltır hem de güvenlik işlemi nedeniyle sitenin kapanmasını önlersiniz.
Resmi kaynaklar: WordPress wp-config.php rehberi, WordPress güvenlik sertleştirme, Dosya izinleri, Hata ayıklama ve wp-config.php API belgesi.
Düzenli gözden geçirme takvimi
İlk kurulumda yapılan kontrol yıllarca geçerli kalmaz. Hosting geçişi, PHP sürümü değişikliği, yeni yedek eklentisi veya dağıtım otomasyonu dosyanın erişim yolunu değiştirebilir. Üç aylık bir güvenlik gözden geçirmesinde dosya sahibini ve izinlerini, webden erişilebilen kopya olup olmadığını, etkin debug ayarlarını, yedek saklama konumunu ve yönetici hesaplarını kontrol edin. Gizli değerleri rapora yazmak yerine yalnızca kontrolün sonucunu ve sorumlusunu kaydedin. Bir risk saptandığında etkilenen sırları belirleyip önceliklendirin.
Olay müdahalesi için de kısa bir liste tutun: erişimi kısıtla, kopyaları bul, ilgili parolaları yenile, oturumları değerlendir, günlükleri incele ve çalışan siteyi tekrar test et. Bu adımlar her olayda aynı sırayla uygulanmayabilir; erişim kesintisi riski ve barındırma hizmetinin özellikleri kararı etkiler. Önceden hazırlanmış iletişim ve geri alma planı, panik hâlinde dosyayı silmekten veya izinleri herkese açmaktan daha güvenlidir.
