Web Sitelerinde Staging ve Backup Dizinlerinin Güvenliği: Hassas Klasörler Nasıl Gizlenir?

Modern web geliştirme süreçlerinde test ortamları (staging) ve veritabanı/dosya yedekleri (backup) projenin sürdürülebilirliği için vazgeçilmezdir. Ancak web sitelerinde staging ve backup dizinlerinin güvenliği ihmal edildiğinde, bu klasörler siber saldırganlar için adeta açık bir kapı haline gelir. Web sunucunuzda unutulan bir backup.sql dosyası veya kamusal erişime açık tutulan bir dev alt alan adı (subdomain), tüm veritabanı kimlik bilgilerinizi, kaynak kodlarınızı ve müşteri verilerinizi saniyeler içinde sızdırabilir. Bu rehberde, staging ve yedek dizinlerini dış dünyaya tamamen kapatmanın, yetkisiz erişimleri engellemenin ve sunucu düzeyinde hassas klasörleri gizlemenin somut adımlarını ele alacağız.

Güvenlik mimarisini kurgularken yalnızca ana sitenizi korumak yeterli değildir. Nitekim Web Uygulama Güvenliği (OWASP Top 10) ve Korunma Yolları listesinde de belirtildiği gibi, hatalı güvenlik yapılandırmaları (Security Misconfiguration) en yaygın zafiyet türleri arasında yer alır. Geliştiricilerin genellikle gözden kaçırdığı test ortamları ve geçici yedek klasörleri, tarama botlarının (scanner) ilk hedef aldığı alanlardır.

Staging ve Backup Dizinlerinin Güvenliği Neden Hayati Öneme Sahiptir?

Bir web projesi geliştirilirken yaygın olarak staging.siteadi.com, siteadi.com/test veya siteadi.com/backup gibi dizinler oluşturulur. Bu alanlar genellikle canlı prodüksiyon (production) ortamının birebir kopyasıdır. Ancak bu alanların savunmasız bırakılması şu kritik riskleri doğurur:

• Açık Metin Kimlik Bilgileri: Staging alanlarında yer alan .env, wp-config.php veya configuration.php dosyaları veritabanı kullanıcı adı ve şifrelerini barındırır. Otomatik tarayıcılar bu dosyalara eriştiğinde veritabanınız tamamen ele geçirilebilir.
• Arama Motoru İndekslenmesi: Arama motoru botları, engelleyici bir robots.txt veya noindex etiketi bulunmayan staging sitelerini indeksler. Bu durum hem yinelenen içerik (duplicate content) cezalarına yol açar hem de gizli kalması gereken yönetim panellerini arama sonuçlarında açık hale getirir.
• Eski ve Zafiyetli Kodlar: Staging ortamları canlı site kadar sık güncellenmeyebilir. Güncellenmeyen bir eklenti veya çekirdek dosya, saldırganın sunucuya sızmasına ve symlink yöntemleriyle ana siteye atlamasına neden olur.
• Büyük Boyutlu Yedek Sızıntıları: site_yedek_2026.zip veya db_dump.sql gibi arşivler doğrudan public_html dizininde saklandığında, URL'yi tahmin eden veya sözlük saldırısı (fuzzing) yapan herkes tüm veriyi indirebilir.

En Sık Yapılan Güvenlik Hataları ve Saldırı Senaryoları

Saldırganlar ve otomatik zafiyet tarama botları (ffuf, DirBuster, Gobuster vb.), web sunucularında belirli dosya ve dizin kalıplarını ararlar. Gerçek senaryolarda en sık karşılaşılan hatalar şunlardır:

• Yedekleri Web Root (public_html) İçinde Saklamak: En ölümcül hata, cPanel veya SSH üzerinden alınan sıkıştırılmış dosyaları webten erişilebilir dizinde bırakmaktır.
• Kötü İsimlendirilmiş Test Klasörleri: /test, /demo, /v2, /old, /new gibi tahmin edilmesi kolay dizin isimleri kullanmak.
• Varsayılan İzinlerin Kullanılması: Klasör izinlerinin 777 veya 755, dosya izinlerinin 666 veya 644 yapılarak herkes tarafından okunabilir kılınması.
• Dizin Listelemenin (Directory Listing) Açık Olması: Dizin içerisinde bir index.html veya index.php bulunmadığında sunucunun tüm dosya listesini ziyaretçiye göstermesi.

