kittokit
DE
DEV-TOOL

.htaccess-Generator — Security-Header & HSTS

Regeln zusammenklicken, Modul-Abhängigkeiten sehen, gleich für Apache 2.4 und Cloudflare Pages exportieren. Mit HSTS-Preload-Checkliste.

Läuft lokal im Browser — Regeln werden im Speicher emittiert, nichts wird hochgeladen.

Voreinstellungen

Stack laden, dann Regel-für-Regel anpassen.

Apache-Version

2.4 ist der moderne Standard. 2.4+2.2-Dual erzeugt eine Fallback-Variante für ältere Shared-Hoster.

Benötigte Apache-Module 2

Auf Shared-Hostern, die ein Modul nicht laden, fällt die jeweilige Regel still aus — der Generator wickelt jede Regel in einen <IfModule>-Guard.

mod_rewritemod_headers
HSTS Preload-Vorbereitung Bereit für hstspreload.org
Zur Einreichung auf hstspreload.org

Regeln 2

HTTPS erzwingen mod_rewrite
Sicherheits-Header mod_headers
# .htaccess generated by kittokit htaccess-generator
# Validate Content-Security-Policy at csp-evaluator.withgoogle.com before deploying.
# Validate HSTS preload eligibility at hstspreload.org.

# ── Enforce HTTPS ──
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
</IfModule>

# ── Security headers ──
<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
  Header set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-ancestors 'none'; base-uri 'self'; form-action 'self'"
  Header set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), magnetometer=(), gyroscope=(), accelerometer=(), interest-cohort=(), browsing-topics=(), fullscreen=(self)"
  Header set Cross-Origin-Opener-Policy "same-origin"
  Header set X-Content-Type-Options "nosniff"
  Header set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

So funktioniert es
  1. 01

    Text oder Code einfügen

    Füge deinen Inhalt in das Eingabefeld ein oder tippe direkt.

  2. 02

    Automatische Verarbeitung

    Das Tool verarbeitet den Inhalt sofort und zeigt das Ergebnis.

  3. 03

    Ergebnis kopieren

    Kopiere das Ergebnis mit einem Klick in die Zwischenablage.

Datenschutz

Alle Berechnungen laufen direkt in deinem Browser. Keine Daten werden auf Server übertragen.

Eine `.htaccess` Regel für Regel aufbauen statt fünf Snippets aus Stack-Overflow zusammenstoppeln. Du wählst Voreinstellungen (Sicherheits-Header, Static-Site-Performance, HSTS-Preload-Pipeline, WordPress-Härtung), passt Regel für Regel an, und der Generator zeigt dir die benötigten Apache-Module pro Regel. Optional kannst du dieselben Regeln als Cloudflare-Pages-`_headers`- und `_redirects`-Dateien exportieren.

01 — Anleitung

Wie benutzt du dieses Tool?

  1. Voreinstellung wählen oder mit leerer Liste starten. Vier kuratierte Stacks decken die häufigsten Use-Cases ab.
  2. Apache-Version festlegen: 2.4 (modern) oder 2.4+2.2-Dual (mit `<IfVersion>`-Fallback für ältere Shared-Hoster).
  3. Regeln hinzufügen, entfernen, neu sortieren. Pro Regel siehst du, welches Apache-Modul sie braucht.
  4. Bei aktivierter HSTS-Regel erscheint die Preload-Checkliste — sie zeigt direkt, was vor der hstspreload.org-Einreichung fehlt.
  5. Output-Tab wechseln: `.htaccess`, Cloudflare-Pages-`_headers` oder `_redirects`. Kopieren oder herunterladen — alles bleibt lokal.

Was macht der .htaccess-Generator?

Der Generator ist ein Editor für Apache-Konfigurations-Regeln. Du wählst aus 14 Regel-Typen (Redirects, Rewrites, Sicherheits-Header, HTTPS-Erzwingen, Cache-Control, IP-Block, Hotlink-Schutz, HTTP-Basic-Auth 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 — Schutz für wp-config.php, wp-includes, XML-RPC.

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, Redirect-/HTTPS-Erzwingen-/www-Canonical-/Trailing-Slash-Regeln gehen in _redirects. Du wechselst einfach den Output-Tab.

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}. Der Generator emittiert die Standard-Variante; wer hinter einem CDN sitzt, passt die Bedingung manuell an.
  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 Server-Roundtrip brauchen, bricht das Pure-Client- Versprechen. Für Live-Tests verweist die FAQ auf den externen Tester von madewithlove.
  • 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?

Zuletzt aktualisiert:

Das könnte dir auch gefallen