WordPress Dosya ve Klasor Izinleri Nasil Ayarlanir

WordPress bir sitede sürekli iki uçlu bir gerilim yaşar. Bir yanda eklentilerin, temaların ve WordPress çekirdeğinin çalışabilmesi için belirli dosyalara yazma yetkisi olması gerekir: güncelleme indirilmeli, önbellek yazılmalı, yüklenen görseller wp-content/uploads altına kaydedilmelidir. Diğer yanda ise bu yazma yetkisi ne kadar geniş verilirse, ele geçirilmiş bir hesabın veya kötü niyetli bir betiğin sitenize kalıcı bir arka kapı bırakması da o kadar kolaylaşır. İşte dosya izinleri tam da bu iki ucun buluştuğu yerde durur: doğru ayarlandığında hem site sorunsuz çalışır hem de olası bir sızıntının etkisi sınırlı kalır.

Yıllardır barındırma tarafında ele geçirilmiş WordPress kurulumlarını temizleyen biri olarak söyleyebilirim ki en sık gördüğüm hata, bir "Permission denied" ya da "Dizin yazılabilir değil" uyarısını görüp paniğe kapılan kullanıcının her şeyi chmod 777 yapıp geçmesidir. Bu, kısa vadede sorunu çözer ama sitenizi paylaşımlı sunucudaki herkese ardına kadar açar. Bu rehberde WordPress için önerilen izin şemasını (klasörler 755, dosyalar 644, wp-config.php için 600), bu izinleri FTP ve SSH ile nasıl uygulayacağınızı, wp-content gibi özel durumları, 777'nin neden bir tuzak olduğunu ve asıl sorunun çoğu zaman izin değil sahiplik olduğunu adım adım ele alacağız. Linux izin modeline hiç aşina değilseniz, önce Linux dosya izinleri yazımız iyi bir temel oluşturur.

WordPress İçin Önerilen İzin Şeması#

WordPress'in resmî belgeleri ve yılların pratiği bizi net bir standarda götürür. Aşağıdaki tablo, tipik bir kurulumda hangi bileşene hangi iznin verileceğini özetliyor:

Bu değerlerin mantığı basit ve tutarlıdır. Dizinlerin 755 olmasının sebebi, web sunucusu prosesinin (Apache veya Nginx tarafında genelde www-data ya da nginx kullanıcısı) o dizine "girip" (x izni) içindeki dosyaları listeleyip okuyabilmesi gerektiğidir; ama dizin dışındaki kullanıcıların oraya yeni dosya yazmasına (w) gerek yoktur. Sıradan dosyaların 644 olması ise "herkes okuyabilir ama yalnızca sahibi değiştirebilir" anlamına gelir — bir PHP dosyası tarayıcıya servis edilmek için okunur, çalıştırma iznine (x) ihtiyaç duymaz.

Burada kritik bir ayrım var: dosyalara asla toptan x (çalıştırma) izni vermeyin. WordPress dosyalarının çalışması, dosyanın kendisinin "çalıştırılabilir" olmasıyla değil, PHP yorumlayıcısının o dosyayı okuyup yürütmesiyle olur. Yani bir .php dosyasına çalıştırma izni eklemek işe yaramadığı gibi, izin hijyeninizi de bozar. Sekizli değerlerin (4=okuma, 2=yazma, 1=çalıştırma) nasıl hesaplandığını daha derinlemesine görmek isterseniz Linux dosya izinleri rehberimizde rwx modelini adım adım çözümlüyoruz.

wp-config.php Neden Ayrı ve Daha Sıkı#

WordPress kurulumunuzdaki en hassas tek dosya wp-config.php'dir. Bu dosya veritabanı kullanıcı adınızı, veritabanı şifrenizi, tablo önekini ve güvenlik anahtarlarını (AUTH_KEY, SECURE_AUTH_KEY vb.) düz metin olarak içerir. Bu bilgiler bir saldırganın eline geçerse, sitenizin veritabanına doğrudan bağlanıp yönetici hesabı ekleyebilir ya da tüm içeriğinizi silebilir.

