.htaccess-Generator: Security-Header & HSTS

Was macht der .htaccess-Generator?

Der Generator ist ein Editor für Apache-Konfigurations-Regeln. Du wählst aus 15 Regel-Typen (Redirects, Rewrites, Sicherheits-Header, HTTPS-Erzwingen, Cache-Control, IP-Block, Hotlink-Schutz, HTTP-Basic-Auth, Sperre für sensible Dateien und mehr), passt jede Regel pro Feld an und bekommst eine sauber strukturierte .htaccess zurück, inklusive <IfModule>-Guards pro Regel, optionalem <IfVersion>-Dual-Output für alte Shared-Hoster, und Cloudflare-Pages-Export für _headers und _redirects. Alles passiert im Browser. Kein Upload, kein Account, kein Cookie-Banner.

Die vier Voreinstellungen decken die häufigsten Stack-Konstellationen ab:

• Moderne Sicherheits-Header: CSP-Starter, HSTS preload-ready, Permissions-Policy, COOP, X-Content-Type-Options, Referrer-Policy.
• Statische Seite, Performance: Cache-Control + Expires für JS/CSS/Bilder/Fonts, Deflate-Kompression für Text-MIMEs.
• HSTS Preload-Pipeline, komplette Vorbereitung für die hstspreload.org-Submission.
• WordPress-Härtung: sperrt wp-config.php, xmlrpc.php und die PHP-Dateien direkt in wp-includes, dazu .env, .git, Editor-Sicherungen und Logdateien. Beim Laden erscheint der Hinweis, dass die Zeilen an die bestehende .htaccess angehaengt gehören: wer den Download eins zu eins hochlädt, löscht den Permalink-Block und bekommt auf jedem Beitrag einen 404.

Welche Regel-Typen sind eingebaut?

Vierzehn Regel-Typen, gegliedert nach Funktion:

• Routing: Redirect (301/302/303/307/308), Rewrite-Pattern, www ↔ non-www, HTTPS erzwingen, Trailing-Slash hinzufügen oder entfernen.
• Header: Sicherheits-Header-Block mit CSP, Permissions-Policy, HSTS, COOP, Referrer-Policy.
• Zugriff: IP-Allow-Liste (gesamte Seite oder nur Admin-Bereich), IP-Block-Liste, HTTP-Basic-Auth mit Realm und .htpasswd-Pfad.
• Inhalt: Custom-Error-Documents (401/403/404/500), Directory-Listing an/aus, Cache-Control mit max-age und immutable, Compression mit MIME-Type-Liste.
• Schutz, Hotlink-Protection mit Referer-Allowlist.

Jede Regel zeigt unter ihrem Header die benötigten Apache-Module als Badge. So siehst du auf einen Blick, ob dein Hoster mod_rewrite, mod_headers, mod_deflate und Co. bereitstellt.

Wie funktioniert der Apache-2.4-vs-2.2-Dual-Modus?

Die meisten Shared-Hoster laufen 2026 auf Apache 2.4. Die Zugriffs-Direktiven haben sich aber zwischen 2.2 und 2.4 grundlegend geändert: Statt Order Allow,Deny plus Allow from nutzt 2.4 die neue Require-Direktive. Wer auf einem Legacy-Hoster ausrollt, schaltet im Generator den 2.4+2.2-Dual-Modus an, dann emittiert der Generator beide Syntax-Varianten in <IfVersion>-Blöcke verpackt. Apache liest nur den passenden Block, und du musst nicht zwei separate .htaccess-Dateien pflegen.

Der Trade-off: <IfVersion> selbst braucht mod_version, das auf den meisten 2.4ern dabei ist, aber nicht auf jedem 2.2er. Der Generator wickelt deshalb die Dual-Blöcke zusätzlich in einen <IfModule mod_version.c>-Guard.

Was macht die HSTS-Preload-Checkliste?

Aktivierst du in einer Sicherheits-Header-Regel das HSTS-Flag, erscheint oberhalb der Regel-Liste eine Checkliste. Sie schaut die anderen Regeln durch und meldet, was die hstspreload.org-Einreichung sonst zurückweist:

• Fehlt ein HTTPS-Redirect? → wird gemeldet.
• Ist includeSubDomains im HSTS-Header? → wird geprüft.
• Ist preload im HSTS-Header? → wird geprüft.

Wenn alles grün ist, bietet der Link direkt die Einreichungs-Maske von hstspreload.org an. So vermeidest du den klassischen Fall, dass die Domain abgelehnt wird, weil der Submission-Workflow nicht verstanden wurde.

Welche Sicherheits-Header lohnen sich wirklich?

Die Mozilla Web Security Guidelines und der OWASP Secure Headers Project listen die folgenden Header als Pflicht-Set für moderne Web-Anwendungen. Der Generator deckt sie alle ab:

• Strict-Transport-Security, erzwingt HTTPS in Browsern für die nächste Periode (max-age 1 Jahr Standard, preload-ready). Pflicht für jede Seite, die irgendwann mal über HTTP erreichbar war.
• Content-Security-Policy: Allow-Liste für Skripte, Styles, Bilder, Fonts. Verhindert Cross-Site-Scripting und Mixed-Content. Komplex zu tunen, daher der Validator-Hinweis.
• Permissions-Policy, sperrt Browser-APIs (Kamera, Mikrofon, Geolocation, Payment Request, Sensors), die deine Seite nicht braucht. Default: alles aus.
• Cross-Origin-Opener-Policy, same-origin isoliert das Fenster gegen window.opener-Tampering und schaltet SharedArrayBuffer frei (relevant für WebAssembly-Tools).
• Referrer-Policy, strict-origin-when-cross-origin schickt den vollen Referer nur an die eigene Domain, an Drittseiten nur die Origin. Balance zwischen Analytics-Bedarf und Privacy.
• X-Content-Type-Options, nosniff verhindert MIME-Sniffing-Attacken auf Dateien mit ungesetztem Content-Type-Header.

