.htaccess-Referenz

Die Website mit einer .htaccess-Datei steuern? Was ist das eigentlich genau? Bevor es mit Weiterleitungen, Zugriffskontrollen oder Sicherheitsregeln losgeht, lohnt sich ein Blick auf die Grundlagen. Dieser Abschnitt erklärt, was es mit der .htaccess auf sich hat, wie sie aktiviert wird und warum sie manchmal scheinbar keine Wirkung zeigt.

📘 Was ist die .htaccess und wozu wird sie genutzt?

Die .htaccess-Datei (sprich: „dot htaccess“ oder einfach „htaccess“) ist eine Konfigurationsdatei für den Webserver Apache. Sie ermöglicht es, serverseitige Einstellungen direkt im Verzeichnis einer Website vorzunehmen – ganz ohne Zugriff auf die zentrale Serverkonfiguration.

Das macht sie besonders nützlich für Shared-Hosting-Umgebungen oder Projekte, bei denen kein direkter Zugriff auf die globale httpd.conf i Zentrale Konfigurationsdatei des Apache-Webservers. Sie legt serverweite Einstellungen wie Module, Virtual Hosts und globale Direktiven fest. Wird beim Serverstart geladen und gilt im Gegensatz zur .htaccess für den gesamten Server. besteht.

Was kann man mit einer .htaccess machen?

