WordPress Dosya İzinleri Rehberi: chmod 644 ve 755

Özet: WordPress sitenizin güvenliği ve düzgün çalışması, dosya ve dizin izinlerinin (file permissions) doğru ayarlanmış olmasına bağlıdır. Yanlış izinler “403 Forbidden” hatalarına, görsel yükleyememeye, sürekli FTP kimlik bilgisi isteyen güncelleme ekranlarına ve en kötüsü, saldırganların wp-config.php gibi kritik dosyaları okumasına yol açabilir. Bu rehberde dizinler için 755, dosyalar için 644, wp-config.php için 640/440 izinlerini neden ve nasıl uygulayacağınızı; izinleri SSH, WP-CLI ve cPanel/Dosya Yöneticisi üzerinden adım adım nasıl düzelteceğinizi; sahiplik (ownership) sorunlarını ve wp-config.php güçlendirme sabitlerini öğreneceksiniz.

Neden Dosya İzinleri Bu Kadar Önemli?

WordPress paylaşımlı veya VPS bir Linux sunucuda çalışır. Linux’ta her dosya ve dizinin bir sahibi, bir grubu ve üç farklı kullanıcı sınıfı için (sahip, grup, diğer) okuma, yazma ve çalıştırma izinleri vardır. Bu izinler sayısal olarak chmod komutuyla ifade edilir; 755, 644, 600 gibi üç haneli sayılar bu izin kombinasyonlarının kısaltmasıdır.

Yanlış yapılandırılmış izinler iki uçta da sorun yaratır:

• Çok kısıtlayıcı izinler (örneğin tüm dosyalar 600): WordPress arayüz üzerinden eklenti yükleyemez, görselleri wp-content/uploads dizinine kaydedemez, .htaccess dosyasını güncelleyemez ve admin tarafında “Connection Information / Bağlantı Bilgileri” formu sürekli FTP bilgisi ister.
• Çok geniş izinler (örneğin 777): Sunucudaki herhangi bir kullanıcı veya kötü amaçlı bir betik wp-config.php dosyanızı okuyabilir, içine arka kapı (backdoor) yerleştirebilir, eklentilere zararlı kod ekleyebilir veya bütün siteyi devre dışı bırakabilir. Birçok shared hosting sağlayıcısı, dosya izinleri 777 olan dizinlerdeki PHP’yi çalıştırmaz; bu da “500 Internal Server Error” sebebidir.

WordPress.org’un resmi güvenlik tavsiyesi nettir: dizinler 755, dosyalar 644, wp-config.php ise mümkün olduğu kadar daha sıkı olmalıdır. Bu rehberin kalanı, bu standardı sitenizde nasıl uygulayacağınızı pratik olarak anlatır.

Linux Dosya İzinlerine Hızlı Giriş

Bir SSH terminalinde ls -la komutunu çalıştırdığınızda her satırın başında şuna benzer bir dize görürsünüz:

-rw-r--r--  1 wpuser www-data   3245 May 14 09:16 wp-config.php
drwxr-xr-x  4 wpuser www-data   4096 May 14 09:16 wp-content

Bu dizenin ilk karakteri dosya tipini gösterir: - normal dosya, d dizin (directory), l sembolik link. Geri kalan 9 karakter üç gruba ayrılır:

• İlk üç (rwx): sahip (owner) izinleri
• Orta üç (rwx): grup (group) izinleri
• Son üç (rwx): diğer herkes (others) izinleri

Her harfin sayısal karşılığı vardır: r=4, w=2, x=1. Bir grubu özetlemek için bu sayılar toplanır. Yani rwxr-xr-x şu demektir: 4+2+1 = 7 (sahip), 4+0+1 = 5 (grup), 4+0+1 = 5 (diğer) → 755.

WordPress için en sık karşılaşacağınız değerler şunlardır:

• 755: Dizinler. Sahip okur/yazar/girer, grup ve diğer kullanıcılar okur ve girer ama yazamaz. Web sunucusunun dosya listeleyebilmesi ve uploads alt dizinlerine girebilmesi için zorunludur.
• 644: Dosyalar. Sahip okur ve yazar; grup ve diğer kullanıcılar sadece okur. Tüm temalar, eklentiler, görseller ve PHP dosyaları için varsayılan.
• 640: wp-config.php için tavsiye edilen değer (web sunucu kullanıcısı grubun bir üyesiyse). Diğer kullanıcılar dosyayı okuyamaz.
• 440 veya 400: wp-config.php için en sıkı seçenek. Sahip ve grup yalnızca okur, yazamaz; diğer kullanıcılar hiç erişemez.
• 700: Bazı backup dizinleri için. Yalnızca sahip okur/yazar/girer.