Bu yüzden wp-config.php, sıradan bir 644 dosyasından daha sıkı korunmalıdır. Önerilen değer 600'dür (rw-------) — yani yalnızca dosyanın sahibi okuyup yazabilir, grup ve diğer herkese tamamen kapalıdır:

chmod 600 wp-config.php

Bazı paylaşımlı barındırma yapılandırmalarında, web sunucusu dosyayı sahibinizden farklı bir kullanıcı olarak okumak zorunda kalabilir; bu tür durumlarda 600 sitenin çalışmasını engelliyorsa 640 (rw-r-----, sahip okur-yazar, grup yalnızca okur) bir uzlaşma noktasıdır. Ancak paylaşımlı bir sunucuda 644 gibi "diğer herkese açık" bir izin, aynı sunucudaki başka bir hesabın veritabanı kimlik bilgilerinizi okumasına yol açabileceği için kaçınılması gereken bir değerdir.

wp-config.php'yi web erişimine tamamen kapatmak isterseniz, dosya izninin yanında bir de web sunucusu kuralı ekleyebilirsiniz. Apache/.htaccess tarafında:

# wp-config.php dosyasına doğrudan HTTP erişimini engelle
<Files wp-config.php>
    Require all denied
</Files>

Nginx kullanıyorsanız aynı korumayı sunucu bloğunuza şu şekilde eklersiniz:

# Hassas dosyalara doğrudan erişimi reddet
location ~* /(wp-config\.php|\.htaccess)$ {
    deny all;
}

Bu iki katman birbirini tamamlar: dosya izni sunucu içindeki diğer kullanıcılara karşı, web sunucusu kuralı ise doğrudan tarayıcıdan yapılan isteklere karşı korur. WordPress güvenliğini bütünsel olarak ele aldığımız WordPress güvenliği yazısında bu tür katmanlı savunmaların tümünü bir arada bulabilirsiniz.

wp-content ve uploads: Özel Durumlar#

WordPress'in en çok yanlış anlaşılan klasörü wp-content ve onun altındaki uploads dizinidir. Kafa karışıklığının kaynağı şu: WordPress'in görsel yükleyebilmesi, eklenti kurabilmesi ve önbellek yazabilmesi için bu dizinlere yazma yetkisi olması gerekir. Birçok kullanıcı bunu görünce refleks olarak chmod -R 777 wp-content yapar. Bu yanlıştır ve gereksizdir.

Doğru çözüm izni gevşetmek değil, sahipliği ayarlamaktır. Eğer wp-content ve altındaki dizinlerin sahibi web sunucusu kullanıcısıysa (www-data, nginx ya da paylaşımlı barındırmada sizin kendi hesap kullanıcınız), standart 755 dizin ve 644 dosya izinleri yazma için fazlasıyla yeterlidir — çünkü yazma yetkisi (w) zaten dosyanın sahibine açıktır. Yani yükleme dizinlerinde sihirli değer 777 değil, doğru sahiplik + standart izinlerdir:

# Sahiplik web sunucusu kullanıcısına aitse standart izinler yeterlidir
find wp-content -type d -exec chmod 755 {} \;
find wp-content -type f -exec chmod 644 {} \;

Bazı durumlarda hosting sağlayıcınızın PHP'yi hangi kullanıcı olarak çalıştırdığına bağlı olarak (örneğin suPHP, PHP-FPM pool veya CloudLinux'un CageFS'i altında) yazma sorunları ortaya çıkabilir. Modern paylaşımlı sunucularda PHP genelde sizin hesap kullanıcınız olarak çalışır, bu da dosyalarınızın sahibiyle PHP'nin çalıştığı kullanıcının aynı olması anlamına gelir; bu senaryoda 755/644 neredeyse her zaman sorunsuz çalışır. Sorun yalnızca dosyalar FTP ile bir kullanıcı, PHP ise başka bir kullanıcı olarak çalıştığında baş gösterir — ki çözümü yine sahipliği hizalamaktır, izni 777 yapmak değil.