• Umleitungen (z. B. 301-Redirects für geänderte URL's)
• Paßwortschutz einzelner Verzeichnisse oder Dateien
• Rewrite-Regeln zur „schöneren“ URL-Gestaltung ( mod_rewrite i Apache-Modul, das URL-Umschreibungen ermöglicht. )
• Zugriffsbeschränkungen nach IP, Datei, Typ oder Host
• Cookies Setzen, Prüfen, Auslesen, Löschen
• MIME-Typen oder Caching beeinflussen
• Sicherheitsmaßnahmen wie das Blockieren gefährlicher Aufrufe
• PHP-Einstellungen ändern (bei aktiviertem mod_php)

⚠️ Hinweise zur Nutzung der .htaccess- Datei

Wo befindet sich die .htaccess- Datei?

Die Datei .htaccess liegt meist im Wurzelverzeichnis der Website (z. B. / oder /htdocs), kann aber auch in beliebigen Unterverzeichnissen platziert werden. Apache wendet sie dann rekursiv auf alle Unterverzeichnisse an.
Das bedeutet: Die darin definierten Einstellungen gelten nicht nur für das Verzeichnis selbst, sondern auch für alle darunterliegenden Ordner – sie werden also vererbt.
Die Vererbung kann durch weitere .htaccess-Dateien in Unterordnern überschrieben oder ergänzt werden.

Wenn keine .htaccess zu sehen ist

Gerade bei günstigem Shared Hosting kommt es häufig vor, daß die .htaccess-Datei nicht zu sehen ist – obwohl sie existiert oder erstellt werden kann. Das liegt daran, daß Dateien mit einem Punkt am Anfang im Web und per FTP oft als „versteckt“ behandelt werden.

1. Sichtbarkeit im FTP-Programm aktivieren

Viele FTP-Programme zeigen versteckte Dateien nicht standardmäßig an. In FileZilla läßt sich das z. B. über Server > Auflistung versteckter Dateien erzwingen oder durch die Option -a bei benutzerdefiniertem Servertyp einstellen.

2. Web-Dateimanager nutzen

Der (gute) Hosting-Anbieter stellt meistens einen Datei-Manager im Webinterface zur Verfügung. Dort läßt sich oft einstellen, daß auch versteckte Dateien angezeigt werden sollen.

3. Datei per Skript erstellen

Wenn beides nicht funktioniert, dann selbst eine .htaccess-Datei über ein einfaches PHP-Skript erstellen oder bearbeiten:

file_put_contents('.htaccess', "RewriteEngine On\nRewriteRule ^test$ test.html [L]");

Das Skript im Browser aufrufen, um die Datei zu schreiben – und danach aus Sicherheitsgründen direkt wieder löschen.

4. Umbenennen von htaccess.txt

Wenn das System das Anlegen von Dateien mit Punkt am Anfang blockiert, kann zuerst eine htaccess.txt hochgeladen und anschließend per Dateimanager oder PHP- Skript in .htaccess umbenannt werden.

rename("htaccess.txt", ".htaccess");

AllowOverride und warum die .htaccess vielleicht nicht wirkt

Die .htaccess-Datei erlaubt es, Konfigurationen direkt in einem Verzeichnis zu setzen – etwa Weiterleitungen, Zugriffsschutz oder Umschreiberegeln. Aber: Apache muss dies auch zulassen. Die zentrale Direktive dafür heißt AllowOverride und wird in der Apache-Hauptkonfiguration gesetzt.

Was macht AllowOverride?

Mit AllowOverride wird gesteuert, ob Apache die .htaccess-Dateien überhaupt berücksichtigt und welche Direktiven darin erlaubt sind. Wenn es auf None steht, wird die .htaccess schlicht ignoriert.

<Directory /var/www/html>
AllowOverride None
</Directory>

Um alle typischen Regeln in .htaccess zuzulassen, muss stattdessen AllowOverride All gesetzt sein:

<Directory /var/www/html>
    AllowOverride All
</Directory>

Die häufigsten Optionen:

• None – ignoriert .htaccess komplett
• All – erlaubt alle Direktiven
• AuthConfig – Erlaubt z. B. AuthType i Legt fest, welches Authentifizierungsverfahren der Server verwendet – meist Basic oder Digest. (Basic / Digest), Require
• FileInfo – Für RewriteRule i Anweisung, um URLs anhand von Mustern umzuschreiben (mod_rewrite). , Redirect i Einfaches Umleitungskommando, um URLs dauerhaft oder temporär weiterzuleiten. usw.
• Indexes – Verzeichnislisten
• Limit – Zugriffsregeln wie Deny, Allow
• Options – Bestimmte Options-Anweisungen

Funktionstest: Wird die .htaccess überhaupt verarbeitet?

Wenn es keinen Zugriff auf die Apache-Konfiguration gibt (z. B. bei Shared Hosting), kann dies nur indirekt getestet werden:

1. Erstellen einer .htaccess mit folgendem Inhalt:

Deny from all

Require all denied

<IfModule mod_access_compat.c>
    Deny from all
</IfModule>
<IfModule mod_authz_core.c>
    Require all denied
</IfModule>

2. Eine Datei im selben Verzeichnis aufrufen.
3. Wenn ein 403-Fehler kommt, wird die .htaccess verarbeitet – sonst nicht.

Alternativ: Mit RewriteRule testen, ob mod_rewrite funktioniert:

RewriteEngine On
RewriteRule ^testseite$ /index.html [R=302,L]

Wenn die Weiterleitung funktioniert, ist mod_rewrite aktiv und AllowOverride FileInfo (oder All) gesetzt.

PHP-Hinweis

Wenn PHP als Apache-Modul läuft, kann mit apache_get_modules() geprüft werden, ob z. B. mod_rewrite geladen ist:

print_r(apache_get_modules());

Das zeigt jedoch nur, ob das Modul geladen ist – nicht, ob es in .htaccess verwendet werden darf.

Grundlegendes

AllowOverride entscheidet darüber, ob eine .htaccess beachtet wird. Bei Problemen lohnt sich immer ein kurzer Test. Wenn Regeln nicht greifen, ist oft nicht die Syntax schuld – sondern die fehlende Erlaubnis durch Apache.

Bestimmte Dateien vor Zugriff schützen

Mit diesem Code lässt sich der Zugriff auf eine konkrete Datei verhindern – etwa die .htaccess selbst. Natürlich kann jede beliebige Datei angegeben werden:

<Files .htaccess>
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order allow,deny
Deny from all
</IfModule>
</Files>

Warum 'mod_authz_core.c'?

Mit Apache 2.4 wurde das Modul 'mod_authz_core' eingeführt, das die neuen Require-Direktiven bereitstellt. Alte Versionen (Apache 2.2) nutzen stattdessen Order/Deny. <IfModule> prüft dabei nicht die Apache-Version, sondern nur, ob ein Modul geladen ist. Fehlt das Modul, wird der Block ignoriert, es entsteht kein Fehler.
So kann <IfModule mod_authz_core.c> für Apache 2.4 und <IfModule !mod_authz_core.c> für Apache 2.2 verwendet werden, um eine versionsübergreifend funktionierende Zugriffskontrolle zu gewährleisten.

Alte und neue Version einzeln:

<Files .htaccess>
Order allow,deny
Deny from all
</Files>

<Files .htaccess>
Require all denied
</Files>

Siehe auch: 'Versteckte und sensible Dateien schützen'

Zugriff temporär einschränken (z.B. Wartungsmodus)

Statt alle Zugriffe hart zu blockieren, ist es nutzerfreundlicher, Besucher bei Wartungsarbeiten auf eine temporäre Seite weiterzuleiten.
Statische Dateien (CSS, JS, Bilder, Fonts) müssen dabei aber weiterhin direkt auslieferbar bleiben, da sie sonst als HTML zurückkommen und vom Browser blockiert werden (MIME-Typ-Fehler). Jegliches Design wäre somit zum Scheitern verurteilt:

RewriteEngine On

# Wartungsseite selbst nicht umleiten
RewriteRule ^wartung\.html$ - [L]

# Statische Dateien immer erlauben (verhindert MIME-Typ-Fehler)
RewriteRule \.(css|js|png|jpg|svg|webp|woff2?)$ - [L,NC]

# Eigene IP freigeben
RewriteCond %{REMOTE_ADDR} ^123\.123\.123\.123$
RewriteRule ^ - [L]

# Alle übrigen Anfragen auf Wartungsseite umleiten
RewriteRule ^ /wartung.html [R=302,L]

• Besucher sehen wartung.html.
• CSS, Bilder und Skripte werden nicht umgeleitet
• Nur die angegebene IP hat weiterhin Zugriff auf die eigentliche Webseite.
• Kein falscher Content-Type, keine Browserfehler

Erklärung

Aktiviert das URL-Rewriting. Ohne diese Zeile funktionieren alle RewriteRule und RewriteCond nicht.

• Stoppt die Weiterleitung für die Wartungsseite selbst.
• - bedeutet: keine Änderung an dieser URL.
• [L] = „Last“ → nach dieser Regel werden keine weiteren Regeln für diese Anfrage ausgeführt.
• Wichtig, damit die Seite wartung.html nicht auf sich selbst umgeleitet wird, sonst Endlosschleife.

• Assets (CSS, JS, Bilder, Fonts) werden nicht umgeleitet.
• Verhindert den bekannten MIME-Typ-Fehler: Browser erwartet CSS/JS, bekommt aber HTML.
• [NC] = „No Case“, also Groß-/Kleinschreibung egal.
• [L] = Stoppt die Regelkette für diese Dateien.

• IP-Ausnahme: z. B. Entwickler oder Admin können die Seite weiterhin normal aufrufen.
• RewriteCond prüft, ob die IP stimmt.
• RewriteRule ^ - [L] bedeutet: URL bleibt unverändert, keine weiteren Regeln werden angewendet.

• Catch-All für alle anderen Besucher.
• Jede Anfrage, die bisher nicht abgefangen wurde, wird auf wartung.html weitergeleitet.
• [R=302] = temporäre Weiterleitung (Browser merkt sie sich nicht dauerhaft).
• [L] = letzte Regel, danach keine weiteren Prüfungen.

Eine erweiterte Version mit mehr, als nur einer IP gibt es weiter unten.

Nach einer Änderung der htaccess am besten die Checkliste Wartungsseite einrichten abarbeiten!

Zugriff ermöglichen mit Cookies.

Wenn man nicht alle Personen sperren und bestimmten externen Kräften Zugriff gewähren möchte, läßt sich das Konzept aus dem Wartungsmodus übernehmen und erweitern:

• Statt die IP vorher zu erfragen, kann man z. B. über die htaccess Cookies setzen, um den Zugriff auf die alte Domain oder bestimmte Seiten temporär zu erlauben.
• So können Mitarbeitende oder Technische Fachkräfte Inhalte prüfen, die noch nicht auf die neue Domain kopiert wurden, oder auf Seiten zugreifen, die wegen PHP-Updates oder Versionserhöhungen temporär defekt sind.
• Die bestehende Weiterleitung oder Wartungsregel bleibt dabei ungestört, der normale Besucher sieht weiterhin die Standardseite oder wird auf eine andere Domain weitergeleitet.

Nötig sind dafür nur wenige Zeilen in der htaccess der alten Domain:

Weiterleitung

RewriteCond %{QUERY_STRING} (^|&)editor=true(&|$) [NC]
RewriteRule ^ - [CO=editor:true:.alte-domain.de:86400:/]

RewriteCond %{HTTP_COOKIE} !editor=true
RewriteRule ^ https://www.neue-domain.de%{REQUEST_URI} [L,R=301]

Erklärung

RewriteCond %{QUERY_STRING} (^|&)editor=true(&|$) prüft auf Existenz von editor=true in der URL. CO=editor:true:.alte-domain.de:86400:/ setzt dann den Cookie editor=true für 1 Tag (86400 Sekunden) auf allen Subdomains und der alten Hauptdomain.

RewriteCond %{HTTP_COOKIE} !editor=true prüft, ob der Cookie fehlt und leitet dann alle Anfragen auf die neue Domain weiter.

Nutzung

Einmalig https://alte-domain.de/seite.html?editor=true aufrufen. Danach können alle Seiten auf der alten Domain für 1 Tag ohne Weiterleitung genutzt werden. Wenn der Tag abläuft, den Link erneut aufrufen, um den Cookie zu erneuern.

Vorteile

• Normale Besucher landen sofort auf der neuen Domain.
• Redakteure oder Helfer haben einfachen Zugriff auf die alte Domain.
• Keine Änderung an bestehenden Links der alten Domain nötig.
• Temporär und leicht rücksetzbar.

Kombination von Wartungsmodus mit IP- Ausnahme und Cookie für unbekannte IP's

Die Kombination von Wartungsmodus mit eigener Wartungsseite, einer freigegebenen IP und der Cookie- Option für unbekannte IP's von externen Fachkräften, zeigt das nächste Beispiel.

RewriteEngine On

# Cookie setzen (Freigabe über URL-Parameter)
RewriteCond %{QUERY_STRING} (^|&)editor=true(&|$) [NC]
RewriteRule ^ - [CO=editor:true:.meine-domain.de:86400:/,L]

# Wartungsseite selbst nicht umleiten
RewriteRule ^wartung\.html$ - [L]

# Statische Dateien immer freigeben (verhindert MIME-Typ-Fehler)
RewriteRule \.(css|js|png|jpg|svg|webp|woff2?)$ - [L,NC]

# Eigene IP freigeben
RewriteCond %{REMOTE_ADDR} ^123\.123\.123\.123$
RewriteRule ^ - [L]

# Cookie-basierte Freigabe
RewriteCond %{HTTP:Cookie} editor=true
RewriteRule ^ - [L]

# Alle übrigen Anfragen auf Wartungsseite umleiten
RewriteRule ^ /wartung.html [R=302,L]

• Besucher ohne IP- oder Cookie-Freigabe sehen wartung.html
• Externe mit ?editor=true erhalten ein zeitlich begrenztes Cookie
• CSS, JS, Bilder und Fonts werden nicht umgeleitet
• Keine falschen MIME-Typen, keine Browserfehler

Nach dem Aktivieren in der htaccess die 'Checkliste Wartungsseite einrichten' abarbeiten!

• Wartungsseite direkt aufrufen – Seite wird angezeigt, Content-Type: text/html
• CSS direkt aufrufen – Content-Type: text/css, keine Weiterleitung auf Wartungsseite
• JS direkt aufrufen – Content-Type: application/javascript, keine Weiterleitung
• Bilder direkt aufrufen – korrekter Content-Type, keine Weiterleitung
• Zugriff von gesetzter IP – normale Seite wird geladen
• Zugriff mit Cookie (z. B. ?editor=true) – normale Seite wird geladen
• Zugriff ohne IP/Cookie – Weiterleitung auf wartung.html
• Browser Console – keine Fehler beim Laden von Assets

Zugriff nur für bestimmte IPs erlauben

Mit dieser Konfiguration erhält nur die angegebene IP-Adresse Zugriff – alle anderen werden abgewiesen:

Require ip 123.123.123.123

Einzelne IP's blocken

Es gibt Seitenbesucher, die sind schlimmer, als eine Schmeißfliege am Kuhfladen. Gegen diese läßt sich mit der .htaccess unter Umständen etwas unternehmen. Das Beispiel sperrt ihren Zugriff auf die Website.
Um das Beispiel zu nutzen, müssen natürlich die entsprechenden IP- Adressen gesetzt werden. Die Nachfolgenden dienen nur der Anschauung.

Order Deny,Allow     
Deny from 123.123.123.123
Deny from 145.145.145.145

Wenn die 'Schmeißfliegen' sich dadurch nicht vertreiben lassen und z. B. einfach die nächstfolgende IP nutzen, könnte das Blockieren des Subnetzes vielleicht zum Erfolg führen:

Order Deny,Allow
Deny from 123.112.0.0/12                         
Deny from 145.144.0.0/12

Um auf leichte Art an die Subnetze zu kommen, einfach das kostenlose Tool C.A.S.P.R. nutzen.

Ab Apache 2.4 ändert sich die Syntax etwas:

<RequireAll>
Require all granted
Require not ip 123.123.123.123
Require not ip 145.145.145.145
</RequireAll>

<RequireAll>
Require all granted
Require not ip 123.112.0.0/12
Require not ip 145.144.0.0/12
</RequireAll>

Die IP-Adressen 123.123.123.123, 145.145.145.145 sowie deren Subnetze 123.112.0.0/12 und 145.144.0.0/12 wurden willkürlich gewählt. Alle dazu getroffenen Angaben/Aussagen haben bestenfalls keinen realen Bezug.

Falls das alles nichts hilft, könnte vielleicht die htaccess- Firewall weiter helfen.

Ausnahmen für bestimmte Dateien erlauben

Manche Crawler hören nicht auf, Dateien wie robots.txt zu laden, selbst wenn ihre IP blockiert wurde. Folgende Regel erlaubt den Zugriff auf diese Dateien:

<FilesMatch "^(robots\.txt|sitemap\.xml)$">
Require all granted
</FilesMatch>

Unerwünschte Clients anhand User-Agent blockieren

Diese Methode blockiert bestimmte Programme anhand des User-Agent. Für mehrere Einträge wird die [OR]-Bedingung mehrfach gesetzt:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^BadBot1 [OR]
RewriteCond %{HTTP_USER_AGENT} ^BadBot2 [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebScraper
RewriteRule ^.*$ - [F,L]

Beispiel: bestimmten Crawler sperren

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^BackWeb
RewriteRule ^.*$ - [F,L]

Um zu vermeiden, daß Bilder von der eigenen Webseite auf fremden Seiten eingebettet werden, hilft dieser Code. Er verhindert fremde Referer:

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?meineDomain\.de/ [NC]
RewriteRule \.(jpg|jpeg|gif|png)$ - [F]

Eigene Startseite festlegen – Variante 1

Wenn die Startseite z.B. index-xy.php heißen soll:

DirectoryIndex index-xy.php

Mehrere mögliche Startseiten definieren – Variante 2

DirectoryIndex index.html index.htm index.php home.html

Startseite je nach Domain (CNAME)

Bei mehreren Domains mit gleichem Verzeichnis kann man unterschiedliche Startseiten zuweisen:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?domain1\.de$
RewriteRule ^$ index1.html [L]                  
RewriteCond %{HTTP_HOST} ^(www\.)?domain2\.de$
RewriteRule ^$ index2.html [L]

Download für bestimmte Dateitypen erzwingen

Standardmäßig entscheidet der Browser, ob eine Datei direkt angezeigt oder zum Download angeboten wird. PDF-Dateien etwa werden oft direkt im Browser geöffnet, ebenso DOC-Dateien, ZIP-Dateien hingegen meist heruntergeladen. Mit Hilfe der .htaccess kann man dieses Verhalten gezielt steuern und den Download bestimmter Dateitypen erzwingen – unabhängig von den jeweiligen Browser-Einstellungen.

Das folgende Beispiel sorgt dafür, dass Dateien mit den Endungen .doc, .pdf, .zip und .rar beim Anklicken im Browser nicht mehr geöffnet, sondern sofort zum Herunterladen angeboten werden:

<FilesMatch "\.(doc|pdf|zip|rar)$">
ForceType application/octet-stream
Header set Content-Disposition attachment
</FilesMatch>

Erklärung der Direktiven

<FilesMatch>

Dieser Block gilt für alle Dateien, deren Endung auf die im regulären Ausdruck angegebenen Formate passt – also z. B. beispiel.pdf oder bericht.doc. Der Ausdruck \.(doc|pdf|zip|rar)$ bedeutet: Dateien, die auf eine dieser Endungen mit einem Punkt davor enden.

ForceType application/octet-stream

Diese Direktive setzt den MIME-Typ der Datei auf application/octet-stream, was ein generischer Typ für Binärdaten ist. Der Browser erkennt dadurch, dass es sich nicht um eine darstellbare Datei handelt – und leitet daraus ab, dass sie heruntergeladen werden soll.

Header set Content-Disposition attachment

Dieser HTTP-Header weist den Browser zusätzlich an, die Datei als Anhang zu behandeln. Zusammen mit dem geänderten MIME-Typ wird dadurch das Herunterladen nahezu aller modernen Browser zuverlässig ausgelöst.

Diese Methode eignet sich insbesondere für Download-Bereiche, in denen sichergestellt werden soll, daß eine Datei gespeichert werden kann, statt sie eventuell nur im Browser zu öffnen.

HSTS - HTTP Strict Transport Security

Zweck: Der HSTS-Header (Strict-Transport-Security) weist Browser an, die Domain künftig ausschließlich über HTTPS aufzurufen. Das schützt vor SSL-Stripping i SSL-Stripping ist ein Angriff, bei dem eine eigentlich sichere HTTPS-Verbindung auf unsicheres HTTP herabgestuft wird, damit Angreifer Daten mitlesen oder manipulieren können. HSTS schützt davor, indem der Browser ausschließlich HTTPS akzeptiert. und reduziert Man-in-the-Middle i Man-in-the-Middle (MitM) ist ein Angriff, bei dem sich ein Dritter heimlich zwischen zwei Kommunikationspartner schaltet, um deren Daten mitzulesen oder zu manipulieren. Verschlüsselung und Sicherheitsmechanismen wie HSTS reduzieren dieses Risiko deutlich. -Risiken.

Nutzen

• Erzwingt nach dem ersten HTTPS-Besuch verschlüsselte Verbindungen.
• Verhindert Downgrade-Angriffe (HTTPS → HTTP).
• Optionaler Schutz für alle Subdomains via includeSubDomains.

⚠️ Risiken & Stolperfallen

• Persistenz: Browser merken sich HSTS bis zum Ablauf von max-age. Ein einmal zu hoch gesetzter Wert läßt sich nicht sofort zurücknehmen. (siehe: Rollback / Notbremse bei HSTS)
• Erreichbarkeit: Wenn eine Subdomain kein HTTPS kann, aber includeSubDomains aktiv ist, wird sie für Nutzer effektiv unzugänglich.
• Preload: Der Parameter preload gehört nur gesetzt, wenn die Domain in die HSTS-Preload-Liste eingetragen werden soll. Ein falscher Eintrag kann nur sehr schwer wieder rückgängig gemacht werden.
• Nur über HTTPS senden: HSTS sollte nur bei HTTPS-Antworten gesetzt werden. Ein Versuch, den Header über HTTP zu senden, wird von modernen Browsern ignoriert, kann aber bei alten oder ungewöhnlichen Clients zu unerwartetem Verhalten führen.
• Zuerst kurz testen: Mit einem kleinen max-age (z. B. 300s) beginnen, ohne includeSubDomains, alles prüfen, danach erst erhöhen.

💡 Rollback / Notbremse bei HSTS

• Kein echter Fallback: Ein einmal gesetzter hoher max-age-Wert bleibt bis zum Ablauf im Browser gespeichert. Das ist Absicht und ein Sicherheitsmechanismus.
• Grund: HSTS-Einträge werden nur im Browser gespeichert. HTTP-Aufrufe werden ignoriert, solange HSTS aktiv ist.
• Einzige technische Möglichkeit: Bei einem erneuten HTTPS-Aufruf den Header Strict-Transport-Security: max-age=0 senden, um den Eintrag zu löschen:

  <IfModule mod_headers.c>
      <If "%{HTTPS} == 'on'">
          Header always set Strict-Transport-Security "max-age=0"
      </If>
  </IfModule>
  

  <IfModule mod_headers.c>
    <IfModule mod_rewrite.c>
      RewriteEngine On
      RewriteCond %{HTTPS} on
      RewriteRule .* - [E=SET_HSTS_ROLLBACK:1]
    </IfModule>
    Header always set Strict-Transport-Security "max-age=0" env=SET_HSTS_ROLLBACK
  </IfModule>
  

• Grenzen: Funktioniert nur, wenn Besucher die Domain nochmals per HTTPS aufrufen. Nutzer, die per HTTP kommen, erreichen sie evtl. nicht mehr.
• Letzter Ausweg: Manuelles Entfernen des HSTS-Eintrags im Browser (Entwicklertools oder Browserdaten löschen).
• Best Practice: Erst mit kleinem Wert (z. B. 300 Sekunden) testen, dann schrittweise erhöhen. includeSubDomains nur aktivieren, wenn alle Subdomains HTTPS können.

Parameter-Übersicht

max-age=<Sekunden>

Dauer der HSTS-Gültigkeit (z. B. 31536000 für 1 Jahr).

Zeitraum	Sekunden
5 Min	300
1 Tag	86400
1 Woche	604800
1 Monat (30 Tage)	2592000
Halbes Jahr (182,5 Tage)	15768000
1 Jahr (365 Tage)	31536000

includeSubDomains

Erweitert die Vorgabe auf alle Subdomains

⚠️ Nur setzen, wenn alle Subdomains HTTPS-fähig sind).

preload

HTTPS-only ab dem ersten Seitenaufruf.

⚠️ Nur verwenden, wenn die Domain in die Preload-Liste aufgenommen werden soll. Vorher unbedingt die Kriterien prüfen.

⚠️ Die Nutzung von preload ist ein aktiver Schritt:
preload nur setzen, wenn die Domain in die offizielle HSTS Preload-Liste eingetragen werden soll und sie alle Kriterien auf hstspreload.org erfüllt.

• Es müssen alle Subdomains HTTPS-fähig, Header korrekt gesetzt sein.
• Die Domain muß über das Formular auf hstspreload.org eingereicht werden.
• Nach Eintragung wird die Domain automatisch in Browsern als HTTPS-only behandelt – schon beim ersten Besuch.
• Einmal eingetragen, ist die Entfernung sehr aufwendig – sorgfältige Prüfung vor der Aktivierung ist daher dringend empfohlen.

Apache .htaccess – Produktivbeispiel

Setzt HSTS nur bei aktiver HTTPS-Verbindung. Empfohlen, wenn alle Subdomains HTTPS unterstützen:

<IfModule mod_headers.c>
  <If "%{HTTPS} == 'on'">
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  </If>
</IfModule>

<IfModule mod_headers.c>
  <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} on
    RewriteRule .* - [E=SET_HSTS:1]
  </IfModule>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