777 izninden kaçının. Bu “herkes her şeyi yapabilir” anlamına gelir ve WordPress’in hiçbir senaryosunda gerekli değildir. Bir eklenti veya tema kurulumunda 777 öneren bir kaynakla karşılaşırsanız, o kaynağı güvenmemeniz için yeterli sebepleriniz var demektir.

WordPress için Önerilen İzin Şeması

Aşağıdaki tablo, standart bir WordPress kurulumunda uygulanması gereken izinleri özetler. Bu, WordPress.org Hardening WordPress dokümanı ve geniş kabul gören shared hosting konfigürasyonlarıyla uyumludur.

Önemli not: Eğer hosting sağlayıcınız suPHP veya CGI modunda PHP çalıştırıyorsa, PHP işlemi sizin kullanıcı hesabınızla çalışır ve 644/755 izinleri yeterlidir. Bazı eski mod_php tabanlı paylaşımlı hostinglerde web sunucusu www-data veya apache gibi farklı bir kullanıcıyla çalışır ve dosyaların grubunun bu kullanıcıyla eşleşmesi (örneğin grup www-data, dosya izni 664) gerekir. Şüpheniz varsa hosting sağlayıcınıza “PHP hangi kullanıcıyla çalışıyor?” sorusunu sorun.

Mevcut İzinleri Kontrol Etme

Düzeltme öncesi sitenizin şu anki durumunu görmek için aşağıdaki yollardan birini kullanabilirsiniz.

1) SSH ile (en hızlı)

SSH erişiminiz varsa, WordPress kök dizininize girip aşağıdaki komutları çalıştırın:

# Kök dizine git
cd ~/public_html  # veya /var/www/html, /home/USER/public_html

# Dizin ve dosya sayım, en sık görülen izin değerlerini bul
find . -type d -printf '%m %p\n' | awk '{print $1}' | sort | uniq -c | sort -rn | head
find . -type f -printf '%m %p\n' | awk '{print $1}' | sort | uniq -c | sort -rn | head

# Anormal (777, 666 vb.) izinli dosyaları listele
find . -type f -perm 0777
find . -type f -perm 0666
find . -type d -perm 0777

# wp-config.php iznine özellikle bak
ls -la wp-config.php

Sağlıklı bir kurulumda find komutlarının ilki yığınla “755” dizini, ikincisi yığınla “644” dosyası göstermelidir. 777 veya 666 satırları varsa, düzeltilmesi gerekir.

2) cPanel Dosya Yöneticisi ile

cPanel kullanıyorsanız, Files → File Manager‘a girin. public_html dizinine gelin. Sağ üst köşedeki “Settings” düğmesinden “Show Hidden Files (dotfiles)” seçeneğini açın; aksi takdirde .htaccess görünmez. Sağ taraftaki “Permissions” sütununu kontrol edin; her satır 0644, 0755 gibi değerler gösterir.

3) FTP istemcisi ile

FileZilla gibi bir FTP istemcisinde dosyaya sağ tıklayıp “File permissions / File attributes” seçtiğinizde mevcut sayısal değeri görür ve değiştirebilirsiniz. Kontrol için yeterli ama büyük çaplı düzeltmeler için yavaştır.

4) WP-CLI ile

WP-CLI tek başına izinleri toplu değiştirmek için doğrudan komut sunmaz, ancak sahipliği ve site sağlığını kontrol etmek için yardımcıdır:

# Site durumu özeti
wp core verify-checksums
wp plugin list --status=active
wp theme list --status=active

# WordPress doğru kullanıcı altında mı çalışıyor?
ls -la wp-config.php | awk '{print $3, $4}'

İzinleri Adım Adım Düzeltme

Bu bölüm, en sık karşılaşılan durumu çözer: sitenizdeki dizinleri 755, dosyaları 644 yapmak ve wp-config.php‘yi sertleştirmek. Çok önemli: bu komutları çalıştırmadan önce mutlaka tam bir yedek (dosyalar + veritabanı) alın. Yanlış dizinde çalıştırılan bir find komutu, sunucudaki başka uygulamaların izinlerini de bozabilir.