Bir de wp-content/uploads içindeki dizinlerde çalıştırılabilir dosya (özellikle .php) barınmaması gerektiğini hatırlatalım. Yüklenen medya dosyaları görsel, PDF veya arşivdir; bu dizine bir PHP dosyası yazılıp çalıştırılabiliyorsa bu neredeyse her zaman bir saldırı belirtisidir. Ekstra bir önlem olarak uploads dizininde PHP yürütmeyi engelleyebilirsiniz:

# wp-content/uploads/.htaccess — bu dizinde PHP çalıştırmayı engelle
<FilesMatch "\.(?i:php|phtml|php3|php4|php5|php7|phps)$">
    Require all denied
</FilesMatch>

İzinleri SSH ile chmod Kullanarak Ayarlama#

Sunucunuza SSH erişiminiz varsa, izinleri toplu ve doğru biçimde ayarlamanın en temiz yolu find komutudur. Buradaki altın kural, dizinlere ve dosyalara ayrı ayrı izin vermektir; çünkü chmod -R 755 . gibi bir komut tüm dosyalara da gereksiz yere çalıştırma izni verir. WordPress kök dizinine geçip şu iki komutu çalıştırın:

# WordPress kök dizinindeyken
# Önce tüm dizinler 755
find . -type d -exec chmod 755 {} \;
# Sonra tüm dosyalar 644
find . -type f -exec chmod 644 {} \;

Bu iki komut, kurulumun tamamını temiz bir 755/644 şemasına oturtur. Ardından hassas dosyaları özel olarak sıkılaştırın:

# wp-config.php'yi yalnızca sahibe aç
chmod 600 wp-config.php

Sahiplik hatalıysa (örneğin dosyaların bir kısmı root, bir kısmı FTP kullanıcısı adına ise) önce sahipliği web sunucusu kullanıcısına devretmeniz gerekir. Sahiplik değişiminde dosya/dizin ayrımı yapmaya gerek yoktur, -R güvenle kullanılır:

# Kendi kurulumunuzda web sunucusu kullanıcısı www-data ise
chown -R www-data:www-data /var/www/wordpress

Sık kullanacaksanız, bu düzeltmeleri tek bir betikte toplamak pratik olur:

#!/bin/bash
# fix-wp-perms.sh — WordPress izinlerini standart şemaya oturtur
WP_ROOT="/var/www/wordpress"
WP_USER="www-data"

chown -R "${WP_USER}:${WP_USER}" "$WP_ROOT"
find "$WP_ROOT" -type d -exec chmod 755 {} \;
find "$WP_ROOT" -type f -exec chmod 644 {} \;
chmod 600 "$WP_ROOT/wp-config.php"

echo "İzinler ve sahiplik güncellendi."

chown komutu genelde root yetkisi (sudo) gerektirir; paylaşımlı barındırmada zaten yalnızca kendi hesabınızın kullanıcısı olduğunuz için sahiplik sorunu nadiren yaşanır. Kendi sunucunuzda tam kontrol istiyorsanız VDS veya sanal sunucu çözümlerimizle SSH üzerinden bu ayarların tümünü doğrudan yönetebilirsiniz.

İzinleri FTP ile FileZilla Kullanarak Ayarlama#

SSH erişiminiz yoksa veya kabuk komutlarıyla arası iyi olmayan biriyseniz, dosya izinlerini FTP istemcisi üzerinden de ayarlayabilirsiniz. En yaygın istemci olan FileZilla üzerinden anlatalım.

