Web Sitelerinde Unutulan Yedek ve Dizin Dosyaları Güvenlik Riski Oluşturur mu? (2026 Rehberi)

Web geliştiricilerinin, sistem yöneticilerinin veya içerik yöneticilerinin bir web sitesinde güncelleme yaparken ya da bir sorunu çözerken en sık başvurduğu yöntemlerden biri geçici yedekler almaktır. Ancak sunucuya yüklenen wp-config.php.old, database_2026.sql veya backup.zip gibi dosyalar iş bittikten sonra sıklıkla unutulur. Peki, web sitelerinde yedek dosyaları güvenlik riski oluşturur mu? Yanıt kesinlikle evettir. Hatta unutulan bu geçici dosyalar ve test dizinleri, günümüz siber saldırı ekosisteminde bir web sitesinin tamamen ele geçirilmesine yol açan en ilkel ancak en etkili kritik zafiyetlerden birini temsil eder. Web sitenizin veri bütünlüğünü korumak ve profesyonel bir Web Sitesi Yedekleme Stratejisi: 3-2-1 Kuralı ve Otomatik Yedekleme oluşturmak için bu dosyaların yarattığı tehlikeleri ve nasıl temizleneceğini detaylıca anlamanız gerekir.

Web sunucuları (Apache, Nginx, LiteSpeed vb.) standart şartlarda .php uzantılı dosyaları yorumlayarak kaynak kodunu gizler ve çıktı olarak sadece HTML üretir. Ancak bir dosyaya .php.bak, .php.old veya .php.txt gibi bir uzantı eklediğinizde, web sunucusu bu dosyayı artık işlenebilir bir betik olarak görmez. Dosyayı düz metin (plain text) olarak istemciye sunar veya doğrudan indirilmesine izin verir. Bu durum, arka planda çalışan tüm veritabanı şifrelerinin, API anahtarlarının ve gizli yapılandırma parametrelerinin tek bir tıkla saldırganların eline geçmesine sebep olur.

Unutulan Yedek Dosyaları Güvenlik Riski İçin Neden Bir numaralı Hedeftir?

Siber korsanlar ve otomatize botlar, bir web sitesine sızmak için her zaman karmaşık 0-day (sıfırıncı gün) açıklarını aramazlar. En az çaba ile en yüksek erişimi sağlayan yöntemlere odaklanırlar. Unutulan yedek ve dizin dosyaları tam da bu noktada saldırganlar için altın değerindedir. Bu durumun ana nedenlerini şu başlıklar altında toplayabiliriz:

1. PHP İşleyicisinin Devre Dışı Kalması ve Düz Metin İfşası

Normal bir akışta bir ziyaretçi index.php veya wp-config.php adresine girdiğinde, PHP-FPM veya mod_php devreye girer. Kodları sunucu tarafında derler ve veritabanı şifreleri gibi kritik satırları saklayarak sonucu sunar. Ancak geliştirici dosyayı wp-config.php.old veya wp-config.php.bak olarak değiştirdiğinde sunucu varsayılan MIME türünü devreye sokar. Tarayıcı veya tarama botu bu adrese istek attığında, PHP kodları derlenmek yerine dosyanın içeriği olduğu gibi ekrana basılır veya bilgisayara indirilir.

2. Kritik Kimlik Doğrulama Bilgilerinin Çalınması

İfşa olan bir config.php.old veya .env.backup dosyası şu bilgileri doğrudan saldırganın eline teslim eder:

• Veritabanı sunucusu IP/Host adresi, veritabanı kullanıcı adı ve parola
• AWS, Google Cloud veya Azure API gizli anahtarları (Secret Keys)
• SMTP e-posta sunucusu kullanıcı adı ve parolaları
• JWT (JSON Web Token) imzalama anahtarları veya uygulama SALT değerleri
• Ödeme kuruluşu (iZico, Stripe vb.) API ve şifreleme anahtarları

3. Statik Güvenlik Duvarlarının (WAF) Yanıltılması

Birçok temel güvenlik duvarı, standart PHP isteklerini denetleyecek şekilde yapılandırılmıştır. Ancak doğrudan statik bir .zip veya .sql dosyasına gelen HTTP GET istekleri, WAF tarafından meşru bir dosya indirme talebi olarak algılanabilir ve engellenmeyebilir. Eğer sitenizde gelişmiş bir kural seti yoksa, saldırgan WAF engelini kolayca aşar. Sunucunuzda aktif bir koruma katmanı kurarken Web Sitesi Güvenlik Duvarı (WAF) Karşılaştırması: Cloudflare, Sucuri ve Wordfence incelememizden faydalanarak bu tür statik dosya kurallarını aktif etmeniz kritik önem taşır.