Yöntem A: SSH ile (önerilen)

WordPress kök dizinine girin ve aşağıdaki komutları sırayla çalıştırın:

# 1) Doğru dizinde olduğunuzu kontrol edin (wp-config.php görmeli)
pwd
ls wp-config.php

# 2) Tüm dizinleri 755 yap
find . -type d -exec chmod 755 {} +

# 3) Tüm dosyaları 644 yap
find . -type f -exec chmod 644 {} +

# 4) wp-config.php'yi sıkılaştır (web sunucusu sizin kullanıcınızla çalışıyorsa 400 da olur)
chmod 640 wp-config.php

# 5) .htaccess ve robots.txt 644 (WP bunları güncelleyebilmeli)
chmod 644 .htaccess 2>/dev/null
chmod 644 robots.txt 2>/dev/null

# 6) Doğrulama
ls -la wp-config.php .htaccess
find . -type d -not -perm 755 | head
find . -type f -not -perm 644 | head

Son iki find komutu boş çıktı dönerse, izinleriniz beklenen standartta demektir. Eğer wp-config.php satırı çıktıda görünüyorsa, bu beklenen bir durumdur (640 bilinçli olarak ayarladık).

Yöntem B: cPanel ile (toplu değiştirme)

SSH’iniz yoksa, cPanel File Manager üzerinden manuel olarak şu adımları izleyin:

1. File Manager‘da public_html içine girin.
2. Tüm içeriği Ctrl+A ile seçin.
3. Üst menüden “Permissions” seçeneğine basın.
4. Açılan pencerede “Apply to: Directories Only” işaretleyin ve değer olarak 0755 verin. “Change Permissions” deyin.
5. Aynı seçim aktifken tekrar “Permissions” seçeneğine basın, bu sefer “Apply to: Files Only” ve değer 0644. Onaylayın.
6. Daha sonra yalnızca wp-config.php dosyasını seçin, izni 0640 yapın.

cPanel’in “Apply to Files / Directories Only” filtresi olmazsa olmazdır; aksi takdirde tüm dizinleri 644’e çekersiniz ve site açılmaz.

Yöntem C: PHP ile (acil kurtarma)

SSH ve File Manager erişiminiz aynı anda yoksa, geçici bir PHP betiğiyle izinleri düzeltebilirsiniz. Bu yöntem yalnızca acil durumlarda kullanılmalı, iş bitince betik silinmelidir.

WordPress kök dizinine fix-perms.php adıyla şu içeriği yükleyin:

<?php
// fix-perms.php — KULLANIMDAN SONRA SİL
if (php_sapi_name() !== 'cli' && !isset($_GET['runme'])) {
    exit('Eksik parametre.');
}

$root = __DIR__;
$rii  = new RecursiveIteratorIterator(new RecursiveDirectoryIterator($root));
$count = 0;
foreach ($rii as $f) {
    $path = $f->getPathname();
    if ($f->isDir()) {
        @chmod($path, 0755);
    } else {
        @chmod($path, 0644);
    }
    $count++;
}
@chmod($root . '/wp-config.php', 0640);
echo "Tamam: $count öğe güncellendi.";

Tarayıcıdan https://siteniz.com/fix-perms.php?runme=1 adresine giderek çalıştırın. İşlem bittikten sonra derhal silin; aksi takdirde dosyanın kendisi bir güvenlik zafiyetine dönüşür.

Sahiplik (Ownership) Sorunlarını Düzeltme

İzinler doğru olsa bile dosya sahibi yanlışsa WordPress yine kuruluma izin vermez. Sahiplik chown komutuyla değiştirilir; çoğu shared hostingte bu komut için root yetkisi gerekir, dolayısıyla VPS / dedicated sunucularda kullanışlıdır.

# Mevcut sahip ve grubu gör
ls -la wp-config.php

# Tüm WordPress dosyalarını wpuser:www-data yap
sudo chown -R wpuser:www-data /var/www/wpneta

# Yalnızca yükleme dizinini web sunucusu grubuna yazılabilir yap (664/775)
sudo find /var/www/wpneta/wp-content/uploads -type d -exec chmod 775 {} +
sudo find /var/www/wpneta/wp-content/uploads -type f -exec chmod 664 {} +

Burada amaç şudur: PHP web sunucu kullanıcısı (www-data) grup üyeliği üzerinden wp-content/uploads içine yazabilsin, ama kök dizine dokunamasın. Bu yaklaşım, WordPress’in görsel yükleme ve eklenti güncellemelerini sorunsuz yapmasını sağlarken çekirdek dosyalarını saldırılara karşı korur.

wp-config.php’yi Sertleştirme

wp-config.php hem veritabanı bilgilerini hem de güvenlik anahtarlarını içerir; dolayısıyla sadece dosya izninin sıkı olması yeterli değildir, içeriğinin de doğru sabitlerle güçlendirilmesi gerekir. Aşağıdaki satırları dosyaya ekleyin (mevcut /* That's all, stop editing! */ satırının üzerine gelecek şekilde):

// 1) Tema/eklenti düzenleyiciyi kapat — admin paneli üzerinden kod düzenlenemesin
define('DISALLOW_FILE_EDIT', true);

// 2) Eklenti/tema yüklemeyi kapat (üretim ortamı için; staging'de açık kalsın)
define('DISALLOW_FILE_MODS', true);

// 3) Otomatik güncelleme metodunu zorla — FTP isteğini kaldırır
define('FS_METHOD', 'direct');

// 4) Çoklu site değilse cookie domain'ini sabitle
define('COOKIE_DOMAIN', 'siteniz.com');

// 5) Salt anahtarları taze tutun: https://api.wordpress.org/secret-key/1.1/salt/
// (Aşağıdakileri yukarıdaki bağlantıdan alın)
define('AUTH_KEY',         '…64 karakter rastgele dize…');
define('SECURE_AUTH_KEY',  '…');
define('LOGGED_IN_KEY',    '…');
define('NONCE_KEY',        '…');
define('AUTH_SALT',        '…');
define('SECURE_AUTH_SALT', '…');
define('LOGGED_IN_SALT',   '…');
define('NONCE_SALT',       '…');

// 6) Veritabanı önekini varsayılan wp_'den değiştirdiyseniz iki kez kontrol edin
$table_prefix = 'wpn_';

// 7) Hata loglarını ekrana basma, dosyaya yaz
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

DISALLOW_FILE_EDIT sabiti, WordPress yönetici paneli üzerinden tema veya eklenti dosyalarını düzenleyebilen kullanıcıların bu yetkisini kapatır. Bir yönetici hesabı ele geçirilirse, saldırgan functions.php‘ye kod ekleyerek arka kapı kuramaz. FS_METHOD = 'direct' ise dosya izinleri doğruyken WordPress’in güncellemelerde “FTP bilgisi” istemesini önler; izinleriniz yanlışsa bu satır işe yaramaz, gerçek sebep izinlerdir.

.htaccess ile Ek Koruma

Kök dizindeki .htaccess dosyasına aşağıdaki kuralları ekleyerek wp-config.php, readme.html, install.php gibi hassas dosyalara doğrudan erişimi engelleyebilirsiniz:

# wp-config.php'ye dışarıdan erişimi engelle
<Files wp-config.php>
    Require all denied
</Files>

# .htaccess'in kendisine erişimi engelle
<Files .htaccess>
    Require all denied
</Files>

# WordPress sürüm bilgisi sızdıran dosyaları engelle
<FilesMatch "^(readme\.html|license\.txt|install\.php|wp-config-sample\.php)$">
    Require all denied
</FilesMatch>

# wp-content/uploads içinde PHP çalıştırılmasın
<Directory "/var/www/wpneta/wp-content/uploads">
    <FilesMatch "\.(php|phtml|php5|php7|phps)$">
        Require all denied
    </FilesMatch>
</Directory>

Üst düzey güvenlik için wp-content/uploads/.htaccess dosyasına aşağıdaki kısa kuralı da ekleyin; böylece bir saldırgan görselin içine PHP gömse bile çalıştıramaz:

<FilesMatch "\.(php|phtml|php5|php7|phps)$">
    Require all denied
</FilesMatch>

Yaygın Hatalar ve Hızlı Çözümleri

“403 Forbidden” hatası

Bir dizinin izni 700’e veya daha kısıtlayıcı bir değere düşmüşse, sunucu o dizine bakmaya yetkili değildir ve 403 döner. find . -type d -not -perm 755 komutuyla yanlış izinli dizinleri bulup düzeltin. Daha detaylı 403 analizi için WordPress 403 Forbidden Hatası rehberimize de göz atın.

“Bağlantı bilgisi” / FTP formu sürekli çıkıyor