Yeni bir site kurarken, örneğin WordPress Elementor ile Sıfırdan Web Sitesi Nasıl Yapılır? (2026) rehberimizdeki adımları takip ederken dahi, ilk iş olarak canlıya geçiş sonrası geçici klasörleri temizlemek ve erişim kısıtlamalarını aktif etmektir.

Apache Sunucularda Hassas Dizinleri Gizleme (.htaccess Yapılandırması)

Apache HTTP sunucusu kullanıyorsanız, .htaccess dosyası üzerinden hassas dizinleri ve dosya uzantılarını kolayca koruma altına alabilirsiniz.

1. Dizin Listelemeyi Kapatma

Sunucunuzun bir klasör içeriğini otomatik olarak listelemesini engellemek için ana .htaccess dosyanızın en üstüne şu satırı ekleyin:

Options -Indexes

2. Kritik Dosya Uzantılarına Erişimi Engelleme

.sql, .zip, .tar.gz, .log, .env ve .bak gibi uzantılara web üzerinden erişimi tamamen engellemek için aşağıdaki kuralı ekleyin:

<FilesMatch "\.(sql|gz|tar|zip|rar|bak|log|env|git|svn)$">
    Require all denied
</FilesMatch>

3. Staging Dizinine IP Kısıtlaması Getirme

Staging klasörünüz olan /staging dizinine sadece kendi IP adresinizin erişmesini sağlayabilirsiniz. /staging/.htaccess dosyası oluşturup şu kodları yerleştirin:

AuthType Basic
AuthName "Yetkili Girisi"
Order Deny,Allow
Deny from all
# Kendi sabit IP adresinizi girin
Allow from 195.175.254.1

4. HTTP Basic Authentication (Şifre Koruması) Ekleme

Eğer sabit bir IP adresiniz yoksa, staging dizinine kullanıcı adı ve şifre ile giriş zorunluluğu getirebilirsiniz. htpasswd aracı ile şifrelenmiş bir .htpasswd dosyası oluşturun ve /staging/.htaccess dosyasına şu satırları yazın:

AuthType Basic
AuthName "Geliştirici Alanı - Korumalı"
AuthUserFile /home/kullanici/secure_dir/.htpasswd
Require valid-user

Nginx Sunucularda Test ve Yedek Klasörlerini Engelleme

Nginx performans açısından son derece verimli olsa da .htaccess dosyalarını okumaz. Tüm güvenlik kuralları Nginx konfigürasyon dosyasına (nginx.conf veya site-available/domain.com) yazılmalıdır.

1. Hassas Uzantıları ve Gizli Dosyaları Engelleme

Nginx bloklarınız arasına şu location tanımlamalarını ekleyerek .env, .git ve yedek uzantılarına erişimi kesebilirsiniz:

# Nokta ile başlayan gizli dosyaları engelle (.htaccess, .env vb.)
location ~ /\. {
    deny all;
    access_log off;
    log_not_found off;
}

# Veritabanı ve arşiv dosyalarına erişimi engelle
location ~* \.(sql|gz|zip|tgz|rar|bak|log)$ {
    deny all;
    return 404;
}

2. Staging Alt Alan Adını (Subdomain) Şifre ile Koruma

staging.siteadi.com sunucu bloğuna (server block) auth_basic direktifini ekleyebilirsiniz:

server {
    listen 443 ssl http2;
    server_name staging.siteadi.com;
    root /var/www/staging;

    auth_basic "Gelisdirici Girisi";
    auth_basic_user_file /etc/nginx/.htpasswd;

    # Sadece belirli IP grubuna izin vermek isterseniz:
    # allow 195.175.254.1;
    # deny all;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }
}

Sistem güvenliğini bir üst seviyeye taşımak için sunucu seviyesinde firewall kuralları da yapılandırılmalıdır. Ayrıntılı bilgi için VPS Sunucu Güvenliği Nasıl Sağlanır? SSH Port Değiştirme ve Firewall Ayarları başlıklı makalemizi inceleyebilirsiniz.

Linux Dosya ve Dizin İzinlerini (Permissions) Sertleştirme