Sunucuya bağlandıktan sonra bir dosya ya da klasöre sağ tıklayıp Dosya izinleri (File permissions) seçeneğine gelin. Açılan pencerede sayısal değeri doğrudan girebilir (örneğin klasörler için 755, dosyalar için 644) ya da okuma/yazma/çalıştırma kutucuklarını işaretleyebilirsiniz. Bir klasöre izin verirken alttaki Alt dizinlere özyinele (Recurse into subdirectories) seçeneğini işaretlerseniz izin tüm alt içeriğe uygulanır.

Ancak burada FTP'nin kritik bir sınırlaması var: FileZilla'nın özyineli izin penceresinde "yalnızca dosyalara uygula" ve "yalnızca dizinlere uygula" seçenekleri bulunur. Tüm kurulumu tek seferde düzeltirken bu iki adımı iki ayrı geçişte yapmalısınız:

• Önce kök klasöre 755 verip "Yalnızca dizinlere uygula" seçeneğini işaretleyin.
• Sonra kök klasöre 644 verip "Yalnızca dosyalara uygula" seçeneğini işaretleyin.

Bu iki adımlı yaklaşım, SSH'deki iki find komutunun tam FTP karşılığıdır. Tek adımda hepsine 755 verirseniz, tıpkı chmod -R 755 gibi, tüm dosyalara gereksiz çalıştırma izni vermiş olursunuz.

FTP'nin bir başka sınırlaması da şudur: FTP protokolü sahiplik (chown) kavramını doğrudan yönetmez. Yani FileZilla ile izinleri (chmod) değiştirebilirsiniz ama bir dosyanın hangi kullanıcıya ait olduğunu değiştiremezsiniz. Sahiplik kaynaklı bir "yazılamıyor" sorunuyla karşılaşırsanız, hosting panelinizin dosya yöneticisini kullanmanız ya da destek ekibinden yardım istemeniz gerekir. FTP ile SFTP arasındaki güvenlik farklarını ve hangisini tercih etmeniz gerektiğini ayrıca değerlendirmek isteyebilirsiniz.

777'nin Tehlikesi ve Asıl Sorun: Sahiplik#

Şimdi en önemli bölüme geldik. İnternette bir sorunla karşılaşan WordPress kullanıcısının en çok gördüğü tavsiye ne yazık ki "izni 777 yap" oluyor. Bu tavsiye neredeyse her zaman yanlıştır ve neden yanlış olduğunu anlamak, doğru izin yönetiminin özünü kavramak demektir.

777 (rwxrwxrwx) izni, bir dosyayı ya da dizini sunucudaki herkese açar: sizin hesabınıza, aynı paylaşımlı sunucudaki komşu hesaplara, ele geçirilmiş başka bir siteye, hatta yanlış yapılandırılmış bazı servislere. Bir saldırgan sitenizde 777 izinli bir dizin bulduğunda, oraya kötü amaçlı bir PHP dosyası yazıp web sunucusu üzerinden çalıştırabilir. Bu, tek bir gevşek izin yüzünden sitenizin tamamen ele geçirilmesi anlamına gelebilir. wp-config.php gibi bir dosyayı 777 yapmak ise doğrudan felakettir — veritabanı şifreniz sunucudaki herkese açılmış olur.

Peki insanlar neden 777'ye başvuruyor? Çünkü genelde asıl sorun izin değil, sahipliktir. "Klasör yazılabilir değil" hatasının gerçek sebebi çoğunlukla şudur: dosyalarınız bir kullanıcı (diyelim FTP hesabınız) adına, PHP ise başka bir kullanıcı (www-data) adına çalışıyordur. www-data, sizin sahip olduğunuz 755 bir dizine yazamaz çünkü o dizinin "diğer" (others) sınıfında yazma izni yoktur — ve 777 yapmak tam da bu "diğer" sınıfına yazma izni açtığı için "işe yaramış" gibi görünür. Oysa doğru çözüm dizini herkese açmak değil, sahibini PHP'nin çalıştığı kullanıcıyla hizalamaktır:

# YANLIŞ yaklaşım — herkese yazma açar, güvenlik açığı yaratır
chmod -R 777 wp-content

# DOĞRU yaklaşım — sahipliği web sunucusu kullanıcısına devret, izni sıkı tut
chown -R www-data:www-data wp-content
find wp-content -type d -exec chmod 755 {} \;
find wp-content -type f -exec chmod 644 {} \;

Aşağıdaki tablo bu iki yaklaşımı karşılaştırıyor:

Özetle: eğer bir izin sorunu için 777'yi düşünüyorsanız, durup önce sahipliği kontrol edin. Modern barındırmada PHP genelde sizin hesabınız olarak çalıştığından bu sorun kendiliğinden çözülür; sorun yaşıyorsanız WordPress güvenliği rehberimizdeki minimum yetki prensibini uygulamak, hem çalışan hem de güvenli bir kuruluma ulaşmanızın en sağlam yoludur.

İzin Sorunlarını Teşhis Etme ve Doğrulama#

İzinleri ayarladıktan sonra "acaba doğru mu oldu" sorusunu netleştirmek için birkaç kontrol yapmak iyidir. SSH üzerinden mevcut izinleri hızlıca görüntülemek için:

# Kök dizindeki dosya ve klasörlerin izinlerini listele
ls -la /var/www/wordpress

# Yalnızca wp-config.php'nin iznini kontrol et
ls -l wp-config.php
# Beklenen çıktı: -rw------- (yani 600)

WordPress'in kendi "Site Sağlığı" (Tools > Site Health) ekranı da dosya sistemiyle ilgili sorunları raporlar; güncellemelerin manuel mi yoksa otomatik mi yapılabildiğini oradan görebilirsiniz. Eğer panelden eklenti güncellerken "FTP bilgileriniz istendi" ekranıyla karşılaşıyorsanız, bu neredeyse her zaman bir sahiplik/izin uyumsuzluğunun işaretidir: WordPress dosyalara doğrudan yazamadığı için sizden FTP köprüsü ister. Sahipliği doğru ayarladığınızda bu ekran ortadan kalkar ve güncellemeler tek tıkla çalışır.

Bir başka pratik ipucu: kapsamlı izin değişikliklerinden önce mutlaka yedek alın. Yanlış bir chmod -R veya chown -R komutu, özellikle yanlış bir dizinde çalıştırılırsa sitenizi erişilemez hâle getirebilir. Yedekleme hizmetimizle düzenli otomatik yedekler alıyorsanız, hatalı bir izin operasyonundan dakikalar içinde geri dönebilirsiniz. Aynı şekilde, site taşırken izinlerin kaynak sunucudakiyle aynı kalmayabileceğini unutmayın; site taşıma işlemlerinde hedef sunucuda izin ve sahipliği yeniden hizalamak standart bir adımdır.

Sıkça Sorulan Sorular#

WordPress dosyalarına hangi izinleri vermeliyim?#

Standart ve güvenli şema şudur: tüm klasörler 755, tüm dosyalar 644, wp-config.php ise 600 (gerekiyorsa en fazla 640). Bu değerler WordPress'in çalışması için yeterli yetkiyi verirken gereksiz açıklıkları kapatır. Dosyalara asla çalıştırma izni (x) veya toplu 777 vermeyin; PHP dosyaları çalıştırma iznine ihtiyaç duymadan, PHP yorumlayıcısı tarafından okunarak yürütülür.

wp-config.php dosyasına neden 600 izni öneriliyor?#

Çünkü wp-config.php veritabanı kullanıcı adınızı, şifrenizi ve güvenlik anahtarlarınızı düz metin olarak içerir. 600 izni bu dosyayı yalnızca sahibine açar; grup ve diğer herkese tamamen kapatır. Özellikle paylaşımlı sunucularda 644 gibi herkese açık bir izin, aynı sunucudaki başka bir hesabın veritabanı şifrenizi okumasına yol açabileceği için ciddi bir risktir.