Alternative ohne Subdomains (konservativer Start)

<IfModule mod_headers.c>
    <If "%{HTTPS} == 'on'">
        Header always set Strict-Transport-Security "max-age=31536000"
    </If>
</IfModule>

<IfModule mod_headers.c>
  <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} on
    RewriteRule .* - [E=SET_HSTS:1]
  </IfModule>
  Header always set Strict-Transport-Security "max-age=31536000"
</IfModule>

Testmodus (empfohlen vor Produktivsetzung)

Kurze Gültigkeit und ohne Subdomains. Wenn alles stabil ist, max-age schrittweise erhöhen und optional includeSubDomains ergänzen.

<IfModule mod_headers.c>
    <If "%{HTTPS} == 'on'">
        Header always set Strict-Transport-Security "max-age=300"
    </If>
</IfModule>

<IfModule mod_headers.c>
  <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} on
    RewriteRule .* - [E=SET_HSTS:1]
  </IfModule>
  Header always set Strict-Transport-Security "max-age=300"
</IfModule>

<IfModule mod_rewrite.c>
  RewriteEngine On
  # Umleitung auf HTTPS erzwingen
  RewriteCond %{HTTPS} !=on
  RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

<IfModule mod_headers.c>
  # HSTS setzen – 1 Jahr, Subdomains optional, Preload optional
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