Saldırganlar Unutulan Yedek ve Dizin Dosyalarını Nasıl Tespit Eder?

Birçok web sitesi yöneticisi "Benim wp-config.php.old dosyamı kimse tahmin edemez" yanılgısına düşer. Oysa 2026 yılı itibarıyla siber saldırı ekosistemi tamamen otonom çalışan tarayıcı yazılımlar ve yapay zeka destekli fuzzing araçları üzerine kuruludur.

Saldırganlar web sitenizi manuel olarak gezmez; hazırladıkları otomatik sözlükler (wordlists) ve hızlı HTTP istek motorları ile saniyede yüzlerce kombinasyonu denerler.

1. Otomatize Fuzzing Araçları (ffuf, Gobuster, Dirsearch)

Saldırganlar ffuf veya Gobuster gibi araçlar kullanarak bilinen en yaygın yedekleme kalıplarını alan adınız üzerinde test ederler. Örneğin aşağıdaki gibi bir komut, sunucunuza saniyeler içinde binlerce istek gönderir:

ffuf -u https://example.com/FUZZ -w /usr/share/wordlists/dirb/common.txt -e .php.bak,.php.old,.zip,.tar.gz,.sql,.bak,.old

Bu kelime listelerinde wp-config.php~, config.bak, site_backup.zip, db_dump.sql, 2026_backup.tar.gz gibi on binlerce hazır kombinasyon yer alır.

2. Arama Motoru İndeksleri (Google Dorks)

Eğer bir yedek klasöründe veya test dizininde Directory Listing (Dizin Listeleme) açık unutulmuşsa, Google veya Bing botları bu klasörü tarar ve indeksler. Saldırganlar sadece şu arama sorgularını kullanarak açıkta duran veritabanı dökümlerine erişebilirler:
• filetype:sql "MySQL dump" site:example.com
• intitle:"index of" "backup.zip"
• inurl:wp-config.php.bak

3. Unutulan Dizinler (Subdirectories)

Geliştiricilerin ana sitede değişiklik yapmadan önce oluşturduğu /test/, /v2/, /old/, /demo/ veya /dev/ gibi dizinler de büyük risk taşır. Ana sitedeki WordPress veya içerik yönetim sistemi güncellense bile, /old/ dizininde unutulan 3 yıllık eski bir sürüm, bilinen bir RCE (Remote Code Execution) zafiyeti üzerinden tüm sunucunun (ve dolayısıyla güncel ana sitenin) hacklenmesine neden olur.

En Riski Yüksek Dosya ve Dizin Uzantıları

Sunucu taramalarınızda gördüğünüz an derhal silmeniz veya web erişimine kapatmanız gereken kritik dosya kalıpları şunlardır:

• Yapılandırma Yedekleri: wp-config.php.bak, wp-config.php.old, wp-config.php~, .env.old, .env.backup, config.inc.php.save
• Veritabanı Dökümleri: dump.sql, backup.sql, database.sql.gz, users.sql, site_db.sql
• Arşiv Dosyaları: public_html.zip, backup_2026.tar.gz, site.rar, wwwroot.zip
• Geçici Editör Dosyaları: .swp (Vim yedekleri), .#filename (Emacs), filename.php.bak (Notepad++ / VSCode uzantıları)
• Geliştirme ve Test Dizinleri: /test/, /dev/, /staging/, /old/, /bak/, /new/

Adım Adım Sunucudaki Unutulan Yedek Dosyalarını Bulma ve Temizleme Rehberi

Eğer bir Linux/Unix tabanlı cPanel, Plesk veya VPS sunucu yönetiyorsanız, terminal (SSH) erişimini kullanarak unutulan ve yedek dosyaları güvenlik riski oluşturan tüm unsurları hızlıca tespit edip temizleyebilirsiniz.

Adım 1: SSH İle Sunucuda Tehlikeli Dosya Taraması Yapın

Sunucunuza SSH ile bağlandıktan sonra web sitenizin kök dizinine (cd /var/www/html veya cd /home/kullanici/public_html) gidin ve aşağıdaki komutları çalıştırın.

Sistemdeki tüm .zip, .tar.gz, .sql, .bak ve .old uzantılı dosyaları bulmak için:

find . -type f \( -name "*.zip" -o -name "*.tar.gz" -o -name "*.tgz" -o -name "*.sql" -o -name "*.bak" -o -name "*.old" -o -name "*~" \) -exec ls -lh {} \;

Gizli kalmış veya yedeklenmiş .env dosyalarını bulmak için:

find . -type f -name ".env*"

wp-config içeren tüm varyasyonları bulmak için:

find . -type f -name "wp-config*"

Adım 2: Web Sunucusu Seviyesinde Hassas Uzantılara Access Block Koyun

Dosyaları silmek ilk adımdır ancak gelecekte bir geliştiricinin yanlışlıkla dosya bırakması ihtimaline karşı web sunucunuzu (Nginx veya Apache) yapılandırmalısınız.

#### Apache (.htaccess) İçin Engelleme Kuralı: Site ana dizininizdeki .htaccess dosyasına şu satırları ekleyerek hassas uzantıların taranmasını ve indirilmesini tamamen engelleyin:

<FilesMatch "\.(bak|config|sql|ini|old|php~|swp|zip|tar\.gz|env|log)$">
    Order allow,deny
    Deny from all
</FilesMatch>

#### Nginx Yapılandırması (nginx.conf veya Server Block): Nginx kullanan sunucularda location bloğu içerisine şu kuralı ekleyip Nginx servisini yeniden başlatın (systemctl reload nginx):

location ~* \.(engine|inc|info|install|make|module|profile|test|po|sh|sql|theme|tpl(\.php)?|xtmpl|bak|old|php~|swp|env|zip|tar\.gz)$ {
    deny all;
    return 404;
}

Adım 3: Dizin Listelemeyi (Directory Browsing) Kapatın

Klasör içinde varsayılan bir index.php veya index.html olmaması durumunda sunucunun klasör içeriğini ekrana basmasını engellemeliniz.

• Apache için: .htaccess dosyasının en üstüne Options -Indexes satırını ekleyin.
• Nginx için: server bloğu içerisinde autoindex off; direktifinin aktif olduğundan emin olun.

Adım 4: Güvenlik Bildirimi İçin security.txt Ekleyin

Sitenizde unutulan olası bir açıkta, etik korsanların (Bug Bounty araştırmacıları) sizinle doğrudan iletişime geçebilmesi için standartlara uygun bir güvenlik bildirimi oluşturmalısınız. Bu konuda detaylı bilgi edinmek için security.txt Dosyası Nedir? Web Sitesi Güvenlik Bildirimi Oluşturma Rehberi makalemizi inceleyebilirsiniz.

Güvenli Yedekleme İçin Doğru Strateji ve En İyi Uygulamalar (Best Practices)

Geçici yedeklerin risk oluşturmaması için altyapı mimarinizde şu prensipleri standart haline getirmelisiniz:

Asla public_html İçine Yedek Almayın: Manuel bir yedek almanız gerekiyorsa, bu yedeği kesinlikle dışarıdan web erişimi olan /public_html veya /var/www/html dizininde saklamayın. Yedeği web dizininin bir üst seviyesine (/home/user/backups/) kaydedin.

Yerel Bilgisayara İndirin ve Sunucudan Silin: Test amacıyla alınan veritabanı dökümlerini veya dosya arşivlerini işlem tamamlanır tamamlanmaz bilgisayarınıza indirin ve sunucudaki kopyasını derhal silin.

Uzak Bulut Depolama Kullanın: Otomatik yedeklerinizi doğrudan sunucu içine değil; AWS S3, Google Cloud Storage, Wasabi veya yedekleme amaçlı ayrılmış uzak bir SFTP sunucusuna aktarın.

Cron Job İle Otomatik Temizlik Tanımlayın: Sunucunuzda geçici dizinlerde biriken eski yedekleri otomatik silen bir bash betiği çalıştın. Örneğin /tmp/ veya özel yedek klasörünüzdeki 7 günden eski dosyaları silmek için şu cron komutunu kullanabilirsiniz:

0 3 * * * find /home/kullanici/private_backups/ -type f -mtime +7 -delete

Geliştirme Ortamlarını İzolasyona Alın: Yeni bir tasarım veya modül denerken sitenizi /test/ gibi bir alt dizine kurmak yerine, sub-domain (örneğin dev.sitename.com) üzerinde kurun ve bu alanı IP kısıtlaması veya HTTP Basic Auth (şifre koruması) ile dış dünyaya tamamen kapatın.

Sonuç

Web sitelerinde unutulan yedek ve dizin dosyaları, saldırganların sisteminize sızmak için kullandığı en sessiz ve en tehlikeli arka kapılardan biridir. Tek bir wp-config.php.old veya database.sql dosyası, aylar süren emeklerinizi ve müşteri verilerinizi bir anda riske atabilir. Üstelik karmaşık sızma araçlarına dahi gerek kalmadan, sadece otomatize arama botları tarafından saniyeler içinde tespit edilebilir.

Sonraki Adım: Zaman kaybetmeden SSH terminalinizi veya cPanel Dosya Yöneticinizi açın. Rehberimizde paylaştığımız find komutlarını çalıştırarak sunucunuzda .sql, .bak, .zip ve .old uzantılı unutulmuş dosya olup olmadığını kontrol edin ve web sunucunuza engelleyici kuralları tanımlayın.