Apache .htaccess Inspector
Analyze .htaccess files for security issues, validate rewrite rules, and detect common misconfigurations
Enter your Apache .htaccess configuration to analyze for security issues and misconfigurations
Inspecting Apache .htaccess Files for Security and Configuration Issues
Apache's .htaccess files provide directory-level configuration overrides that control URL rewriting, access control, authentication, and security headers. Their distributed nature — any directory can have its own .htaccess — makes them powerful but difficult to audit holistically. A single misconfigured RewriteRule can expose admin panels, directory listing can reveal file structure, and missing security headers leave applications vulnerable to XSS and clickjacking attacks.
The .htaccess Inspector analyzes your Apache configuration for security vulnerabilities, rewrite rule correctness, deprecated directives, and missing protections. It validates RewriteRule regex patterns, detects information disclosure risks, checks for proper authentication configuration, and identifies common misconfigurations that impact both security and performance. All processing happens entirely in your browser.
Rewrite Rule Analysis
Apache's mod_rewrite is powerful but notoriously complex. The inspector validates rewrite rules for common issues:
- Invalid regex patterns: Syntax errors that cause 500 Internal Server Error responses
- Missing flags: Rules without
[L](Last) flag continue processing additional rules, causing unexpected behavior - Redirect loops: Rules that match their own output, creating infinite redirect cycles
- Overly broad patterns:
^(.*)$matching all URLs when a more specific pattern was intended - Missing RewriteEngine On: Rules that have no effect because the rewrite engine is not activated
Each rewrite issue includes the specific rule, what it actually does versus likely intent, and a corrected version with proper flags and patterns.
Security and Access Control
The inspector detects security gaps in .htaccess configuration:
- Directory listing enabled: Missing
Options -Indexesexposes file structure when no index file exists - Unprotected sensitive files: Missing rules to block access to
.env,.git,wp-config.php, and backup files - Weak authentication:
AuthType Basicwithout HTTPS sends credentials in base64 (not encrypted) - Server signature: Missing
ServerSignature Offexposes Apache version in error pages - PHP configuration exposure: Allowing access to
phpinfo()output orphp.inifiles
Performance and Deprecated Directives
Beyond security, the inspector identifies configurations that impact performance or use deprecated syntax:
- Deprecated
Order/Deny/Allow: Apache 2.4+ usesRequiredirectives; old syntax causes unexpected behavior in mixed configurations - Excessive .htaccess reliance: Per-request file parsing adds overhead; rules that could be in the virtual host configuration should be moved there
- Missing compression: No
mod_deflateormod_gzipconfiguration for text-based content - Missing caching headers: No
mod_expiresorCache-Controlheaders for static assets
For performance-critical deployments, the inspector recommends migrating .htaccess rules to the main server configuration (httpd.conf or virtual host files) to eliminate per-request file system lookups. Apache must traverse each directory in the URL path looking for .htaccess files on every request, adding measurable latency under high traffic. The inspector distinguishes rules that require .htaccess (user-editable hosting) from those that should be in server config (dedicated servers where admin access is available).
Code Examples
Secure .htaccess Configuration
# Security hardening
Options -Indexes -Multiviews
ServerSignature Off
# Block sensitive files
<FilesMatch "^\.(env|git|htpasswd)$">
Require all denied
</FilesMatch>
# Block backup and config files
<FilesMatch "\.(bak|sql|log|ini|conf)$">
Require all denied
</FilesMatch>
# Security headers
<IfModule mod_headers.c>
Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "SAMEORIGIN"
Header set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>
# HTTPS redirect
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]Frequently Asked Questions
What does the Apache .htaccess Inspector check?
The .htaccess Inspector analyzes your Apache configuration for security issues including exposed directory listings, missing security headers, sensitive file exposure (.env, .git), invalid RewriteRule regex patterns, missing rewrite flags, deprecated directives (Order/Allow/Deny), PHP information disclosure (display_errors), and redirect issues like HTTP downgrades. It calculates a security score and provides actionable fix recommendations.
What is the most common .htaccess security mistake?
The most common mistake is leaving directory listing enabled (Options +Indexes), which exposes your file structure to anyone who navigates to a directory without an index file. Another frequent issue is not protecting sensitive files like .env (which contains database credentials and API keys) and .git directories (which expose source code and commit history).
Why are Order/Allow/Deny flagged as deprecated?
The Order, Allow, and Deny directives were replaced by the 'Require' directive in Apache 2.4 (released in 2012). While they still work with mod_access_compat for backward compatibility, the new syntax is clearer and less error-prone. Replace 'Order deny,allow / Deny from all' with 'Require all denied', and 'Allow from 192.168.1.0/24' with 'Require ip 192.168.1.0/24'.
Why does the tool flag missing RewriteEngine On?
Apache ignores all RewriteRule and RewriteCond directives unless RewriteEngine is explicitly turned on. If you have rewrite rules but forgot 'RewriteEngine On', they will silently do nothing. This is a common issue when copying rewrite rules between servers or when the directive was accidentally removed.
What RewriteRule flags should I use?
Common Apache RewriteRule flags: [L] stops processing further rules (similar to 'break' in Nginx), [R=301] sends a permanent redirect, [R=302] sends a temporary redirect, [NC] makes the pattern case-insensitive, [QSA] appends query strings, [F] returns 403 Forbidden, and [NE] prevents encoding of special characters. Always include [L] to prevent unexpected rule chaining.
How do I protect sensitive files in .htaccess?
Use FilesMatch to deny access to sensitive files: '<FilesMatch "^\.(env|git|htpasswd)"> Require all denied </FilesMatch>'. For directories like .git, use 'RedirectMatch 404 /\.git' to return a 404. You can also use RewriteRule with [F] flag: 'RewriteRule ^\.(env|git) - [F,L]'.
What security headers should I set in .htaccess?
Essential security headers to set via .htaccess: X-Frame-Options (prevents clickjacking), X-Content-Type-Options (prevents MIME sniffing), Referrer-Policy (controls URL leakage), and Strict-Transport-Security (enforces HTTPS). Add them with 'Header always set' directives inside an '<IfModule mod_headers.c>' block.
Is my .htaccess content sent to a server?
No. All analysis happens entirely in your browser using JavaScript. Your .htaccess configuration — which may contain internal paths, IP restrictions, and authentication details — is never transmitted to any server. No data is stored, logged, or shared.
What is the difference between Redirect and RewriteRule?
Redirect is simpler — it matches exact URL prefixes and sends an HTTP redirect response to the client. RewriteRule uses regex patterns and can perform internal URL rewrites (the client never sees the real path) or external redirects. Use Redirect for simple path changes, and RewriteRule when you need pattern matching, conditional logic (RewriteCond), or internal rewrites.