<IfModule mod_headers.c>
  # HSTS setzen – 1 Jahr, Subdomains optional, Preload optional
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>

PHP-Fallback

Wenn kein Zugriff auf die htaccess möglich ist, gibt es auch eine Lösung für per PHP ausgelieferte Seiten. Allerdings greift der HSTS-Header dann nur bei dynamischen Verbindungen, nicht bei Statischen, wie Bilder, CSS oder JS.

<?php
// Nur auf HTTPS-Antworten senden
if (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off') {
    // Konservativ starten (ohne includeSubDomains), später anheben
    header('Strict-Transport-Security: max-age=31536000');
}
?>

Checkliste vor Aktivierung

• Alle relevanten Hosts/Subdomains erreichbar & mit gültigem Zertifikat?
• HTTP->HTTPS-Weiterleitungen korrekt & ohne Redirect-Schleifen?
• Erst mit kurzer max-age testen, dann erhöhen.
• includeSubDomains nur, wenn wirklich alle Subdomains HTTPS können.
• preload nur nach sorgfältiger Prüfung der Kriterien.

Cross-Origin-Opener-Policy (COOP)

Zweck: Der COOP-Header isoliert den Top-Level-Window-Kontext von der Domain und verhindert, dass fremde Dokumente denselben „Window-Objekt-Bereich“ ( Browsing Context Group i Eine Browsing Context Group ist eine Gruppe von Fenstern oder Tabs, die denselben JavaScript-Kontext teilen und miteinander interagieren können. COOP isoliert diese Gruppen. ) teilen. So werden Datenlecks über Pop-ups oder Cross-Origin-Skripte stark reduziert.

Nutzen

• Schutz gegen Man-in-the-Middle i Man-in-the-Middle (MitM) ist ein Angriff, bei dem sich ein Dritter heimlich zwischen zwei Kommunikationspartner schaltet, um deren Daten mitzulesen oder zu manipulieren. Verschlüsselung und Sicherheitsmechanismen wie HSTS reduzieren dieses Risiko deutlich. -artige Datenlecks über andere Fenster oder Tabs.
• Ermöglicht die sichere Nutzung von SharedArrayBuffer i SharedArrayBuffer ist ein JavaScript-Objekt, das es erlaubt, großen Speicher zwischen Threads oder Web Workern zu teilen, um Hochleistungsberechnungen effizient durchzuführen. und bestimmten Web Worker i Web Worker sind JavaScript-Hintergrund-Threads, die Berechnungen ausführen, ohne die Hauptseite zu blockieren. Sie können Daten mit SharedArrayBuffer effizient verarbeiten. Funktionen in modernen Browsern.
• Verhindert, dass externe Pop-ups den Window-Kontext manipulieren oder Zugriff auf sensible Daten erhalten.

COOP-Varianten

same-origin

Strikte Isolation: Nur Fenster derselben Origin i Die Origin besteht aus Schema (http/https), Domain und Port. Sie definiert die Sicherheitsgrenze für Web-Ressourcen und erlaubt oder blockiert Cross-Origin-Zugriffe. dürfen den Kontext teilen. Fremde Pop-ups werden vollständig getrennt.

same-origin-allow-popups

Lockert die Isolation leicht: Pop-ups derselben Origin dürfen noch geöffnet werden, andere Fenster bleiben isoliert.

Kombination mit Cross-Origin-Embedder-Policy (COEP)

COEP wird häufig zusammen mit COOP eingesetzt:
COEP steuert, welche Ressourcen von fremden Origins eingebunden werden dürfen. Es sorgt dafür, daß nur explizit zugelassene Inhalte geladen werden, und erhöht so die Sicherheit beim Umgang mit Cross-Origin-Daten, insbesondere in Kombination mit SharedArrayBuffer und Web Workern.

• Header: Cross-Origin-Embedder-Policy: require-corp
• Erlaubt sichere Nutzung von SharedArrayBuffer, Web Workers und Cross-Origin-Resourcen i Cross-Origin-Resourcen sind Inhalte (z. B. Skripte, Bilder, Fonts), die von einer anderen Origin als der Hauptseite geladen werden. Richtlinien wie COOP/COEP steuern den Zugriff darauf. unter strikter Isolation.
• Empfohlen, wenn du maximale Isolation und moderne Features nutzen willst.

Risiken / Stolperfallen

• Strikte Isolation (`same-origin`) kann Pop-ups blockieren, die eventuell funktional gebraucht werden.
• Externe Skripte oder Drittanbieter-Widgets könnten nicht mehr funktionieren.
• Ältere Browser unterstützen COOP teilweise nur eingeschränkt.

.htaccess-Beispiel

<IfModule mod_headers.c>
    # COOP setzen – strikte Isolation
    Header set Cross-Origin-Opener-Policy "same-origin"

    # Optional: COEP setzen für volle Isolation
    Header set Cross-Origin-Embedder-Policy "require-corp"
</IfModule>

Praxis-Tipps

• Test zuerst in einer Subdomain oder Staging-Umgebung, um Inkompatibilitäten zu erkennen.
• Wenn Pop-ups genutzt werden, vorab prüfen ob `same-origin-allow-popups` für die Anwendungsfälle paßt.
• COOP + COEP zusammen ermöglichen maximale Sicherheit bei modernen Browsern, besonders relevant für SharedArrayBuffer, Web Workers und Cross-Origin-Schutz.
• Immer Browserkompatibilität prüfen, bevor die Header produktiv einsetzt werden.

Zusammenfassung

COOP ist ein wichtiger Header, um den Window-Kontext zu isolieren, Datenlecks über Pop-ups zu vermeiden und die Nutzung moderner Browser-Features zu sichern. In Kombination mit COEP bietet er maximale Schutzwirkung gegen Cross-Origin-Angriffe und verbessert die Sicherheit deiner Seiten erheblich.

• same-origin – Strikte Isolation: Nur Fenster derselben Origin dürfen den Kontext teilen. Fremde Pop-ups werden vollständig getrennt. Maximale Sicherheit, kann aber eigene Pop-ups blockieren.
• same-origin-allow-popups – Flexibler: Pop-ups derselben Origin dürfen geöffnet werden, andere Fenster bleiben isoliert. Funktionaler bei Pop-up-lastigen Anwendungen, aber geringfügig weniger strikt.

Verzeichniszugriff blockieren

Verhindert, daß ein Besucher die Dateiliste eines Verzeichnisses sehen kann (Directory Listing).

Options -Indexes

Versteckte Dateien schützen

Blockiert allgemein alle versteckten Dateien (beginnen mit Punkt), außer es gibt Ausnahmen.

RedirectMatch 404 /\..*

Zugriff auf bestimmte Dateitypen verhindern

Praktisch, um z. B. Uploads von PHP-Dateien in Medien-Ordnern zu blockieren.

<FilesMatch "\.(php|pl|py|jsp|asp|sh)$">
Order deny,allow    
Deny from all
</FilesMatch>

Sicherheit mit der .htaccess- firewall

Die .htaccess-Datei ist nicht nur ein Werkzeug zur Steuerung von Weiterleitungen oder URL-Strukturen – sie kann auch als effektive erste Verteidigungslinie gegen Angriffe auf eine Website dienen.
Da sie direkt auf Webserver-Ebene wirkt (Apache), werden viele Anfragen bereits blockiert, bevor überhaupt WordPress, Joomla oder eine andere Anwendung ins Spiel kommt.

Beispiel: 7G Firewall

Ein bekanntes Beispiel für eine auf .htaccess-Regeln basierende Sicherheitslösung ist die 7G Firewall von Perishable Press.
Dabei handelt es sich um eine kompakte Sammlung von Regeln, die schädliche Anfragen (z. B. mit verdächtigen User-Agents, ungültigen Zeichen in der URL oder typischen Mustern für SQL-Injections) erkennen und blockieren.