Der Generator wickelt alle sechs in einen einzigen <IfModule mod_headers.c>-Block und gibt den Block als zusammenhängende Einheit aus. Wer einen Header nicht braucht, deaktiviert die entsprechende Checkbox oder löscht den Wert im Textfeld, die Zeile fällt automatisch aus dem Output.

Wie funktioniert der Cloudflare-Pages-Export?

Cloudflare Pages liest keine .htaccess. Stattdessen erwartet die Plattform zwei Dateien im Web-Root:

• _headers, Path-Pattern plus HTTP-Response-Header. Format: Pfad-Zeile + eingerückte Key: Value-Zeilen.
• _redirects, Source-Pfad, Destination-Pfad, Status-Code pro Zeile.

Der Generator emittiert aus derselben Regel-Liste beide Dateien. Sicherheits-Header und Cache-Control gehen in _headers, einzelne Pfad-Redirects in _redirects. Du wechselst einfach den Output-Tab. Was auf den Hostnamen zielt, also HTTPS-Zwang und www-Kanonisierung, lässt sich in _redirects nicht ausdrücken, weil die Datei nur Pfade vergleicht. Der Export schreibt dort einen Kommentar mit dem Grund, statt eine Zeile, die Cloudflare ohne Fehlermeldung verwirft.

Damit wird ein häufiger Pain-Point gelöst: Wer von Shared-Hosting auf eine Edge-Plattform migriert, muss seine .htaccess sonst manuell in zwei andere Dateien übersetzen. Der Generator macht das automatisch, gleiche Regel-Liste, drei Output-Formate.

Welche Fehler treten am häufigsten auf?

Drei Klassiker, die bei Production-Deploys einer neuen .htaccess immer wieder auftauchen, und der Generator versucht jeden zu vermeiden:

1. 500 Internal Server Error nach dem Upload, das ist fast immer eine Direktive ohne geladenes Modul. Klassisch: Header set … auf einem Hoster ohne mod_headers. Der Generator wickelt deshalb jede Regel in einen <IfModule>-Guard. Wenn du trotzdem einen 500er siehst, prüfe als Erstes das error.log deines Hosters.
2. Endlos-Redirect-Loop bei HTTPS-Erzwingen hinter einem Reverse-Proxy, Cloudflare und ähnliche CDNs leiten den Request schon HTTPS-terminiert weiter; Apache sieht aber %{HTTPS} als off, weil die Verbindung Proxy → Origin HTTP ist. Lösung: Statt %{HTTPS} prüfst du %{HTTP:X-Forwarded-Proto}. Dafür gibt es den Schalter „Hinter CDN oder Reverse-Proxy“ an der HTTPS-Regel, er ergänzt die zweite Bedingung.
3. CSP blockiert eigene Inline-Skripte, passiert, wenn die Standard-CSP ohne 'unsafe-inline' ausgespielt wird, deine Seite aber noch Inline-Skripte enthält. Zwei Wege: Inline-Skripte in separate Dateien auslagern (sauberer Weg, langfristig), oder per Nonce-/Hash-Whitelist die verbleibenden Inlines explizit erlauben. Der externe CSP-Evaluator zeigt genau, welche Inlines die Policy gerade blockt.

Diese drei Pain-Points sind in den FAQ-Antworten verlinkt, der Generator selbst kann sie nicht verhindern, aber er kommuniziert sie ehrlich.

Wie ist die Privacy geregelt?

Pure-client. Der Generator läuft komplett im Browser. Es gibt keinen Server-Endpunkt für Regel-Validierung, keinen Telemetrie-Aufruf, keinen Cookie, keinen Account. Wenn du das Tab schließt, ist deine Regel-Liste weg, der Generator persistiert nichts. Wer einen Verlauf braucht, lädt nach jedem Edit die .htaccess herunter und versioniert sie im Repo, wo sie sowieso hingehört.

Was ist absichtlich nicht gebaut?

• Kein nginx-Konverter, htaccess-zu-nginx ist ein separates Tool im Backlog, weil die Direktiv-Mappings zu umfangreich für einen Inline-Tab sind.
• Kein .htpasswd-Generator inline, der Passwort-Datei-Generator ist Schwester-Tool htpasswd-generator (kommt). HTTP-Basic-Auth-Regel verweist im Output auf die nötige Datei.
• Keine Bot-Blocker-Mega-Liste, User-Agent-basiertes Sniffing ist 2026 als Schutz weitgehend ineffektiv und produziert False-Positives. Wer Bots blocken will, nutzt eine WAF auf Edge-Ebene.
• Keine Server-seitige Validierung, würde einen Server-Roundtrip brauchen und bricht das Pure-Client-Versprechen. Was sich ohne Server prüfen lässt, also Syntax, Modul-Abhängigkeiten, Regelreihenfolge und Weiterleitungsketten, macht der .htaccess-Prüfer.
• Kein mod_security-Ruleset-Editor, zu spezialisiert für ein Generator-Tool. Wer mod_security tunt, arbeitet direkt mit der OWASP-CRS-Konfiguration.

Wo finde ich mehr Details?

• Apache HTTP Server Dokumentation 2.4, offizielle Direktiven-Referenz
• .htaccess auf Wikipedia: Geschichte, Funktionsweise, Beispiele
• hstspreload.org, Submission-Liste für HSTS-Preload-Domains
• CSP Evaluator, externer Validator für Content-Security-Policy-Werte
• Cloudflare-Pages-Headers-Doku, _headers-Syntax-Referenz
• Cloudflare-Pages-Redirects-Doku, _redirects-Syntax-Referenz