Das Wichtigste in Kürze

  • Grundlage: HTTPS überall, gültiges Zertifikat, keine unverschlüsselt nachgeladenen Inhalte.
  • HSTS sagt Browsern, die Seite nur noch verschlüsselt aufzurufen; ein Jahr Laufzeit ist üblich.
  • Weitere Header: X-Content-Type-Options, Schutz vor Clickjacking, Referrer-Policy, Content-Security-Policy.
  • Veraltete Software und sichtbare Versionsnummern sind ein häufiges, leicht behebbares Risiko.

Warum das auch kleine Betriebe betrifft

Die meisten Angriffe auf kleine Websites sind nicht persönlich. Automatische Programme suchen rund um die Uhr nach bekannten Schwachstellen, etwa veralteten WordPress-Plugins. Wer gefunden wird, verteilt danach unbemerkt Schadsoftware oder Spam, und Browser warnen Ihre Kunden vor der Seite. Die gute Nachricht: Ein großer Teil des Schutzes besteht aus Einstellungen, die einmal richtig gesetzt werden und dann bleiben.

Die Grundlage: HTTPS und Zertifikat

HTTPS verschlüsselt die Verbindung zwischen Besucher und Server. Ohne HTTPS können Daten aus Kontaktformularen unterwegs mitgelesen werden, und Browser markieren die Seite als nicht sicher. Das Zertifikat bestätigt, dass die Verbindung wirklich zu Ihrer Domain führt. Läuft es ab oder passt es nicht zur Domain, erscheint eine ganzseitige Warnung – die meisten Besucher sind dann weg.

Für die Verschlüsselung selbst nutzen aktuelle Server TLS 1.2 oder TLS 1.3. Das BSI beschreibt den Einsatz von TLS in seiner Technischen Richtlinie TR-02102 (Teil 2). Ältere Versionen sollten abgeschaltet sein; das erledigt meist der Hoster.

Gemischte Inhalte

Lädt eine HTTPS-Seite Bilder, Skripte oder Schriften noch über http, spricht man von gemischten Inhalten. Laut MDN rüsten Browser Bilder, Audio und Video automatisch auf HTTPS um, Skripte, Stylesheets und iframes dagegen werden blockiert – die Seite sieht dann plötzlich kaputt aus. Abhilfe: alle Adressen auf https umstellen.

Die wichtigsten Security-Header

Security-Header sind kurze Anweisungen, die Ihr Server bei jeder Antwort mitschickt. Besucher sehen sie nicht, der Browser hält sich daran. Die Empfehlungen in der Tabelle folgen dem OWASP HTTP Headers Cheat Sheet, einer verbreiteten Sammlung bewährter Einstellungen:

HeaderWozuÜblicher Wert
Strict-Transport-Security (HSTS)Browser rufen die Seite nur noch per HTTPS aufmax-age=31536000 (ein Jahr) oder länger; includeSubDomains, wenn alle Subdomains HTTPS haben
X-Content-Type-Optionsverhindert, dass der Browser Dateitypen errätnosniff
X-Frame-Options oder CSP frame-ancestorsverhindert Einbettung in fremde Seiten (Clickjacking)DENY bzw. frame-ancestors
Referrer-Policybegrenzt, welche Adresse an andere Seiten weitergegeben wirdstrict-origin-when-cross-origin
Permissions-Policyschaltet ungenutzte Funktionen wie Kamera oder Standort abz. B. camera=(), microphone=(), geolocation=()
Content-Security-Policylegt fest, woher Skripte und Inhalte geladen werden dürfenindividuell; erst im Report-Only-Modus testen

Vorsicht bei HSTS

Laut MDN merken sich Browser HSTS für die angegebene Zeit. Wer HSTS setzt und später ein Zertifikatsproblem hat, sperrt seine Besucher aus, bis die Zeit abläuft. Setzen Sie HSTS deshalb erst, wenn HTTPS stabil läuft, und includeSubDomains nur, wenn wirklich alle Subdomains verschlüsselt sind.