# Beispiel aus der 7G Firewall                                                                                           
<IfModule mod_rewrite.c>                     
  RewriteEngine On          
                    
  # Blockiere Anfragen mit typischen Exploit-Mustern
  RewriteCond %{QUERY_STRING} (\.\./|\.\.\\) [NC,OR]
  RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]
  RewriteCond %{QUERY_STRING} (eval\() [NC,OR]                              
  RewriteCond %{QUERY_STRING} concat\([^\)]{1,}\) [NC]
  RewriteRule .* - [F]
</IfModule>

Diese Regeln blockieren Angriffe automatisiert, bevor sie ihre Wirkung entfalten können. Die 7G Firewall ist quelloffen, performant und lässt sich ohne Plugin einfach in die bestehende .htaccess einfügen.

Weitere Schutzmaßnahmen

• Sperren des Zugriffs auf sensible Dateien wie wp-config.php oder .env
• Einschränkung des Zugriffs auf die wp-admin oder administrator-Bereiche
• Blockierung bestimmter IP-Adressen oder Länderbereiche
• Deaktivierung von trace und track, um XST-Angriffe zu unterbinden

Eine durchdachte .htaccess kann somit als minimalistisches, aber wirksames Sicherheits-Framework dienen – besonders für kleinere Websites ohne dedizierte Sicherheitslösungen.

Viele Betriebssysteme und Webtools legen versteckte Dateien an, die nicht über das Internet erreichbar sein sollten. Wird ihr Zugriff nicht blockiert, kann das zu Sicherheitslücken führen – etwa durch versehentlich öffentlich gewordene Konfigurations-, Paßwort- oder Indexdateien.

📂 Beispiel: .DS_Store auf macOS

macOS erzeugt in jedem Verzeichnis eine Datei .DS_Store, die Informationen zur Darstellung im Finder enthält (z. B. Symbolpositionen). Gelangt sie in ein öffentliches Webverzeichnis, kann sie:

• versteckte Inhalte verraten (Datei- und Ordnernamen)
• als inoffizielles Verzeichnislisting dienen
• Angreifern helfen, die interne Struktur der Seite zu erkunden

Um das zu verhindern, lässt sich der Zugriff in der .htaccess blockieren:

<Files ".DS_Store">
  Require all denied
</Files>

Oder alternativ für ältere Apache-Versionen:

<FilesMatch "^\.DS_Store$">
  Order allow,deny  Deny from all
</FilesMatch>

🛡️ Allgemeiner Schutz für versteckte Dateien

Viele Systeme und Programme legen versteckte Dateien im Webverzeichnis an, die nicht für den Zugriff über das Internet bestimmt sind. Dazu gehören z. B.:

• .htaccess, .htpasswd – Konfigurationsdateien
• .git, .svn, .env – Versionskontrolle oder Umgebungsvariablen
• .DS_Store – eine macOS-spezifische Datei, die ein reales Sicherheitsrisiko darstellen kann

Beispiel: .DS_Store als Sicherheitsrisiko

Auf macOS wird beim Öffnen eines Ordners im Finder automatisch eine Datei .DS_Store angelegt. Diese enthält Informationen zur Ordneransicht – z. B. Symbolpositionen. Gelangt sie versehentlich in ein öffentliches Webverzeichnis (z. B. beim Hochladen via FTP oder Deployment), kann sie:

• Rückschlüsse auf versteckte Dateien und Ordner zulassen
• als inoffizielles Verzeichnislisting fungieren – auch wenn Options i Legt Serveroptionen für Verzeichnisse fest, z.B. Indexes oder FollowSymLinks. -Indexes gesetzt ist
• ein potenzieller Einstiegspunkt für Angreifer sein

Sollen mehrere sensible Dateien gleichzeitig abgesichert werden (z. B. .git, .env, .htpasswd), kann ein gemeinsames Muster verwendet werden:

<FilesMatch "^(\.git|\.svn|\.env|\.DS_Store|\.ht.*)$">
  Require all denied
</FilesMatch>

Damit werden folgende Dateien zuverlässig geschützt:

• .git, .svn: Versionskontrolle
• .env: Umgebungsvariablen, z. B. Datenbankzugang
• .DS_Store: macOS-spezifische Datei, potentielles Sicherheitsrisiko
• .htaccess, .htpasswd: Konfiguration & Paßwortschutz

💡 Zusätzlicher Hinweis

Neben dem Sperren über .htaccess sollte der Upload solcher Dateien am besten komplett verhindert werden:

Mit der .htaccess-Datei lassen sich Weiterleitungen und Umschreibungen direkt auf Serverebene steuern – noch bevor PHP oder andere Skripte ausgeführt werden. Das ist besonders nützlich, um veraltete URL's umzuleiten, HTTPS zu erzwingen, www zu entfernen oder sprechende URL's i Sogenannte sprechende URLs – auch „Pretty URLs“ genannt – sind Webadressen, die lesbar und verständlich sind, sowohl für Menschen als auch für Suchmaschinen. Anstelle technischer Pfade wie /seite.php?id=42 verwendet man dann z. B. /ueber-uns oder /kontakt. Das wirkt benutzerfreundlich, steigert die Vertrauenswürdigkeit und kann sich positiv auf die Suchmaschinenoptimierung auswirken. zu ermöglichen. Dadurch wird nicht nur die Benutzerführung verbessert, sondern auch Duplicate Content i Doppelte Inhalte, die bei Suchmaschinen zu schlechterem Ranking führen können. vermieden und bestenfalls das Ranking in Suchmaschinen positiv beeinflußt.

Die Konfiguration erfolgt mit dem Apache-Modul mod_rewrite i Apache-Modul, das URL-Umschreibungen ermöglicht. , das über sogenannte RewriteRule- und RewriteCond-Anweisungen arbeitet. Diese ermöglichen eine präzise Steuerung des Anfrageverlaufs – z. B. durch Bedingungen, reguläre Ausdrücke und Statuscodes wie 301 (permanente Weiterleitung).

HTTP zu HTTPS

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Erklärung der Direktiven

• RewriteEngine On – aktiviert das mod_rewrite i Apache-Modul, das URL-Umschreibungen ermöglicht. - Modul von Apache. Ohne diese Direktive funktioniert keine der folgenden Regeln.
• RewriteCond %{HTTPS} off – diese Bedingung prüft, ob der aktuelle Aufruf nicht verschlüsselt ist (also über http:// erfolgt). Nur wenn das zutrifft, wird die folgende Regel angewendet.
• RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] – leitet den Aufruf auf die HTTPS-Version der Seite um. Dabei bleibt die Domain (%{HTTP_HOST}) und der Pfad inklusive Parameter (%{REQUEST_URI}) erhalten. Die Flags:
  • L – „Last Rule“: Nach dieser Regel wird keine weitere geprüft.
  • R=301 – sendet eine 301-Weiterleitung (permanent), die auch von Suchmaschinen gespeichert wird.

Warum ist das wichtig?

Die Umstellung auf HTTPS ist heutzutage Standard – nicht nur wegen der Datensicherheit (z. B. bei Formularen), sondern auch wegen der SEO-Bewertung i Die SEO-Bewertung umfaßt verschiedene technische, inhaltliche und strukturelle Faktoren, mit denen Suchmaschinen die Qualität und Relevanz einer Website einschätzen. Dazu gehören u.a. Ladezeit, Mobilfreundlichkeit, sichere Verbindung (HTTPS), interne Verlinkung, sprechende URLs und Inhaltsstruktur. . Google bevorzugt HTTPS-Seiten im Ranking, und viele Browser warnen aktiv vor unverschlüsselten Seiten.

Diese Regel stellt sicher, dass wirklich alle Zugriffe automatisch auf HTTPS umgeleitet werden – ohne dass du in deinem HTML-Code oder CMS Links manuell anpassen musst.

WWW entfernen

Diese Regel sorgt dafür, dass Anfragen an die Domain mit www. automatisch auf die Version ohne www umgeleitet werden – also von www.agentur-pflueger.de zu agentur-pflueger.de. Das dient hauptsächlich der einheitlichen Erreichbarkeit deiner Website unter einer einzigen Adresse.

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]

Erklärung der Direktiven

• RewriteEngine On – aktiviert das Rewrite-Modul i Aktiviert die Verarbeitung von Umschreiberegeln in Apache (siehe mod_rewrite). .
• RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC] – diese Bedingung prüft, ob der Hostname mit www. beginnt. Das (.*) fängt den Rest der Domain (z. B. agentur-pflueger.de) ab und speichert ihn in %1. [NC] steht für „No Case“, also Groß-/Kleinschreibung ignorieren.
• RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301] – wenn die Bedingung zutrifft, wird der Besucher per 301-Weiterleitung i Eine permanente Weiterleitung, die auch von Suchmaschinen übernommen wird. auf die Domain ohne www. umgeleitet – inklusive Pfad und Parameter.

Warum sollte man das machen?

Diese Regel verhindert Duplicate Content i Doppelte Inhalte, die bei Suchmaschinen zu schlechterem Ranking führen können. und sorgt für klare Strukturen. Damit Suchmaschinen die Seite nicht doppelt aufrufen und indexieren können – einmal mit www und einmal ohne.