Yanlış dosya izinleri, aynı web sunucusunda barınan diğer sitelerin veya yetkisiz kullanıcıların dosyalarınızı okumasına neden olur. İdeal dosya ve klasör izinleri şu şekilde olmalıdır:

• Tüm Klasörler: 755 (rwxr-xr-x) veya daha sıkı 750
• Tüm Dosyalar: 644 (rw-r--r--) veya daha sıkı 640
• Kritik Konfigürasyon Dosyaları (.env, wp-config.php): 600 (rw-------) veya 400 (r--------)

SSH üzerinden bu izinleri toplu olarak uygulamak için aşağıdaki komutları kullanabilirsiniz:

# Tüm klasörleri 755 yap
find /var/www/siteadi/public_html -type d -exec chmod 755 {} \;

# Tüm dosyaları 644 yap
find /var/www/siteadi/public_html -type f -exec chmod 644 {} \;

# Hassas konfigürasyon dosyasını sadece sahibi okuyabilsin
chmod 600 /var/www/siteadi/public_html/.env
chmod 600 /var/www/siteadi/public_html/wp-config.php

Yedekleme Stratejisinde En İyi Uygulama: Web Root Dışına Çıkmak

Staging ve backup dizinlerinin güvenliği konusunda yapılan en temel kavramsal hata, yedeklerin webten erişilebilir dizin altında tutulabileceği düşüncesidir. Oysa doğru bir mimaride yedek dosyaları asla public_html veya www dizini içinde yer almamalıdır.

Güvenli Yedek Depolama Mimarisi:

• Home Dizininde Web Root Dışı Alan Kullanımı: Yedeklerinizi /home/kullanici/backups/ gibi web sunucusunun (Nginx/Apache) kök dizin olarak tanımlamadığı alanlarda saklayın.
• Uzak Depolama (Off-Site Backup) Entegrasyonu: Yedeklerinizi otomatik olarak Amazon S3, Google Cloud Storage, Cloudflare R2 veya uzak bir SFTP sunucusuna aktarın. Aktarım biter bitmez yerel geçici yedeği silin.
• Yedek Arşivlerini Şifreleme: Veritabanı ve dosya yedeklerinizi alırken AES-256 algoritması ile şifreleyin. Böylece dosya çalınsa dahi içerik okunamaz.

Örnek şifreli yedek alma komutu:

mysqldump -u dbuser -p dbname | gzip | openssl enc -aes-256-cbc -e -k GüçlüParolam123! > /home/kullanici/backups/db_backup_$(date +%Y%m%d).sql.gz.enc

Otomatik Taramalar ve Sızma Testi ile Kontrol Etme

Yaptığınız kısıtlamaların çalışıp çalışmadığını doğrulamak için dışarıdan sitenizi test etmelisiniz. Aşağıdaki yöntemlerle kendi sitenizi tarayabilirsiniz:

• cURL ile HTTP Durum Kodu Kontrolü: Terminal üzerinden gizlediğiniz bir dosyayı isteyin. 403 Forbidden veya 404 Not Found yanıtı almalısınız.

curl -I https://siteadi.com/.env
curl -I https://siteadi.com/backup.sql

• OWASP ZAP veya Burp Suite Taraması: Web uygulamanızı güvenlik tarayıcılarından geçirerek açıkta kalan dizinleri tespit edin.
• Search Console Kontrolü: Google Search Console paneline girip dizine eklenen sayfalar arasında staging URL'lerinin olup olmadığını kontrol edin.

Sonuç ve Sonraki Adımlar

Siber güvenlik bütüncül bir yaklaşımdır. Ana sitenizi en güncel yazılımlarla ve karmaşık şifrelerle korusanız bile, unuttuğunuz bir test klasörü veya backup.zip dosyası tüm sisteminizi savunmasız bırakabilir. Bu rehberde öğrendiğiniz Nginx/Apache kurallarını hemen uygulayarak sunucunuzdaki hassas klasörleri dış dünyaya kapatın.

Hemen Atmanız Gereken İlk Adım: SSH veya FTP ile sunucunuza bağlanın, web root (public_html) klasörünüz altında yer alan tüm .zip, .sql, .tar.gz ve geçici test klasörlerini silin ya da web root dışındaki güvenli bir dizine taşıyın.