Was sonst oft übersehen wird

  • Software aktuell halten: CMS, Theme und Plugins. Veraltetes jQuery vor Version 3.5 hat bekannte Schwachstellen.
  • Versionsnummern verbergen: Header wie Server oder X-Powered-By und das WordPress-Generator-Tag verraten sonst, welche Version läuft. OWASP empfiehlt, X-Powered-By ganz zu entfernen.
  • Cookies mit den Attributen Secure, HttpOnly und SameSite setzen.
  • Formulare nur an https-Adressen senden lassen.
  • Regelmäßige Backups, die nicht auf demselben Server liegen.
  • Starke, einzigartige Passwörter und, wo möglich, Zwei-Faktor-Anmeldung für den Admin-Zugang.

Wie Sie die Header setzen

Je nach System an unterschiedlicher Stelle: bei Apache in der .htaccess, bei nginx in der Server-Konfiguration, bei WordPress über ein Sicherheits-Plugin oder den Hoster, bei Baukastensystemen oft gar nicht selbst – dann lohnt eine Nachfrage beim Anbieter. Testen Sie nach jeder Änderung, ob Formulare, Karten und eingebettete Videos noch funktionieren. Vor allem eine zu strenge Content-Security-Policy blockiert schnell Dinge, die Sie brauchen.

Fünf Fragen an Ihren Hoster oder Webdienstleister

Wenn Sie die Technik nicht selbst betreuen, reicht oft eine kurze E-Mail mit diesen Fragen. Die Antworten zeigen schnell, ob sich jemand kümmert:

  • Wird das Zertifikat automatisch erneuert, und wer bekommt eine Nachricht, wenn das scheitert?
  • Werden CMS, Theme und Plugins regelmäßig aktualisiert – von wem und wie oft?
  • Wo liegen die Backups, wie lange werden sie aufbewahrt, und wurde eine Wiederherstellung schon einmal getestet?
  • Sind HSTS und die übrigen Security-Header gesetzt?
  • Wer hat Admin-Zugänge, und sind ehemalige Mitarbeiter oder Dienstleister entfernt?

Was der Sicherheits-Check prüft – und was ausdrücklich nicht

Der Sicherheits-Check liest nur, was Ihr Server ohnehin jedem Besucher schickt: ob HTTPS aktiv ist und http weiterleitet, ob das Zertifikat gültig ist und wann es abläuft, welche TLS-Version ausgehandelt wird, welche der genannten Header gesetzt sind, ob gemischte Inhalte oder unverschlüsselte Formulare vorkommen, wie Cookies gesetzt sind und ob Versionsnummern, veraltetes jQuery oder eine sichtbare WordPress-Version auffallen. Für HSTS erwartet er mindestens 180 Tage Laufzeit.

Er greift nichts an, meldet sich nirgends an und sucht keine Lücken in Ihrem Code. Ein grünes Ergebnis heißt also: Die Grundeinstellungen stimmen. Es heißt nicht, dass Ihre Website sicher vor jedem Angriff ist. Wie die Bewertung entsteht, steht in der Methodik. Passende Weiterleitungen von http auf https erklärt der Ratgeber http auf https weiterleiten. Wenn Sie die Einrichtung abgeben möchten, hilft die Webagentur Scherzinger (webagentur-scherzinger.com).

Häufige Fragen

Ist meine Seite sicher, wenn der Check grün ist?

Die geprüften Grundeinstellungen stimmen dann. Lücken in Software oder Passwörtern findet ein passiver Check nicht.

Welche HSTS-Laufzeit ist sinnvoll?

Üblich ist ein Jahr (max-age=31536000) oder mehr. Unser Check erwartet mindestens 180 Tage.

Brauche ich X-XSS-Protection?

OWASP rät, den Header nicht zu setzen oder ausdrücklich abzuschalten und stattdessen eine Content-Security-Policy zu verwenden.

Kann mein Hoster die Header setzen?

Oft ja, per Einstellung oder auf Anfrage. Bei Baukästen ist das manchmal die einzige Möglichkeit.

Quellen

  1. OWASP: HTTP Headers Cheat Sheet abgerufen am 17.10.2026
  2. MDN: Strict-Transport-Security abgerufen am 17.10.2026
  3. MDN: Mixed content abgerufen am 17.10.2026
  4. BSI: Technische Richtlinie TR-02102 Kryptographische Verfahren abgerufen am 17.10.2026