b2KIT

Apache Security Config Generator

Generate secure Apache .htaccess and httpd.conf snippets for TLS, headers, mod_security, and access control.

Tested tool guide Tested browser tools Checked August 16, 2026

What Apache Security Config Generator does, with a checked example

This tool composes Apache configuration snippets from a checklist of hardening choices: TLS protocol and cipher settings, security headers, ModSecurity rule stanzas, and access control. You pick a target - a .htaccess file or a virtual host inside httpd.conf - select the controls you want, and it emits ready-to-paste directives tied to a specific Apache version. The surprise most users hit: .htaccess is not the server config. TLS directives like SSLCipherSuite and SSLProtocol only take effect at server or virtual-host level, and .htaccess rules are ignored entirely unless the main config's AllowOverride permits them. A snippet valid in one place silently does nothing in the other.

Worked example

A concrete input and expected output from the current implementation.

Input

Target: .htaccess on Apache 2.4. Options: disable directory listing; deny direct access to .htaccess and .htpasswd files.

Expected output

Options -Indexes

<FilesMatch "^\.ht">
    Require all denied
</FilesMatch>

Options -Indexes stops Apache from generating an automatic index when no index file exists, and the FilesMatch block returns 403 for any file whose name starts with .ht, covering both .htaccess and .htpasswd. Require is Apache 2.4 syntax; the 2.2 equivalent would be Order allow,deny with Deny from all.

How the result is produced

1

Context-aware directive selection

Every Apache directive carries a documented context, and the tool enforces it. Output for httpd.conf may include server-level SSL settings (SSLProtocol, SSLCipherSuite, SSLHonorCipherOrder) and LoadModule lines; .htaccess output sticks to directory-context directives such as Options, Header, RewriteRule, and Require. Pasting a server-level directive into .htaccess makes Apache reject the file with a 500 error ("not allowed here"), so the split keeps the output paste-ready.

2

Version-matched access control

Apache 2.2 and 2.4 express access rules differently: 2.2 uses Order, Allow, and Deny; 2.4 uses Require (Require all granted, Require ip 192.0.2.10, Require valid-user). The generator asks for the major version and emits the matching form. It also separates web-server directives from ModSecurity ones, since SecRule stanzas only run when the separate ModSecurity module is loaded and its rule engine is enabled at the server level.

Good uses

  • Hardening a shared-hosting site where you control only .htaccess: disable directory listing, block dotfiles, restrict an admin path by IP with Require ip, and add X-Frame-Options and Content-Security-Policy headers.
  • Drafting a TLS stanza for a new virtual host in httpd.conf, with modern protocol and cipher settings to paste in before the certificate directives.
  • Adding ModSecurity rules to an existing WAF deployment, such as a SecRuleRemoveById entry that re-enables a Core Rule Set rule causing false positives on a specific path.

Limits and checks

  • The output cannot verify your server. If AllowOverride in httpd.conf does not grant the directive group your rules need, the .htaccess is ignored silently - no error, no effect. Confirm by checking that a blocked path really returns 403.
  • Snippets assume modules are loaded: Header needs mod_headers, RewriteRule needs mod_rewrite, TLS needs mod_ssl, and SecRule stanzas need ModSecurity, a third-party module not bundled with Apache. On a stock server you get "Invalid command" errors or 500s until those modules are enabled.
  • ModSecurity rule IDs are not universal. SecRuleRemoveById assumes a specific OWASP Core Rule Set version: if the installed CRS does not define the ID, the directive is a silent no-op, and the false positive you meant to disable keeps firing.

Common questions

Can I paste the output straight into my production server?

Only after checking the prerequisites the generator cannot see: whether the host permits .htaccess overrides, whether mod_headers, mod_rewrite, mod_ssl, or ModSecurity are loaded, and which Apache major version actually runs. Verify with curl -I that the headers arrive, force a 403 on a blocked path, and run the TLS setup through a check like SSL Labs before calling it done.

Will these snippets protect my site from attacks?

Not by themselves. The output hardens the web server: it hides directory listings, sends security headers, and can filter request patterns. Application-level flaws - SQL injection, XSS, broken authentication - live in your code and remain reachable unless you also patch the app. Treat the generated config as one layer in a defense-in-depth setup, not a substitute for secure code.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools