How can I prevent Drupal’s public file system from exposing private configuration files accidentally?

Why the risk exists

Drupal’s public file system lives inside the web‑root (e.g., sites/default/files). Any file that ends up there is reachable by a direct URL unless the web server is explicitly told otherwise. If a developer or an automated process uploads a configuration export, log, or any other non‑public file to that folder, visitors can download it.

Core settings to review

1. Public file path – Check admin/config/media/file-system and confirm the Public file path is what you expect (usually sites/default/files).
2. Private file path – In settings.php the private path should point outside the document root, e.g.:

   $settings['file_private_path'] = '/var/www/example.com/private';
   

   This directory must be writable by the web‑server user but not directly accessible via HTTP.
3. File system permissions – Ensure the public folder is 0755 and files 0644; the private folder should be 0750 and files 0640. Verify the owner matches the web‑server user (often www-data, apache, or nginx).
4. Disable PHP execution in public files – Drupal’s core already sets php_flag engine off in the default files/.htaccess, but double‑check if you have overridden it.

Server‑level rules for Apache & Nginx

Apache (.htaccess)

# Prevent access to sensitive file types in the public files directory.

  Require all denied

# Deny PHP execution in the public files folder.

  Require all denied

# Keep the default Drupal behaviour for assets.

Nginx (location block)

location ~* ^/sites/default/files/.*\.(yml|yaml|inc|install|log|txt|conf|ini|env)$ {
  deny all;
  return 404;
}
location ~* ^/sites/default/files/.*\.(php|php5?)$ {
  deny all;
  return 404;
}
# Allow normal assets.
location ~* ^/sites/default/files/.*\.(css|js|png|jpg|jpeg|gif|svg|webp)$ {
  try_files $uri =404;
}

Replace /sites/default/files with the actual public path if you use a different site directory.

Verification checklist

• Use curl -I https://example.com/sites/default/files/someconfig.yml and confirm a 403 or 404 status.
• Navigate to admin/reports/status and verify the private path is listed as outside the docroot.
• Attempt to upload a test file via the Drupal UI to the public folder and confirm it is not publicly accessible.
• Check web‑server error logs for any unexpected 403 entries on legitimate assets.
• Run drush core-status or drush php-eval "echo file_exists('/var/www/example.com/private/test.txt');" to ensure the private filesystem is functional.

Next diagnostic question

Do you currently host Drupal behind Apache, Nginx, or another web server? The exact directive syntax differs slightly between them, so confirming the server type will help tailor the rules precisely.