Zum Inhalt springen

Schutz-Einstellungen des Servers

Sendet der Webserver die wichtigsten Security-Header, und sind sie wirksam eingestellt?

Was wir prüfen

Mit jeder Seite schickt der Webserver unsichtbare Zusatzangaben mit, die sogenannten HTTP-Header. Einige davon weisen den Browser an, bestimmte Angriffe abzuwehren. Wir prüfen auf der Startseite sechs davon:

Header Schützt vor
Strict-Transport-Security (HSTS) Rückfall auf unverschlüsseltes HTTP
Content-Security-Policy eingeschleustem fremdem Code
X-Frame-Options Einbetten der Seite auf fremden Seiten (Klick-Betrug)
Referrer-Policy unnötiger Weitergabe besuchter Adressen
X-Content-Type-Options falsch interpretierten Dateien
Permissions-Policy ungewolltem Zugriff auf Kamera, Mikrofon oder Standort

Fehlen drei der ersten vier, gibt es eine Warnung. Fehlen einzelne, einen Hinweis. Ausserdem melden wir schwache Einstellungen: eine HSTS-Dauer unter 180 Tagen und unsafe-inline oder unsafe-eval in der Content-Security-Policy.

Warum das wichtig ist

Security-Header sind wie die Sicherheitsgurte einer Website. Sie verhindern keinen Fehler im Code, begrenzen aber den Schaden, wenn einer passiert:

  • HSTS sorgt dafür, dass der Browser die Seite nur noch verschlüsselt aufruft, auch wenn jemand http:// eintippt oder einem alten Link folgt.
  • Content-Security-Policy legt fest, von welchen Adressen Skripte geladen werden dürfen. Gelingt es einem Angreifer, Code in die Seite einzuschleusen, etwa über ein verwundbares Plugin, wird dieser Code nicht ausgeführt.
  • X-Frame-Options verhindert, dass eine Betrugsseite die Website unsichtbar einbettet und Besucher zu Klicks verleitet.

Diese Header kosten nichts, verlangsamen nichts und lassen sich meist mit wenigen Zeilen einrichten.

So behebst Du es

Apache (.htaccess)

Für die meisten Websites ist das ein guter Anfang:

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

Setze HSTS erst, wenn HTTPS zuverlässig funktioniert, auch für alle Subdomains, sonst werden Besucher ausgesperrt.

Content-Security-Policy

Sie hängt davon ab, welche fremden Dienste die Seite einbindet: Google Fonts, Maps, YouTube, Analyse-Tools. Lass sie von der betreuenden Agentur erstellen und zuerst im Modus Content-Security-Policy-Report-Only testen.

WordPress

Plugins wie «Headers Security Advanced & HSTS WP» setzen die Header ohne Serverzugriff. Auch manche Sicherheits- und Caching-Plugins bieten diese Funktion.

Hosting mit Panel

Bei Plesk und cPanel lassen sich zusätzliche Header in den Einstellungen für Apache bzw. nginx eintragen. Frag im Zweifel den Support des Hosters.

So prüfst Du es selbst

Gib die Adresse der Website auf securityheaders.com ein. Der Dienst zeigt alle gesetzten Header und bewertet sie mit einer Note von A+ bis F.

Häufige Fragen

Können diese Header etwas kaputt machen?

Bei der Content-Security-Policy ja: Ist sie zu streng, laden Schriften, Karten oder Videos nicht mehr. Darum zuerst mit «Content-Security-Policy-Report-Only» testen. Die übrigen Header sind unproblematisch.

Der Baukasten lässt keine eigenen Header zu. Was nun?

Bei Wix, Jimdo oder Squarespace legt der Anbieter die Header fest. Man kann ihn darauf ansprechen, selbst ändern lässt es sich meist nicht. Die Prüfung zeigt dann vor allem, wie gut der Anbieter vorsorgt.

Jetzt eine Website prüfen

Wir prüfen «Schutz-Einstellungen des Servers» und alle anderen Punkte in wenigen Minuten, kostenlos und ohne Anmeldung.