WordPress, eklenti veya tema güncellerken kendi kullanıcısının ilgili dizinlere yazma izni olmadığını fark ederse FTP kimlik bilgisi ister. Çözüm:

1. wp-content, wp-content/plugins, wp-content/themes, wp-content/uploads dizinlerinin izinlerini 755 yapın.
2. Sahibi web sunucusu kullanıcısı veya o gruba ait bir kullanıcı olmalı.
3. wp-config.php‘ye define('FS_METHOD', 'direct'); ekleyin.

Görsel yüklenmiyor / “Unable to create directory” uyarısı

wp-content/uploads dizininin yazılabilir olması gerekir. SSH’ta:

chmod 755 wp-content/uploads
chown -R wpuser:www-data wp-content/uploads

Eğer sunucu mod_php ile çalışıyor ve PHP www-data ile koşuyorsa, uploads dizinine grup yazma da verilebilir: chmod 775 wp-content/uploads.

“Plugin update failed” / Otomatik güncelleme başarısız

Otomatik güncellemeler için WordPress, wp-content içine yazabilmelidir. İzinler 755 ve sahip doğru olduğunda bu sorun ortadan kalkar. Ayrıntılı kurulum için WordPress Otomatik Güncelleme Yapılandırması rehberimize bakabilirsiniz.

Beyaz ekran (White Screen of Death)

Kritik bir dosyanın izni okunamayacak değere düşmüşse PHP dosyayı yükleyemez ve ölümcül hatayla beyaz ekran gelir. error_log‘a bakın; “Permission denied” satırı varsa ilgili dosyayı bulup 644’e çekin. Beyaz ekran hatası rehberimiz diğer olası sebepleri de listeler.

500 Internal Server Error sonrası izinler

Bazı paylaşımlı hostingler 777 izinli PHP dosyalarını “güvensiz” sayar ve 500 döner. Çözüm dosyayı 644’e indirmektir. Konunun bütün yüzleri için WordPress 500 Internal Server Error rehberimize bakın.

Sorun Giderme Checklist

Bir sorunla karşılaştığınızda aşağıdaki sırayla ilerleyin; bu liste, deneyimli yöneticilerin ilk kontrol ettiği başlıklardan derlenmiştir.

1. Yedek aldınız mı? İzinleri değiştirmeden önce dosya ve veritabanı yedeği alın. WordPress yedekleme stratejisi için Yedekleme Rehberi.
2. Hangi sunucu modunda çalışıyorsunuz? suPHP/CGI mu, mod_php mi? Bu, hangi kullanıcının dosyalara yazacağını belirler.
3. Doğru kök dizinde misiniz? pwd ile teyit edin. find komutunu yanlış dizinde çalıştırmayın.
4. Dizinlerin tamamı 755 mi? find . -type d -not -perm 755 boş dönmeli (uploads özel durumu hariç).
5. Dosyaların tamamı 644 mi? find . -type f -not -perm 644 sadece wp-config.php (640) ve özel istisnalarınızı göstermeli.
6. wp-config.php izni 640 (veya 440/400) mı? ls -la wp-config.php ile teyit.
7. Sahip ve grup doğru mu? Hosting sağlayıcınızın belirttiği kullanıcı:grup ile eşleşmeli.
8. uploads içinde PHP dosyası var mı? find wp-content/uploads -name "*.php" komutu meşru bir eklenti dosyası dışında hiçbir şey göstermemeli — bulduklarınızı silmeden önce zararlı olup olmadığını eklenti dizininizle karşılaştırın.
9. .htaccess aktif mi? Permalink ayarlarını yeniden kaydetmek WordPress’in dosyayı yeniden oluşturmasını sağlar.
10. Güvenlik eklentinizle (Wordfence, Sucuri, iThemes Security gibi) tam tarama yaptınız mı?

WP-CLI ile Otomasyon

VPS veya dedicated sunucu kullanıyorsanız, izin kontrolünü WP-CLI ile birleştirip bir bash dosyasına dönüştürerek düzenli aralıklarla çalıştırabilirsiniz. Aşağıdaki betik, izinleri her hafta otomatik olarak standart değerlere çeker:

#!/usr/bin/env bash
# /usr/local/bin/wp-fix-perms.sh — haftada bir çalıştırın

set -euo pipefail
WP_ROOT="${1:-/var/www/wpneta}"
WP_USER="wpuser"
WP_GROUP="www-data"