Wenn es lieber mit www. sein soll, kann die Umleitung umkehrt werden, sodaß alle Anfragen ohne www zu www. weitergeleitet werden.

RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Entscheidend ist, sich für eine Variante zu entscheiden und diese konsequent einzusetzen.

🌐 Umleitung mehrerer Domains (mit und ohne www.) auf eine einheitliche Hauptdomain

Früher war es bei manchen Hostinganbietern üblich, mehrere Domain-Endungen (z. B. .de, .com, .org, .net, .eu) im Paket zu registrieren. Technisch verwiesen diese Domains oft alle auf das gleiche Webverzeichnis – was zu doppeltem Inhalt führen konnte. Damit jedoch keine Duplicate-Content-Probleme entstehen und Suchmaschinen die Webseite korrekt indexieren, sollten sämtliche Aufrufe (mit oder ohne www.) auf eine Hauptdomain umgeleitet werden.

Das folgende Beispiel leitet alle Varianten auf https://beispiel.de weiter:

RewriteEngine On
RewriteCond %{HTTP_HOST} !^beispiel\.de$ [NC]
RewriteRule ^ https://beispiel.de%{REQUEST_URI} [L,R=301]

Erklärung der Direktiven

• RewriteEngine On – aktiviert das Umschreibemodul (mod_rewrite).
• RewriteCond %{HTTP_HOST} !^beispiel\.de$ [NC] – diese Bedingung greift, wenn die Domain nicht exakt beispiel.de ist. Also z. B. www.beispiel.de, beispiel.com, www.beispiel.net usw.
• RewriteRule ^ https://beispiel.de%{REQUEST_URI} [L,R=301] – leitet alles auf die Hauptdomain weiter – inklusive Pfad und Parameter.

Was bringt das?

Diese Umleitung hilft bei der Vermeidung von Duplicate Content i Doppelte Inhalte, die bei Suchmaschinen zu schlechterem Ranking führen können. , verbessert das SEO-Ranking und sorgt für eine klare Markenidentität – unabhängig davon, mit welcher Domain oder Schreibweise ein Besucher kommt.

Tipp:

Wenn stattdessen lieber www.beispiel.de als Hauptdomain genutzt werden soll, muß die Regel entsprechend angepaßt werden:

RewriteCond %{HTTP_HOST} !^www\.beispiel\.de$ [NC]
RewriteRule ^ https://www.beispiel.de%{REQUEST_URI} [L,R=301]

Dateiendung entfernen

Macht aus seite.php einfach /seite, wenn Rewrite entsprechend funktioniert.

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([a-zA-Z0-9_-]+)$ $1.php [L]

Fehlermeldungen unterdrücken

php_flag display_errors Off

Dateigröße für Uploads erhöhen

php_value upload_max_filesize 20M
php_value post_max_size 25M

Standard-Zeitzone setzen

php_value date.timezone "Europe/Berlin"

GZIP-Komprimierung

Die GZIP-Komprimierung ist eine effektive Methode, um die Größe von Textdateien wie HTML, CSS, JavaScript oder XML zu reduzieren. Das bedeutet, daß die Daten komprimiert vom Server an den Browser gesendet werden, was die Ladezeiten der Webseite deutlich verbessert und gleichzeitig Bandbreite spart.

Besonders bei langsamen Verbindungen oder großen Webseiten mit vielen Ressourcen spürt man den Unterschied deutlich. Der Browser entpackt die Dateien beim Empfang automatisch und stellt sie normal dar.

In der .htaccess wird dafür meist das Apache-Modul mod_deflate verwendet, das auf dem Server installiert und aktiviert sein muss. Der Codeblock <IfModule mod_deflate.c> ... </IfModule> prüft, ob das Modul vorhanden ist, bevor die Komprimierung aktiviert wird. So wird vermieden, dass die .htaccess einen Fehler auslöst, wenn das Modul fehlt.

Die Direktive AddOutputFilterByType DEFLATE weist Apache an, die Ausgabe von bestimmten Dateitypen zu komprimieren. In dem Beispiel sind das unter anderem text/html (HTML-Seiten), text/css (Stylesheets) und application/javascript (JavaScript-Dateien).

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain text/html text/xml text/css application/javascript
</IfModule>

Entscheident ist, daß nur Dateitypen komprimiert werden, die vom Browser entpackt werden können. Binärdateien wie Bilder oder Videos sollten nicht per GZIP komprimiert werden, da dies keinen Vorteil bringt und die Serverlast unnötig erhöht.

GZIP hilft, die Übertragungsmenge zu verringern und die Website performanter zu machen – ein einfacher und wirkungsvoller Schritt in der Weboptimierung.

Caching aktivieren

Durch Caching i Zwischenspeicherung von Dateien im Browser, um diese bei späteren Seitenaufrufen schneller zu laden merkt sich der Browser bestimmte Dateien deiner Webseite, wie Bilder oder Stylesheets. Das bedeutet, dass nicht bei jedem Besuch alle Dateien neu vom Server geladen werden müssen, sondern stattdessen lokal gespeichert und wiederverwendet werden können.

Die in der .htaccess aktivierte Regel nutzt das Apache-Modul mod_expires. Dieses Modul gibt dem Browser Anweisungen, wie lange bestimmte Dateitypen zwischengespeichert werden sollen.

Der Block <IfModule mod_expires.c> ... </IfModule> stellt sicher, dass die Regeln nur angewendet werden, wenn das Modul auf dem Server aktiv ist, damit keine Fehler auftreten, falls es fehlt.

Mit ExpiresActive On wird die Ablaufsteuerung aktiviert. Die folgenden Zeilen definieren die Speicherzeit für verschiedene Dateitypen:

• ExpiresByType image/jpg "access plus 1 month" sagt dem Browser, dass JPG-Bilder für einen Monat ab dem Zeitpunkt des Zugriffs zwischengespeichert werden sollen.
• ExpiresByType text/css "access plus 1 week" bewirkt, dass CSS-Dateien eine Woche lang im Cache bleiben.

Diese zeitlichen Angaben helfen dabei, die Ladezeiten für wiederkehrende Besucher deutlich zu verbessern, da weniger Daten neu geladen werden müssen.

Wichtig ist, daß die Cache-Dauer je nach Dateityp und Aktualisierungsfrequenz angepaßt wird. Sehr statische Dateien wie Bilder können länger zwischengespeichert werden, während häufig geänderte Dateien kürzere Zeiten erhalten sollten, um Aktualität sicherzustellen.

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/jpg "access plus 1 month"
  ExpiresByType text/css "access plus 1 week"
</IfModule>

Durch Caching wird nicht nur die Website schneller geladen, sondern auch der Server entlastet.

Verzeichnisschutz mit .htpasswd

AuthType Basic
AuthName "Geschützt"
AuthUserFile /pfad/zur/.htpasswd
Require valid-user

Bei mit .htpasswd geschützten Bereichen bringt Apache bereits eine grundlegende Protokollierung von fehlgeschlagenen Login‑Versuchen mit.
Eine zusätzliche Konfiguration in der .htaccess ist dafür nicht erforderlich.

Jeder fehlgeschlagene Authentifizierungsversuch (z. B. falscher Benutzername oder falsches Paßwort) wird automatisch im Error‑Log des Apache protokolliert.
user admin: authentication failure for "/admin/": Password Mismatch
Diese Einträge entstehen unabhängig davon, ob der Zugriff per Browser, Skript oder Bot erfolgt.

Loginversuche überwachen und Angreifer blockieren

Da Apache Authentifizierungsfehler selbstständig im Error‑Log erfasst, können diese Logeinträge direkt von externen Werkzeugen wie Fail2Ban ausgewertet werden.

Fail2Ban:

• analysiert das Error‑Log
• erkennt wiederholte Authentifizierungsfehler
• blockiert die Quell‑IP temporär oder dauerhaft (z. B. via iptables, nftables oder firewalld)

Ein separates Logfile ist hierfür nicht erforderlich. Die automatische Protokollierung im Error‑Log erfüllt denselben Zweck.

Alternativ: Wiederholungstäter direkt blockieren

# Wiederholungstäter manuell blockieren
<RequireAll>
Require all granted
Require not ip 192.0.2.42
</RequireAll>

Hinweis: Diese Methode ist nicht besonders elegant oder skalierbar, aber für kleinere Websites oder temporäre Schutzmaßnahmen oft ausreichend.

Warum Burte-Force-Abwehr wichtig ist

Standardmäßig zeigt der Apache-Webserver bei Fehlern wie „Seite nicht gefunden“ (404) oder „Inhalt dauerhaft entfernt“ (410) eine schlichte, technische Fehlerseite an. Diese ist weder ansprechend gestaltet noch besonders informativ. Mit der ErrorDocument-Direktive in der .htaccess kann eine benutzerdefinierte Fehlerseite festlegt werden – im passenden Design der Website und mit weiterführenden Hinweisen für die Besuchenden.

Das verbessert die User Experience (kurz UX), vermeidet Verwirrung und unterstützt das Branding. Statt einer generischen Fehlermeldung kann Hilfestellung gegeben, zur Startseite verlinkt oder ein Suchfeld angeboten werden.

ErrorDocument 404 /fehler/404.html
ErrorDocument 410 /fehler/410.html 

Was bedeutet das konkret?