chmod 777 yaparsam neden güvenlik açığı oluşur?#

777 izni dosyayı ya da dizini sunucudaki herkese okuma, yazma ve çalıştırma için açar. Bu, aynı sunucudaki başka bir hesabın veya ele geçirilmiş bir sitenin, sizin dizininize kötü amaçlı bir PHP dosyası yazıp çalıştırabilmesi anlamına gelir. Yazma sorununuz gerçekte bir sahiplik uyumsuzluğundan kaynaklanıyorsa, doğru çözüm chown ile sahipliği web sunucusu kullanıcısına devretmek ve izinleri 755/644 seviyesinde tutmaktır.

FTP ile dosya izinlerini nasıl değiştiririm?#

FileZilla gibi bir FTP istemcisinde dosya veya klasöre sağ tıklayıp Dosya İzinleri seçeneğinden sayısal değeri girebilirsiniz. Tüm siteyi düzeltirken önce dizinlere 755 (Yalnızca dizinlere uygula), ardından dosyalara 644 (Yalnızca dosyalara uygula) verecek şekilde iki ayrı özyineli geçiş yapın. FTP ile yalnızca izinleri (chmod) değiştirebilirsiniz; sahiplik (chown) değişimi için hosting paneli ya da SSH gerekir.

wp-content klasörüne 777 vermem gerekiyor mu?#

Hayır. wp-content ve uploads dizinlerinin sahibi web sunucusu kullanıcısı (paylaşımlı barındırmada genelde sizin hesap kullanıcınız) ise, standart 755 dizin ve 644 dosya izinleri yükleme ve güncelleme için fazlasıyla yeterlidir. Yazma yetkisi zaten dosyanın sahibine açık olduğundan 777'ye ihtiyaç yoktur; 777 yalnızca gereksiz bir güvenlik açığı yaratır.

İzin ayarlarını SSH olmadan da yapabilir miyim?#

Evet. SSH erişiminiz yoksa hosting panelinizin (cPanel gibi) Dosya Yöneticisi üzerinden ya da bir FTP istemcisiyle izinleri ayarlayabilirsiniz. Her ikisi de chmod benzeri bir izin arayüzü sunar. Ancak sahiplik (chown) sorunları için genelde sunucu tarafında kabuk erişimi ya da destek ekibinin müdahalesi gerekir; çünkü ne FTP ne de çoğu dosya yöneticisi arayüzü sahiplik değişimini doğrudan destekler.

Kapanış#

WordPress dosya izinleri, ilk bakışta teknik bir ayrıntı gibi görünse de aslında sitenizin güvenliğinin en temel katmanlarından biridir. Aklınızda tutmanız gereken şema sade: klasörler 755, dosyalar 644, wp-config.php için 600. Bir yazma sorunuyla karşılaştığınızda ilk refleksiniz 777 olmamalı; neredeyse her zaman asıl mesele izin değil sahipliktir ve doğru çözüm chown ile sahipliği hizalamaktır. Bu basit disiplin, hem sitenizin sorunsuz çalışmasını hem de olası bir sızıntının etkisinin sınırlı kalmasını sağlar.

Clou.TR olarak WordPress sitenizin güvenli ve hızlı bir altyapıda çalışmasını önemsiyoruz. PHP'yi kendi hesap kullanıcınız olarak çalıştıran, izin ve sahiplik sorunlarını en aza indiren modern WordPress hosting ve web hosting paketlerimize göz atabilir; tam kontrol isteyen ileri kullanıcılar için VDS çözümlerimizle SSH üzerinden her ayarı kendiniz yönetebilirsiniz. Sitenizi taşırken izinlerin doğru kurulmasını isterseniz site taşıma ekibimiz, olası hatalara karşı da yedekleme hizmetimiz her zaman yanınızda.