cd "$WP_ROOT"

# Tüm dizinler 755, dosyalar 644
find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

# wp-config.php sıkı
chmod 640 wp-config.php

# uploads dizini grup yazılabilir
find wp-content/uploads -type d -exec chmod 775 {} + 2>/dev/null || true
find wp-content/uploads -type f -exec chmod 664 {} + 2>/dev/null || true

# Sahiplik
chown -R "$WP_USER:$WP_GROUP" "$WP_ROOT"

# WP-CLI çekirdek bütünlük kontrolü
sudo -u "$WP_USER" -- wp core verify-checksums --path="$WP_ROOT" || \
    logger -t wpneta "WP core checksum failed in $WP_ROOT"

logger -t wpneta "wp-fix-perms.sh completed for $WP_ROOT"

Crontab’a şu satırı ekleyerek haftada bir Pazartesi 03:00’da çalıştırın:

0 3 * * 1 /usr/local/bin/wp-fix-perms.sh /var/www/wpneta > /dev/null 2>&1

Güvenlik Eklentileriyle Sürekli İzleme

Manuel kontrol her zaman iyi bir refleks olsa da, sürekli izleme için bir güvenlik eklentisi şarttır. Aşağıdaki üç eklentinin tamamı dosya bütünlüğü taraması, izin denetimi ve değişiklik bildirimi sunar:

• Wordfence Security: “Wordfence Scan” sekmesi, çekirdek dosyaların bütünlüğünü kontrol eder ve yanlış izinli ya da bilinmeyen PHP dosyaları için uyarı verir. Ücretsiz sürümde temel tarama, premium sürümde gerçek zamanlı kontrol vardır.
• Sucuri Security: “Site Integrity” modülü, MD5 imzalarıyla çekirdek dosyaları karşılaştırır. Yeni veya değişmiş dosyaları haftalık raporlar.
• iThemes Security (Solid Security): “File Change Detection” özelliği, izinlerinizde veya dosya içeriklerinde anormal bir değişiklik olursa e-posta gönderir.

Hangisini seçerseniz seçin, kurulumdan sonra ilk tam taramayı sabırla bekleyin ve sonuçları gözden geçirin; ilk tarama büyük siteler için 30 dakikayı bulabilir.

Error Log İnceleme: İzin Sorununu Loglarda Görmek

“Permission denied” hatasını WordPress arayüzünde değil, error log’da görürsünüz. Apache ve PHP-FPM logları /var/log/apache2/error.log, /var/log/php-fpm/error.log veya cPanel’in ~/logs/error_log dosyasında olur. SSH’ta canlı izleme:

# Apache hata logunu son satırlarından canlı izle
tail -f /var/log/apache2/error.log

# PHP-FPM logunu izle
tail -f /var/log/php-fpm/www-error.log

# WordPress'in kendi debug log'u (wp-config.php'de WP_DEBUG_LOG açıkken)
tail -f wp-content/debug.log

“Permission denied” veya “open_basedir restriction” satırlarındaki dosya yolu, hangi izni düzeltmeniz gerektiğini söyler.

Yedekleme ve Güncelleme Disiplini

Yanlış izinler genellikle başka bir hatayla birlikte gelir (bir eklenti güncellemesinden sonra, manuel taşıma sonrası, hacklenme sonrası temizlik sırasında). İzin sorununu önlemenin en sağlam yolu, üç ayağı olan bir disiplin oluşturmaktır:

1. Düzenli yedek: Günlük dosya + veritabanı yedeği, en az 30 gün geriye dönük. Yedekleri sunucudan farklı bir konumda saklayın.
2. Staging ortamı: Eklenti ve tema güncellemelerini önce staging’de deneyin; izinlerin staging’de bozulması canlı siteyi etkilemez.
3. Sürüm kilidi: Çekirdek güncellemeleri için WP_AUTO_UPDATE_CORE sabitini “minor” değerinde tutun ve büyük sürümleri kendi disiplininizle yükseltin. Detaylar için Otomatik Güncelleme Yapılandırması rehberine bakın.

Sık Sorulan Sorular (SSS)

Tüm dosyaları 777 yaptım, site şu an çalışıyor. Sorun ne olabilir?