• ErrorDocument 404: Wenn eine angeforderte Seite nicht existiert, wird stattdessen /fehler/404.html geladen. Beispiel: 404
• ErrorDocument 410: Wenn Seiten bewußt entfernt wurden und dies mitgeteilt werden soll, wird /fehler/410.html angezeigt. Beispiel: 410

Warum 410 statt 404?

Ein 404-Fehler bedeutet: „Die Seite wurde nicht gefunden – vielleicht war sie nie da, vielleicht ist sie nur temporär nicht erreichbar.“. Ein 410-Fehler dagegen signalisiert: „Diese Seite wurde dauerhaft entfernt.“. Das ist vor allem für Suchmaschinen (z. B. Google) relevant, denn ein 410 führt in der Regel schneller dazu, daß die Seite aus dem Index entfernt wird.

Ergänzende Hinweise

• Pfadangaben wie /fehler/404.html sind relativ zum Document Root i Das Hauptverzeichnis einer Website auf dem Server. Alle Pfade in der .htaccess (z. B. zu Fehlerseiten) beziehen sich relativ auf dieses Verzeichnis. .
• Die Zielseite muss existieren und für den Webserver zugänglich sein, sonst wird wieder eine Fehlerseite generiert.
• Es kann jede beliebige Datei angeben werden – auch .php oder .cgi.

Wenn mehr Kontrolle gewünscht ist (z. B. Logging oder dynamische Fehlerseiten), empfiehlt sich eine PHP-Datei mit zusätzlichen Funktionen.

MIME-Typen setzen

Manchmal behandelt der Server bestimmte Dateitypen nicht korrekt. Mit AddType kannst du den MIME-Typ explizit setzen, damit Browser und Clients die Dateien richtig interpretieren.

<IfModule mod_mime.c>
AddType application/font-woff2 .woff2
AddType image/svg+xml .svg
AddType application/javascript .js
</IfModule>

Zum Beispiel: Die WOFF2-Schriftdateien benötigen den MIME-Typ application/font-woff2, sonst könnten sie nicht korrekt geladen werden.

Cross-Origin Resource Sharing (CORS) steuern

CORS (Cross-Origin Resource Sharing) ist ein Sicherheitsmechanismus, den Browser implementieren, um zu kontrollieren, welche Websites auf Ressourcen (z. B. Schriftarten, APIs, Bilder) auf dem Server zugreifen dürfen. Ohne CORS-Regeln können Webseiten aus anderen Domains normalerweise nicht einfach auf die eigenen Ressourcen zugreifen — das schützt vor ungewolltem Datenklau oder Mißbrauch.

Warum braucht man CORS?

Manchmal ist es aber gewollt, dass Ressourcen von anderen Domains genutzt werden können, z. B.:

• Eine API, die von verschiedenen Webseiten verwendet wird.
• Ein Webfont oder JavaScript-Dateien, die auf mehreren Domains eingebunden sind.
• Eine Single-Page-Application (SPA) lädt Daten von einem anderen Server.

Ohne CORS konfiguriert zu haben, blockieren Browser solche Zugriffe aus Sicherheitsgründen.

Wie konfiguriert man CORS mit .htaccess?

In der .htaccess können mit dem Apache-Modul mod_headers HTTP-Header gesetzt werden, die CORS erlauben oder einschränken. Hier ein paar Beispiele:

<IfModule mod_headers.c>
  # Erlaubt allen Domains den Zugriff auf alle Ressourcen
  Header set Access-Control-Allow-Origin "*"
</IfModule>

* bedeutet: Jeder darf auf die Ressourcen zugreifen (offene Freigabe). Das ist praktisch für öffentliche APIs oder Fonts, aber oft nicht sicher, weil jeder Zugriff hat.

Sichere Variante: nur bestimmte Domains erlauben.

<IfModule mod_headers.c>
  SetEnvIf Origin "https://(www\.)?meine-domain\.de$" AccessControlAllowOrigin=$0
  Header set Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin
  Header set Access-Control-Allow-Methods "GET, POST, OPTIONS"
  Header set Access-Control-Allow-Headers "Origin, X-Requested-With, Content-Type, Accept"
</IfModule>

• Hier werden nur Anfragen von meine-domain.de erlaubt.
• Andere Domains bekommen keinen Zugriff.
• Access-Control-Allow-Methods definiert erlaubte HTTP-Methoden (z.B. GET, POST).
• Access-Control-Allow-Headers gibt an, welche Header die Anfrage enthalten darf.

Beispiel für eine API, die nur von einer Subdomain zugänglich sein soll.

<IfModule mod_headers.c>
  SetEnvIf Origin "https://api\.meine-domain\.de$" AccessControlAllowOrigin=$0
  Header set Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin
  Header set Access-Control-Allow-Methods "GET, POST, OPTIONS"
  Header set Access-Control-Allow-Headers "Origin, Content-Type, Accept"
  Header set Access-Control-Allow-Credentials "true"
</IfModule>

• Access-Control-Allow-Credentials "true" erlaubt auch die Übertragung von Cookies oder HTTP-Auth-Informationen.
• Diese Einstellung erfordert, dass Access-Control-Allow-Origin kein * sein darf, sondern eine konkrete Domain sein muß.

Wichtige Hinweise:

• Wenn CORS nicht richtig konfiguriert ist, können Browser Zugriffe blockieren oder Fehler im Frontend auftreten.
• CORS betrifft nur Browser; direkte Server-zu-Server-Anfragen sind nicht betroffen.
• mod_headers muss auf dem eigenen Apache-Server aktiviert sein.
• Bei komplexeren CORS-Anforderungen ( Preflight-Requests i Ein Preflight-Request ist eine automatische OPTIONS-Anfrage des Browsers vor bestimmten CORS-Anfragen, um zu prüfen, ob der Server die tatsächliche Anfrage erlaubt. Das passiert bei Anfragen mit speziellen HTTP-Methoden (z. B. PUT, DELETE) oder mit benutzerdefinierten Headern. Der Server muß dann passende CORS-Header in der Antwort senden, damit die eigentliche Anfrage ausgeführt wird. , PUT/DELETE) sind oft noch zusätzliche Header notwendig.

Was ist CSP?

CSP ist eine Sicherheitsrichtlinie, die dem Browser genau vorgibt, welche Quellen für Skripte, Styles, Bilder und andere Ressourcen erlaubt sind. So kannst du z.B. verhindern, dass schädlicher Code (wie Cross-Site-Scripting (XSS) i Eine Sicherheitslücke, bei der Angreifer bösartigen Code (meist JavaScript) in Webseiten einschleusen, um z. B. Benutzerdaten zu stehlen oder Sitzungen zu übernehmen. ) ausgeführt wird.

Warum ist CSP wichtig?

Ohne CSP kann jede beliebige Quelle Skripte auf deiner Webseite ausführen – eine Einladung für Angreifer. CSP schränkt diesen Spielraum ein und erhöht damit die Sicherheit.

Die Content Security Policy (CSP) wird vom Browser umgesetzt – sie ist also nur so wirksam, wie der Browser sie unterstützt. Alte oder unsichere Browser ignorieren sie unter Umständen vollständig. CSP sollte daher nie als alleiniger Schutzmechanismus verstanden werden, sondern immer Teil eines umfassenden Sicherheitskonzepts sein.

Wie wird CSP in der .htaccess konfiguriert?

Die Konfiguration der Content-Security-Policy erfolgt über den HTTP-Header Content-Security-Policy. Er wird mit der 'Header set'- Direktive hinzugefügt:

Header set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self';"

• default-src 'self' erlaubt nur Ressourcen von der eigenen Domain.
• script-src 'self' blockiert Inline-Skripte und erlaubt nur externe Skripte von der eigenen Domain.
• style-src 'self' macht das Gleiche für Stylesheets.

Wann Inline-Skripte erlauben?

Manche Webseiten nutzen Inline-JavaScript oder CSS. Um diese zu erlauben, kann man 'unsafe-inline' hinzufügen, z.B.:

Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';"

⚠️ Vorsicht: 'unsafe-inline' reduziert den Schutz und sollte nur eingesetzt werden, wenn es keine Alternative gibt.

Inline-Skripte mit Hashes erlauben

Wenn unbedingt einzelne, bekannte Inline-Skripte genutzt werden sollen, können diese per SHA-256-Hash freigegeben werden:

<IfModule mod_headers.c>
  Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'sha256-AbC123...=';"
</IfModule>

Vorgehen:

1. Den Inhalt des Inline-Skripts nehmen (z. B. <script>alert("Test")</script>).
2. SHA-256-Hash davon erzeugen und Base64-codieren (sha256-nnD2G3mKzkt4r5VIR0K6O9a+JFsM9GzKyXWDIfmbuKs=).
3. In die CSP eintragen.

   Header set Content-Security-Policy "script-src 'self' 'sha256-nnD2G3mKzkt4r5VIR0K6O9a+JFsM9GzKyXWDIfmbuKs=';"

💡 CSP zuerst testen

Content-Security-Policy-Report-Only nutzen, um Richtlinien nur zu testen, bevor sie aktiviert werden:

<IfModule mod_headers.c>
  Header set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self';"
</IfModule>

Preflight-Requests

