WordPress güvenliği yalnızca güçlü bir parola kullanmak, güvenlik eklentisi kurmak veya giriş adresini değiştirmekten ibaret değildir. Bir WordPress sitesinin en kritik güvenlik noktalarından biri, çoğu zaman gözden kaçan wp-config.php dosyasıdır.
Veritabanı bağlantı bilgilerinden güvenlik anahtarlarına, dosya sistemi izinlerinden yönetici panelinin davranışına kadar WordPress’in birçok temel ayarı bu dosya üzerinden kontrol edilir. Bu nedenle wp-config.php dosyasının doğru yapılandırılması, özellikle kurumsal siteler, haber siteleri, WooCommerce mağazaları ve yüksek trafikli WordPress projelerinde ciddi önem taşır.
Bu rehberde wp-config.php üzerinden uygulanabilecek WordPress güvenlik önlemlerini, hangi kodun ne işe yaradığını ve hangi ayarların dikkatli kullanılması gerektiğini ele alacağız.
wp-config.php Dosyası Neden Bu Kadar Önemli?
WordPress çalışmaya başladığında ihtiyaç duyduğu temel yapılandırma bilgilerini wp-config.php dosyasından alır. Veritabanı adı, kullanıcı adı, parola, güvenlik anahtarları ve WordPress’in çalışma biçimini değiştiren çeşitli sabitler bu dosyada bulunur.
Dosyanın ele geçirilmesi durumunda saldırgan yalnızca WordPress yönetim paneline değil, doğrudan veritabanına ve site altyapısına yönelik önemli bilgilere de ulaşabilir. Bu nedenle wp-config.php güvenliği, WordPress güvenlik çalışmalarının temel parçalarından biri olmalıdır.
1. WordPress Veritabanı Güvenliğini Artırın
Varsayılan wp_ Tablo Önekini Kullanmayın
Standart WordPress kurulumunda veritabanı tabloları genellikle wp_ önekiyle oluşturulur. Örneğin kullanıcıların bulunduğu tablo çoğunlukla wp_users, ayarların tutulduğu tablo ise wp_options şeklindedir.
Farklı bir tablo öneki kullanmak SQL Injection saldırılarını tek başına engellemez. Ancak otomatik saldırı araçlarının standart WordPress tablo isimlerini tahmin etmesini zorlaştırabilir.
// Use a custom database table prefix.
$table_prefix = 'kurumsal_sistem_948_';
Dikkat: Bu işlem yeni WordPress kurulumlarında kolaylıkla yapılabilir. Çalışan bir sitede tablo önekini değiştirmek istiyorsanız yalnızca wp-config.php dosyasındaki satırı değiştirmek yeterli değildir. Veritabanındaki ilgili tabloların ve bazı veritabanı kayıtlarının da güncellenmesi gerekir.
Uzak Veritabanı Kullanıyorsanız SSL/TLS Bağlantısını Değerlendirin
WordPress ve MySQL/MariaDB aynı sunucu üzerinde değilse, uygulama ile veritabanı arasındaki bağlantının şifrelenmesi önem kazanır. Özellikle farklı sunucular veya veri merkezleri arasında bağlantı kuruluyorsa SSL/TLS kullanılmalıdır.
// Enable SSL for supported database configurations.
define('DB_SSL', true);
// Require an SSL-enabled MySQL client connection when supported.
define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL);
Bu ayarlar her hosting altyapısında aynı şekilde çalışmayabilir. Kullanılan MySQL/MariaDB sunucusunun SSL bağlantısını desteklemesi gerekir.
2. WP_ALLOW_REPAIR Ayarını Açık Bırakmayın
WordPress’in bozulmuş veritabanı tablolarını onarabilmek için yerleşik bir veritabanı onarım sistemi bulunur. Bu özellik aşağıdaki kodla etkinleştirilebilir:
// Enable only temporarily when database repair is required.
// define('WP_ALLOW_REPAIR', true);
Ancak burada önemli bir güvenlik ayrıntısı vardır. WP_ALLOW_REPAIR aktif olduğunda WordPress’in veritabanı onarım sayfasına oturum açmadan erişilebilir.
Bu nedenle veritabanı onarımı tamamlandıktan sonra bu kod mutlaka kaldırılmalı veya yukarıdaki örnekte olduğu gibi yorum satırına alınmalıdır.
3. WordPress Güvenlik Anahtarlarını Güçlendirin
WordPress kullanıcı oturumlarının ve çeşitli kimlik doğrulama işlemlerinin güvenliğini sağlamak için sekiz farklı güvenlik anahtarı ve salt değeri kullanır.
Bunlar şunlardır:
- AUTH_KEY
- SECURE_AUTH_KEY
- LOGGED_IN_KEY
- NONCE_KEY
- AUTH_SALT
- SECURE_AUTH_SALT
- LOGGED_IN_SALT
- NONCE_SALT
Bu değerlerin her WordPress kurulumu için benzersiz ve uzun karakterlerden oluşması gerekir.
define('AUTH_KEY', 'BENZERSIZ-VE-UZUN-BIR-ANAHTAR');
define('SECURE_AUTH_KEY', 'BENZERSIZ-VE-UZUN-BIR-ANAHTAR');
define('LOGGED_IN_KEY', 'BENZERSIZ-VE-UZUN-BIR-ANAHTAR');
define('NONCE_KEY', 'BENZERSIZ-VE-UZUN-BIR-ANAHTAR');
define('AUTH_SALT', 'BENZERSIZ-VE-UZUN-BIR-ANAHTAR');
define('SECURE_AUTH_SALT', 'BENZERSIZ-VE-UZUN-BIR-ANAHTAR');
define('LOGGED_IN_SALT', 'BENZERSIZ-VE-UZUN-BIR-ANAHTAR');
define('NONCE_SALT', 'BENZERSIZ-VE-UZUN-BIR-ANAHTAR');
Bir WordPress sitesinin saldırıya uğradığından şüpheleniyorsanız bu anahtarların yenilenmesi mevcut kullanıcı oturumlarının geçersiz hale gelmesini sağlayabilir. Böylece WordPress’e giriş yapmış kullanıcıların yeniden oturum açması gerekir.
4. WordPress Yönetim Panelinde HTTPS Kullanımını Zorunlu Hale Getirin
WordPress yönetim paneli ve giriş sayfası mutlaka HTTPS üzerinden kullanılmalıdır. SSL sertifikası bulunan bir sitede aşağıdaki ayar kullanılabilir:
// Force HTTPS for WordPress administration pages.
define('FORCE_SSL_ADMIN', true);
Bu ayar özellikle yönetici oturumlarının şifrelenmemiş bağlantılar üzerinden taşınmasını önlemek açısından önemlidir.
5. Cloudflare ve Reverse Proxy Kullanırken HTTPS Ayarı
WordPress sitesi Cloudflare, reverse proxy veya load balancer arkasında çalışıyorsa WordPress bazı durumlarda ziyaretçinin HTTPS kullandığını doğru algılayamayabilir.
Sonuç olarak sürekli HTTPS yönlendirmesi yapılabilir ve tarayıcıda ERR_TOO_MANY_REDIRECTS hatası görülebilir.
// Detect HTTPS connections forwarded by a trusted reverse proxy.
if (
isset($_SERVER['HTTP_X_FORWARDED_PROTO']) &&
strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false
) {
$_SERVER['HTTPS'] = 'on';
}
Proxy arkasındaki gerçek ziyaretçi IP adresini WordPress’e aktarırken ise dikkatli olunmalıdır. X-Forwarded-For başlığı yalnızca güvenilir proxy altyapısından geldiği kesin olarak biliniyorsa kullanılmalıdır.
6. WordPress Site Adresini wp-config.php Üzerinden Sabitleyin
WP_HOME ve WP_SITEURL değerleri kullanılarak WordPress’in hangi alan adı üzerinden çalışacağı doğrudan wp-config.php dosyasından belirlenebilir.
// Define the public site URL.
define('WP_HOME', 'https://www.ornek.com');
// Define the WordPress installation URL.
define('WP_SITEURL', 'https://www.ornek.com');
Bu yöntem özellikle alan adı yapısının değişmesini istemediğiniz kurumsal WordPress sistemlerinde yararlı olabilir.
7. WordPress Tema ve Eklenti Dosya Düzenleyicisini Kapatın
WordPress güvenliği için uygulanabilecek en etkili wp-config.php ayarlarından biri yönetim panelindeki tema ve eklenti dosya düzenleyicisini kapatmaktır.
Bir saldırgan yönetici hesabını ele geçirdiğinde tema veya eklenti dosyalarına PHP kodu eklemeye çalışabilir. WordPress’in kendi dosya düzenleyicisini kapatmak bu yöntemin kullanılmasını zorlaştırır.
// Disable the built-in theme and plugin file editors.
define('DISALLOW_FILE_EDIT', true);
Bu kod eklenti veya tema kurulumunu engellemez. Yalnızca WordPress yönetim panelinden PHP dosyalarının düzenlenmesini kapatır.
8. Tema ve Eklenti Kurulumunu da Tamamen Kapatmak
Daha sıkı güvenlik isteyen sistemlerde WordPress üzerinden tema ve eklenti yükleme, silme ve güncelleme işlemleri de engellenebilir.
// Disable plugin, theme and core installation/update operations.
define('DISALLOW_FILE_MODS', true);
Önemli: Bu ayar DISALLOW_FILE_EDIT ayarından çok daha kapsamlıdır. Yönetim panelinden eklenti ve tema kurulumlarını engellediği gibi WordPress güncelleme işlemlerini de etkileyebilir.
Güncellemeleri düzenli olarak WordPress panelinden yapan sitelerde yalnızca DISALLOW_FILE_EDIT kullanmak genellikle daha pratiktir.
9. WordPress’in Dış Sunuculara Yaptığı İstekleri Sınırlandırın
WordPress çekirdeği, eklentiler ve temalar çeşitli nedenlerle harici sunuculara HTTP bağlantıları gerçekleştirebilir. Çok sıkı güvenlik politikalarının uygulandığı sistemlerde bu bağlantılar sınırlandırılabilir.
// Block external HTTP requests made through the WordPress HTTP API.
define('WP_HTTP_BLOCK_EXTERNAL', true);
// Allow only approved external hosts.
define('WP_ACCESSIBLE_HOSTS', '*.wordpress.org,*.github.com,api.ornek.com');
Bu yapılandırma SSRF saldırılarının etkisini azaltmaya yardımcı olabilir ancak tüm WordPress sitelerinde kullanılmaya uygun değildir.
Ödeme sistemleri, lisans sunucuları, API servisleri, Google hizmetleri, SMTP servisleri ve üçüncü taraf eklentiler dış bağlantıya ihtiyaç duyabilir. Bu nedenle izin verilen alan adlarının doğru belirlenmesi gerekir.
10. Filtrelenmemiş HTML Kullanımını Engelleyin
WordPress’te yüksek yetkiye sahip kullanıcılar normal şartlarda bazı filtrelenmemiş HTML kodlarını içeriklere ekleyebilir. Yönetici veya editör hesabının ele geçirilmesi durumunda bu yetki kötüye kullanılabilir.
// Prevent privileged users from publishing unfiltered HTML.
define('DISALLOW_UNFILTERED_HTML', true);
Bu ayar özellikle birden fazla editörün çalıştığı kurumsal WordPress sitelerinde Stored XSS risklerini azaltmak amacıyla değerlendirilebilir.
11. Kontrolsüz Dosya Yüklemelerine İzin Vermeyin
WordPress güvenlik nedeniyle bazı dosya türlerinin medya kütüphanesine yüklenmesini varsayılan olarak engeller. Bu kontrolün kapatılması ciddi güvenlik sorunlarına yol açabilir.
// Keep WordPress file type validation enabled.
define('ALLOW_UNFILTERED_UPLOADS', false);
Özellikle SVG gibi dosyaların kontrol edilmeden yüklenmesine izin verilmemelidir. SVG kullanılması gerekiyorsa dosyaları temizleyen ve güvenli hale getiren bir sistem tercih edilmelidir.
12. WordPress Hatalarını Ziyaretçilere Göstermeyin
Canlı bir WordPress sitesinde PHP hatalarının ziyaretçilere gösterilmesi güvenlik açısından doğru değildir. Hata mesajlarında sunucu dizinleri, PHP dosya yolları, eklenti isimleri ve sistem hakkında kullanılabilecek başka bilgiler bulunabilir.
Canlı sitelerde genel yaklaşım aşağıdaki gibi olmalıdır:
// Disable WordPress debugging on production websites.
define('WP_DEBUG', false);
// Never display debug information to visitors.
define('WP_DEBUG_DISPLAY', false);
// Prevent PHP errors from being displayed.
@ini_set('display_errors', 0);
// Do not store database queries in memory.
define('SAVEQUERIES', false);
// Mark the website as a production environment.
define('WP_ENVIRONMENT_TYPE', 'production');
Bir hata araştırılıyorsa debug özelliği geçici olarak açılabilir. Ancak ziyaretçilere hata gösterilmemeli ve işlem tamamlandıktan sonra debug modu tekrar kapatılmalıdır.
13. WordPress Bellek Kullanımını Sınırlandırın
WordPress, özellikle WooCommerce, Elementor ve çok sayıda eklenti kullanılan projelerde yüksek PHP belleğine ihtiyaç duyabilir. Bellek değerleri sunucu kapasitesine uygun şekilde sınırlandırılabilir.
// Define the normal WordPress PHP memory limit.
define('WP_MEMORY_LIMIT', '256M');
// Define the maximum memory available for administrative operations.
define('WP_MAX_MEMORY_LIMIT', '512M');
Buradaki değerlerin doğrudan her siteye uygulanması doğru değildir. 1 GB RAM bulunan bir sunucu ile 32 GB RAM bulunan bir sunucunun yapılandırması doğal olarak aynı olmamalıdır.
14. WordPress Yazı Revizyonlarını Sınırlandırın
WordPress bir yazı veya sayfa güncellendiğinde eski sürümlerini revizyon olarak veritabanında saklar. Çok sık güncellenen ve binlerce içeriğe sahip sitelerde revizyon sayısı zamanla ciddi miktarda büyüyebilir.
// Store a maximum of five revisions for each post.
define('WP_POST_REVISIONS', 5);
Bu ayar her yazı veya sayfa için en fazla beş eski revizyon tutulmasını sağlar.
15. Çöp Kutusunun Otomatik Temizlenmesini Sağlayın
WordPress’te silinen içerikler doğrudan veritabanından kaldırılmaz. Önce çöp kutusuna taşınır.
Çöp kutusunda bulunan içeriklerin ne kadar süre saklanacağı aşağıdaki şekilde belirlenebilir:
// Permanently delete trashed content after seven days.
define('EMPTY_TRASH_DAYS', 7);
Özellikle yoğun içerik üreten haber sitelerinde bu ayar veritabanının gereksiz yere büyümesini önlemeye yardımcı olabilir.
16. Düzenlenen Görsellerin Eski Kopyalarını Saklamayın
WordPress içerisindeki görsel düzenleme araçları kullanıldığında sistem eski görsel dosyalarını saklayabilir. Çok sayıda görsel bulunan sitelerde bu durum zamanla disk kullanımını artırabilir.
// Replace previous edited image versions instead of keeping all copies.
define('IMAGE_EDIT_OVERWRITE', true);
Bu ayar etkinleştirildiğinde WordPress düzenlenen görsellerin eski sürümlerini sürekli olarak saklamak yerine mevcut dosyaları yönetmeyi tercih eder.
17. WordPress Multisite Yapısında Güvenliği Göz Ardı Etmeyin
Birden fazla WordPress sitesini tek kurulum üzerinden yönetmek isteyen işletmeler WordPress Multisite özelliğini kullanabilir.
// Enable the WordPress Multisite installation option.
define('WP_ALLOW_MULTISITE', true);
Ancak bağımsız WordPress kurulumlarının aynı kullanıcı tablolarını paylaşmasını sağlayan özel yapılandırmalar güvenlik açısından dikkatle değerlendirilmelidir.
Bir sistemde meydana gelen güvenlik açığının diğer WordPress kurulumlarını da etkilemesini önlemek için mümkün olduğunca uygulama ve veritabanı izolasyonu korunmalıdır.
18. wp-config.php Dosyasını public_html Dışına Taşımak
WordPress, belirli standart kurulumlarda wp-config.php dosyasını WordPress’in bulunduğu dizinin bir üst seviyesinde de arayabilir.
Örneğin WordPress aşağıdaki dizinde bulunuyorsa:
/home/kullanici/public_html/uygun sunucu yapılarında wp-config.php dosyası şu seviyede tutulabilir:
/home/kullanici/wp-config.phpBöylece yapılandırma dosyası doğrudan web kök dizininin dışında kalır.
Ancak bu işlemin her hosting mimarisinde uygulanabileceği varsayılmamalıdır. Özellikle bir hosting hesabında birden fazla WordPress sitesi bulunuyorsa dizin yapısı dikkatle kontrol edilmelidir.
19. wp-config.php Dosya İzinlerini Sıkılaştırın
wp-config.php içerisinde veritabanı kullanıcı adı ve parolası gibi kritik bilgiler bulunduğundan dosya izinleri mümkün olduğunca kısıtlı tutulmalıdır.
Sunucu yapılandırmasına bağlı olarak kullanılabilecek değerler şunlardır:
| Dosya İzni | Açıklama |
|---|---|
400 | Yalnızca dosya sahibi okuyabilir. |
440 | Dosya sahibi ve grup okuyabilir. |
600 | Dosya sahibi okuyabilir ve yazabilir. |
Hangi değerin kullanılacağı PHP’nin ve web sunucusunun hangi kullanıcı hesabıyla çalıştığına bağlıdır. Yanlış izin verilmesi WordPress sitesinin çalışmamasına neden olabilir.
20. Web Sunucusu Seviyesinde wp-config.php Erişimini Engelleyin
PHP seviyesindeki güvenlik önlemlerine ek olarak wp-config.php dosyasına doğrudan web üzerinden erişim sunucu katmanında da engellenebilir.
Nginx İçin wp-config.php Koruması
# Block direct HTTP access to wp-config.php.
location = /wp-config.php {
deny all;
access_log off;
log_not_found off;
}
Bu tür bir kural kullanıldığında wp-config.php dosyasına yapılan doğrudan HTTP istekleri sunucu seviyesinde reddedilir.
WordPress Güvenliği İçin Hangi wp-config.php Ayarları Öncelikli?
Buradaki tüm ayarları aynı anda kullanmak her WordPress sitesi için doğru değildir. Bazı yapılandırmalar yalnızca kurumsal sistemlerde veya özel sunucu mimarilerinde anlamlıdır.
Standart bir WordPress sitesi için öncelikli olarak değerlendirilebilecek temel ayarlar şunlardır:
// Disable theme and plugin source code editing from wp-admin.
define('DISALLOW_FILE_EDIT', true);
// Force HTTPS for WordPress administration.
define('FORCE_SSL_ADMIN', true);
// Prevent unrestricted file uploads.
define('ALLOW_UNFILTERED_UPLOADS', false);
// Do not display PHP or WordPress errors to visitors.
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
// Disable query logging on production websites.
define('SAVEQUERIES', false);
// Define the website as a production environment.
define('WP_ENVIRONMENT_TYPE', 'production');
// Limit stored post revisions.
define('WP_POST_REVISIONS', 5);
// Automatically clear the trash after seven days.
define('EMPTY_TRASH_DAYS', 7);
Sonuç: wp-config.php WordPress Güvenliğinin Önemli Bir Parçasıdır
WordPress güvenliğinde tek bir kod veya eklentiyle tam koruma sağlamak mümkün değildir. Güvenli bir WordPress altyapısı; güncel WordPress çekirdeği, güvenilir tema ve eklentiler, doğru dosya izinleri, güçlü kullanıcı hesapları, sunucu güvenliği, güvenlik duvarı, düzenli yedekleme ve doğru yapılandırılmış wp-config.php dosyasının birlikte kullanılmasıyla oluşturulur.
Özellikle DISALLOW_FILE_EDIT, FORCE_SSL_ADMIN, güvenlik anahtarları, hata gösteriminin kapatılması ve doğru dosya izinleri gibi önlemler pek çok WordPress sitesi için uygulanabilecek temel güvenlik adımları arasındadır.
Bununla birlikte her wp-config.php kodunu internette görüldüğü şekliyle doğrudan canlı sisteme eklemek doğru değildir. Sunucu altyapısı, kullanılan eklentiler, CDN veya Cloudflare yapılandırması ve sitenin çalışma biçimi dikkate alınarak yalnızca ihtiyaç duyulan güvenlik ayarları uygulanmalıdır.
Siz de Yorumlarda Paylaşın
Bildiğiniz diğer güvenlikle ilgili çalışmalarınızı yorumlar alanımızda yazarak paylaşabilirsiniz.