Sorun olmaması, sorun olmadığı anlamına gelmez. 777 izinli bir wp-config.php, sunucudaki başka herhangi bir hesabın (paylaşımlı hostingte komşunuzun) dosyanızı okumasına izin verir. Veritabanı kullanıcı adı ve şifresi açıktadır. Mümkün olan en kısa sürede 644/755 standardına dönün.

chmod 755 mi 750 mi daha güvenli?

Eğer web sunucusu kullanıcısı dosyanın grubuna üye değilse, 750 (sahip:rwx, grup:r-x, diğer: —) izni sunucunun dizine girememesine ve 403 hatasına yol açar. Genel kural: web sunucu kullanıcısı grubun üyesiyse 750/640 daha güvenli; değilse 755/644 ile devam edin.

wp-config.php’yi 400 yaparsam WordPress çalışır mı?

Genelde evet, çünkü PHP dosyayı sahip izniyle (4 = okuma) okur ve write yapmaz. Ancak bazı güvenlik eklentileri veya kurulum sihirbazları yazma denemesi yapabilir; bu durumlarda eklenti hata verir. 640 dengeli seçenektir.

Hosting sağlayıcım izinleri kendiliğinden 755/644’e çekiyor. Yine de manuel yapmama gerek var mı?

Bazı paylaşımlı hostingler kullanıcının diğer kullanıcıların dosyalarına erişimini engellemek için bir “Permission Reset” çalıştırır. Bu varsayılan değerleri 644/755’e çekse de wp-config.php‘yi 640’a düşürmez. Kritik dosyaları manuel olarak sıkıştırmak hâlâ sizin sorumluluğunuzdadır.

İzinleri düzelttim ama 403 hâlâ geliyor. Ne yapayım?

Sahiplik (ownership) yanlış olabilir. ls -la ile dosyanın sahibini kontrol edin. Sağlıklı bir kurulumda sahip, sizin SSH/cPanel kullanıcı adınız olmalıdır. Yanlışsa chown -R kullanici:grup . ile düzeltin (root yetkisi gerekir).

cPanel “permissions” sütunu kırmızı renkte gösteriyor. Bu ne demek?

cPanel, kabuk yorumlamasına göre “olağandışı” izinleri renklendirir; özellikle 777 veya yazma izni olan dizinler kırmızı görünür. Bunun “bilgi amaçlı uyarı” olduğunu ve sizin müdahale etmenizi beklediğini bilin.

WP-CLI yok, sadece FTP’m var. Toplu chmod yapabilir miyim?

FileZilla “File permissions” diyaloğunda “Recurse into subdirectories” ve “Apply to files only / directories only” seçenekleri vardır. Bu kombinasyonla 644 (dosya) ve 755 (dizin) toplu olarak uygulanabilir. SSH kadar hızlı değildir ama güvenlidir.

Yeni bir WordPress kurulumunda izinler nasıl gelir?

Çoğu modern hosting kontrol panelinin oto-kurulumu (Softaculous, WordPress Toolkit vb.) 755/644 standartlarını uygular ve wp-config.php‘yi 640’a çeker. Yine de kurulum sonrası bir kez kontrol etmek iyi bir alışkanlıktır.

Kaynak Önerileri

• WordPress.org — Hardening WordPress (resmi güvenlik dokümanı, “Changing File Permissions” bölümü)
• WPNeta — WordPress Yedekleme Rehberi
• WPNeta — WordPress Sitem Hacklendi: 7 Acil Adım
• WPNeta — WordPress İki Faktörlü Doğrulama (2FA) Kurulumu
• WPNeta — WordPress Otomatik Güncelleme Yapılandırması

Sonuç

Dosya izinleri WordPress güvenliğinin görünmez ama kritik temelidir. Dizinler için 755, dosyalar için 644 ve wp-config.php için 640/440 standardını tutmak; sahipliği doğru kullanıcıya bağlamak; .htaccess ile hassas dosyalara erişimi kapatmak ve DISALLOW_FILE_EDIT gibi sabitleri eklemek, sitenizi yaygın saldırı yüzeylerinin büyük çoğunluğuna karşı korur. Bu rehberdeki komutları haftada bir cron işiyle veya manuel olarak çalıştırmayı alışkanlık haline getirin; bir güvenlik eklentisiyle bütünleştirin; ve her büyük değişiklik öncesinde mutlaka yedek alın. Böylece bir gün sitenize bir saldırı geldiğinde değil, geldiği saat farkına varır ve birkaç dakika içinde temiz haline geri dönebilirsiniz.