Manchmal sendet der Browser vor einer komplexen Anfrage einen Preflight-Requests i Ein Preflight-Request ist eine automatische OPTIONS-Anfrage des Browsers vor bestimmten CORS-Anfragen, um zu prüfen, ob der Server die tatsächliche Anfrage erlaubt. Das passiert bei Anfragen mit speziellen HTTP-Methoden (z. B. PUT, DELETE) oder mit benutzerdefinierten Headern. Der Server muß dann passende CORS-Header in der Antwort senden, damit die eigentliche Anfrage ausgeführt wird. (OPTIONS), um zu prüfen, ob die Anfrage erlaubt ist. CSP beeinflußt auch, wann und wie diese Anfragen stattfinden.

301-Weiterleitung

Eine permanente Weiterleitung, die auch von Suchmaschinen übernommen wird.

AddType

Legt den MIME-Typ für bestimmte Dateiendungen fest.

allow

Erlaubt Zugriff auf bestimmte Ressourcen oder IP-Adressen.

AuthType

Legt fest, welches Authentifizierungsverfahren der Server verwendet – meist Basic oder Digest.

Basic

Einfaches Authentifizierungsverfahren über Benutzername/Paßwort im Klartext (Base64) (s. AuthType).

Browsing Context Group

Eine Browsing Context Group ist eine Gruppe von Fenstern oder Tabs, die denselben JavaScript-Kontext teilen und miteinander interagieren können. COOP isoliert diese Gruppen.

Brute-Force-Angriff

Systematischer Versuch, Passwörter durch massenhaftes Ausprobieren zu erraten.

Caching

Zwischenspeicherung von Dateien im Browser, um diese bei späteren Seitenaufrufen schneller zu laden

Content Security Policy (CSP)

Eine Sicherheitsfunktion, mit der festgelegt wird, welche Quellen für Inhalte wie Skripte, Styles, Bilder oder Frames erlaubt sind. Dadurch wird die Website vor Cross-Site-Scripting (XSS) und anderen Angriffen geschützt.

Credential Stuffing

Credential Stuffing ist eine automatisierte Angriffsmethode auf Login-Systeme. Angreifer nutzen bereits geleakte Zugangsdaten (Benutzername/E-Mail + Paßwort) aus früheren Datenlecks. Diese Kombinationen werden massiv und automatisiert bei anderen Diensten ausprobiert. Grundlage ist, daß viele Nutzer Paßwörter mehrfach verwenden.

Cross-Origin-Resourcen

Cross-Origin-Resourcen sind Inhalte (z. B. Skripte, Bilder, Fonts), die von einer anderen Origin als der Hauptseite geladen werden. Richtlinien wie COOP/COEP steuern den Zugriff darauf.

Cross-Site-Scripting (XSS)

Eine Sicherheitslücke, bei der Angreifer bösartigen Code (meist JavaScript) in Webseiten einschleusen, um z. B. Benutzerdaten zu stehlen oder Sitzungen zu übernehmen.

Deny

Verweigert Zugriff auf bestimmte Ressourcen oder IP-Adressen.

Digest

Sichere Variante eines Authentifizierungsverfahrens, mit Hash-Funktion (s. AuthType).

Document Root

Das Hauptverzeichnis einer Website auf dem Server. Alle Pfade in der .htaccess (z. B. zu Fehlerseiten) beziehen sich relativ auf dieses Verzeichnis.

Duplicate Content

Doppelte Inhalte, die bei Suchmaschinen zu schlechterem Ranking führen können.

FTP

File Transfer Protocol (FTP) ist ein älteres Übertragungsprotokoll für Dateien. Es ist unsicher, da Passwörter unverschlüsselt übertragen werden. Besser: SFTP oder WebDAV, falls der Hoster dies anbietet.

Hacker versus Cracker

• Hacker: Technisch versierte Personen, die Systeme, Software oder Netzwerke kreativ nutzen oder analysieren. Kann legal oder illegal handeln, z. B. Security-Forschung oder Open-Source-Projekte.
• Cracker: Jemand, der Systeme illegal angreift, Sicherheitsmechanismen umgeht oder Software knackt. Immer böswillig und auf illegale Aktivitäten ausgerichtet.

Jeder Cracker ist ein Hacker, aber nicht jeder Hacker ist ein Cracker.

httpd.conf

Zentrale Konfigurationsdatei des Apache-Webservers. Sie legt serverweite Einstellungen wie Module, Virtual Hosts und globale Direktiven fest. Wird beim Serverstart geladen und gilt im Gegensatz zur .htaccess für den gesamten Server.

HTTPS

Sicheres Übertragungsprotokoll mit SSL-Verschlüsselung.

Man-in-the-Middle

Man-in-the-Middle (MitM) ist ein Angriff, bei dem sich ein Dritter heimlich zwischen zwei Kommunikationspartner schaltet, um deren Daten mitzulesen oder zu manipulieren. Verschlüsselung und Sicherheitsmechanismen wie HSTS reduzieren dieses Risiko deutlich.

mod_rewrite

Apache-Modul, das URL-Umschreibungen ermöglicht.

Options

Legt Serveroptionen für Verzeichnisse fest, z.B. Indexes oder FollowSymLinks.

Order

Steuerung der Reihenfolge von Zugriffsregeln in Apache (z.B. allow, deny).

Order allow,deny

Steuert die Reihenfolge der Zugriffssteuerung (veraltet in Apache 2.4, ersetzt durch Require).

Origin

Die Origin besteht aus Schema (http/https), Domain und Port. Sie definiert die Sicherheitsgrenze für Web-Ressourcen und erlaubt oder blockiert Cross-Origin-Zugriffe.

php_flag

Direktive zum Ein- oder Ausschalten von PHP-Einstellungen innerhalb der .htaccess.

php_value

Direktive zum Setzen von PHP-Konfigurationswerten in der .htaccess.

Preflight-Requests

Ein Preflight-Request ist eine automatische OPTIONS-Anfrage des Browsers vor bestimmten CORS-Anfragen, um zu prüfen, ob der Server die tatsächliche Anfrage erlaubt. Das passiert bei Anfragen mit speziellen HTTP-Methoden (z. B. PUT, DELETE) oder mit benutzerdefinierten Headern. Der Server muß dann passende CORS-Header in der Antwort senden, damit die eigentliche Anfrage ausgeführt wird.

Rate-Limiting

Mechanismus, um die Anzahl von Anfragen pro Zeitspanne zu begrenzen und so Überlastung oder Mißbrauch zu verhindern.

Redirect

Einfaches Umleitungskommando, um URLs dauerhaft oder temporär weiterzuleiten.

Require

Apache 2.4 Direktive zur Zugriffssteuerung basierend auf Benutzer, Host oder IP.

Rewrite-Modul

Aktiviert die Verarbeitung von Umschreiberegeln in Apache (siehe mod_rewrite).

RewriteRule

Anweisung, um URLs anhand von Mustern umzuschreiben (mod_rewrite).

Script-Kiddies

Unerfahrene Angreifer, die fertige Tools oder Skripte nutzen, ohne die zugrunde liegende Technik zu verstehen. Der Begriff stammt aus der Hacker-Szene der späten 1990er Jahre und betont, daß es sich nicht um erfahrene Cracker handelt. Ihre Angriffe sind meist automatisiert oder einfach und leicht zu erkennen, im Gegensatz zu professionellen Angreifern oder Crackern. Ein etwa gleich zu setzender Begriff aus der IT-Security-Forschung: „low-skill attacker“.

SEO-Bewertung

Die SEO-Bewertung umfaßt verschiedene technische, inhaltliche und strukturelle Faktoren, mit denen Suchmaschinen die Qualität und Relevanz einer Website einschätzen. Dazu gehören u.a. Ladezeit, Mobilfreundlichkeit, sichere Verbindung (HTTPS), interne Verlinkung, sprechende URLs und Inhaltsstruktur.

SharedArrayBuffer

SharedArrayBuffer ist ein JavaScript-Objekt, das es erlaubt, großen Speicher zwischen Threads oder Web Workern zu teilen, um Hochleistungsberechnungen effizient durchzuführen.

sprechende URL's

Sogenannte sprechende URLs – auch „Pretty URLs“ genannt – sind Webadressen, die lesbar und verständlich sind, sowohl für Menschen als auch für Suchmaschinen. Anstelle technischer Pfade wie /seite.php?id=42 verwendet man dann z. B. /ueber-uns oder /kontakt. Das wirkt benutzerfreundlich, steigert die Vertrauenswürdigkeit und kann sich positiv auf die Suchmaschinenoptimierung auswirken.

SSL-Stripping

SSL-Stripping ist ein Angriff, bei dem eine eigentlich sichere HTTPS-Verbindung auf unsicheres HTTP herabgestuft wird, damit Angreifer Daten mitlesen oder manipulieren können. HSTS schützt davor, indem der Browser ausschließlich HTTPS akzeptiert.

Web Worker

Web Worker sind JavaScript-Hintergrund-Threads, die Berechnungen ausführen, ohne die Hauptseite zu blockieren. Sie können Daten mit SharedArrayBuffer effizient verarbeiten.

Zwei-Faktor-Authentifizierung

Login-Methode mit zusätzlicher Sicherheit durch einen zweiten Faktor, z. B. Einmalcode oder Authenticator-App.