Generate Apache .htaccess Security Rules

Apache .htaccess files are per-directory configuration files that allow site administrators to override server settings without restarting Apache or editing the main httpd.conf. They're especially common on shared hosting environments where users don't have server-level access. A well-configured .htaccess can enforce HTTPS, add security headers, prevent directory listing, block access to sensitive files, and configure caching — all from a file in the web root. This example implements the four most important .htaccess security configurations: HTTPS redirection, security headers, directory listing prevention, and blocking access to sensitive file extensions. The HTTPS redirection block uses mod_rewrite to redirect all HTTP requests to HTTPS. The RewriteCond %{HTTPS} off checks if the current request is not using HTTPS. The RewriteRule then redirects to the HTTPS version using 301 (permanent redirect) so browsers and search engines update their bookmarks and indexes. The [L] flag stops processing further rules once this rule matches. The four security headers that every site should set: X-Content-Type-Options: nosniff prevents browsers from MIME-sniffing a response away from the declared content type (which could allow an HTML file served as text/plain to be executed as HTML). X-Frame-Options: DENY prevents clickjacking by blocking iframe embedding. Referrer-Policy: strict-origin-when-cross-origin limits the referer header to not leak full URLs to cross-origin destinations. Options -Indexes disables directory listing — without this, Apache displays a file browser when a directory lacks an index.html file, exposing your file structure to anyone who navigates to that directory path. The FilesMatch block blocks access to files with sensitive extensions: .env (environment files with secrets), .log (application logs), .bak (backup files), .sql (database dumps), and .conf (configuration files). These file types are commonly left in web roots accidentally and can expose credentials, database contents, or application configuration to anyone who guesses the filename. Critical warning: a single syntax error in .htaccess causes Apache to return a 500 Internal Server Error for every request in that directory and all subdirectories. This makes syntax validation before deployment essential. Always test .htaccess changes on a staging server first, and keep a backup of the working configuration so you can quickly revert if something goes wrong. Tips: .htaccess only works if AllowOverride is set to All (or at least to the required options) in Apache's main configuration. If your .htaccess rules seem to be ignored, check the Apache virtual host configuration for AllowOverride settings.

# Force HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Security Headers
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "DENY"
Header always set X-XSS-Protection "1; mode=block"
Header always set Referrer-Policy "strict-origin-when-cross-origin"

# Prevent directory listing
Options -Indexes

# Block access to sensitive files
<FilesMatch ".(env|log|bak|sql|conf)$">
  Order allow,deny
  Deny from all
</FilesMatch>