HTTP-Header-Prüfer
Sicherheit, Komprimierung und Caching
Dieser HTTP-Header-Prüfer liest die Antwort jeder Seite und bewertet sie in einem Durchgang: die acht Sicherheits-Header, Komprimierung, Caching und was der Server preisgibt. Danach schreibt er die Zeilen, die jede Lücke schließen, für Apache, Nginx oder eine Header-Datei.
- KostenlosPreis
- 23Prüfungen
- InklusiveKorrektur
- NichtsGespeichert
HTTP-Header-Prüfer
Acht Sicherheits-Header, Komprimierung und Caching, in einem Durchgang bewertet
- Punktzahl
- —
- Bestanden
- 0
- Warnungen
- 0
- Fehler
- 0
- Erstes Byte
- —
| Header | Wert | Urteil | Was es bedeutet |
|---|---|---|---|
| Fügen Sie oben eine Adresse ein, dann erscheint die Antwort hier. | |||
Die Punktzahl ist unsere eigene Gewichtung der Zeilen oben, keine Branchennote. HTTPS, die Richtlinie und die Komprimierung zählen am meisten; alles als Information Markierte zählt nicht.
Fertige Zeilen für jeden Header oben, der durchgefallen ist oder gewarnt hat. Wählen Sie Ihren Server, fügen Sie die Zeilen ein und prüfen Sie erneut.
Bereit. Fügen Sie eine öffentliche Adresse ein, dann öffnet dieser Server zwei Verbindungen dorthin.
Was Antwort-Header entscheiden
Jede Seite kommt mit ein paar Zeilen, die der Besucher nie sieht. Diese Zeilen sind die Antwort-Header.
Sie sagen dem Browser, wie er die Seite behandeln soll: welche Skripte laufen dürfen, ob sie in einem Frame stehen darf, wie lange sie aufbewahrt werden darf und ob sie komprimiert kam.
Also können zwei Seiten mit identischem Inhalt bei Tempo und Sicherheit sehr verschieden sein. Der Unterschied steckt ganz in den Headern.
Dieser Prüfer liest sie von einer Live-Adresse, bewertet jeden einzelnen und gibt Ihnen dann die Konfiguration, die die schwachen behebt.
Die acht Sicherheits-Header
Strict-Transport-Security hält Browser auf HTTPS. Content-Security-Policy entscheidet, welche Skripte laufen dürfen, und ist damit der wichtigste Schutz gegen eingeschleusten Code.
X-Content-Type-Options verhindert, dass Browser Dateitypen raten. Der Frame-Schutz über X-Frame-Options oder frame-ancestors hindert fremde Websites daran, Ihre Seite in einen Frame zu packen und Klicks abzugreifen.
Referrer-Policy begrenzt, was Ihre Adresse anderen Websites verrät. Permissions-Policy schaltet zudem Kamera, Mikrofon und Standort ab, wenn eine Seite sie nicht anfordert.
Schließlich halten die beiden Cross-Origin-Richtlinien andere Fenster und Websites von der Seite fern. Zusammen schließen diese acht die meisten Türen, die ein Angreifer zuerst probiert.
Warum die Komprimierung getrennt geprüft wird
Ein Server komprimiert nur, wenn der Browser danach fragt. Deshalb öffnet dieses Tool eine zweite Verbindung, die gzip und Brotli anbietet, und meldet, was zurückkommt.

Komprimierung verkleinert eine HTML-Seite meist um etwa siebzig Prozent. Daher gehört sie zu den günstigsten Tempogewinnen einer Website und fehlt trotzdem besonders oft.
Der Vary-Header wird gleich mitgeprüft, denn eine komprimierte Seite ohne Vary: Accept-Encoding kann ein gemeinsamer Cache an den falschen Browser ausliefern.
Caching in einfachen Worten
Cache-Control sagt, wie lange eine Kopie wiederverwendet werden darf. Ohne ihn erfindet jeder Browser und jeder Proxy eigene Regeln, und die stimmen selten überein.

ETag und Last-Modified erlauben es einem wiederkehrenden Browser zu fragen, ob seine Kopie noch aktuell ist. Folglich bekommt er eine winzige "nicht geändert"-Antwort statt der ganzen Seite.
Was der Server preisgibt
Die Header Server und X-Powered-By nennen oft die genaue Software und Version. Das hilft keinem Besucher, erspart einem Angreifer jedoch einen Schritt.

Auch Cookies werden geprüft. Jedes sollte Secure, HttpOnly und SameSite tragen, denn sonst kann es unverschlüsselt reisen oder von einem Skript gelesen werden.
Wie die Korrektur geschrieben wird
Für jede fehlgeschlagene Zeile, die eine Konfigurationszeile beheben kann, schreibt das Tool genau diese Zeile. Sie wählen Apache, Nginx oder eine _headers-Datei, und der Block passt sich an.
Die Content-Security-Policy-Zeile wird absichtlich als Report-Only geschrieben. Eine allgemeine Richtlinie, sofort scharf geschaltet, kann die eigenen Skripte einer Website blockieren, während der Berichtsmodus erst zeigt, was brechen würde.
Manches ist kein Header-Problem, etwa ein langsames erstes Byte. Das wird aufgelistet, bleibt aber außerhalb des Blocks, damit darin nichts vorgibt, etwas zu beheben, das es nicht kann.
Zur Punktzahl
Die Punktzahl ist unsere eigene Gewichtung, kein Branchenstandard. HTTPS, die Content-Policy und Komprimierung zählen am meisten, während Informationszeilen gar nicht zählen.
So nutzen Sie den HTTP-Header-Prüfer
Eine Adresse hinein, eine bewertete Antwort und eine fertige Korrektur heraus.
- 1
Seitenadresse einfügen
Jede öffentliche Seite geht, und Weiterleitungen werden bis zur letzten Antwort verfolgt.
- 2
Punktzahl und Liste lesen
Die Fehler stehen in jeder Gruppe zuerst. Jede Zeile sagt, was sie gefunden hat und warum das zählt.
- 3
Server wählen
Wählen Sie Apache, Nginx oder eine _headers-Datei, dann schreibt sich der Korrekturblock für diesen Server um.
- 4
Einfügen, neu laden, erneut prüfen
Fügen Sie die Zeilen ein, laden Sie den Server neu und prüfen Sie dann erneut, um die Zeilen grün werden zu sehen.
Was diesen Header-Prüfer auszeichnet
Die meisten Header-Tools geben die Rohliste aus und hören auf. Dieses erklärt sie dagegen und behebt die Lücken.
Sicherheit, Tempo und Caching zusammen
Dreiundzwanzig Prüfungen in fünf Gruppen statt drei getrennter Tools, die jeweils nur einen Teil sehen.
Die Korrektur, für Sie geschrieben
Fertige Zeilen für Apache, Nginx oder eine _headers-Datei, nur für die Zeilen, die sie brauchen.
Komprimierung wirklich getestet
Eine zweite Verbindung fragt nach gzip und Brotli, deshalb zeigt die Antwort, was ein echter Browser bekommt.
Sichere Voreinstellungen
Die Content-Policy kommt zuerst im Berichtsmodus, also kann das Ausprobieren der Korrektur die Website nicht kaputtmachen.
Rohe Header mit einem Tipp
Die unbearbeitete Liste hat einen eigenen Tab für alle, die jede Zeile lesen möchten.
Nichts wird gespeichert
Die Adresse dient einer Prüfung und ist dann weg. Außerdem schreibt dieser Server keinen Eintrag darüber.
Regeln für Antwort-Header
Acht Gewohnheiten, die Header nach der ersten Korrektur richtig halten.
- Zuerst HTTPS reparieren. Jeder Sicherheits-Header setzt eine verschlüsselte Verbindung voraus. Über unverschlüsseltes HTTP bewirken die meisten nichts.
- Die Content-Policy langsam einführen. Beginnen Sie im Berichtsmodus, lesen Sie, was blockiert würde, und schalten Sie sie dann scharf, sobald die Berichte ruhig sind.
- HSTS schrittweise erhöhen. Beginnen Sie mit einem kurzen max-age, prüfen Sie, dass jede Subdomain HTTPS liefert, und gehen Sie dann auf ein volles Jahr.
- Text komprimieren, keine Bilder. HTML, CSS, JavaScript und SVG schrumpfen stark. JPEG und WebP sind dagegen schon komprimiert, also bringt gzip dort nichts.
- Etwas zum Caching sagen. Selbst no-store ist besser als Schweigen, weil Schweigen jeden Cache anders raten lässt.
- Versionsnummern verbergen. Schalten Sie Server-Tokens und X-Powered-By ab. Sie helfen nur Angreifern.
- Jedes Cookie kennzeichnen. Secure, HttpOnly und SameSite an jedem, auch an Cookies, die Plugins setzen.
- Nach jedem Deployment erneut prüfen. Ein neuer Server, ein CDN oder ein Plugin kann Header still entfernen, deshalb sollten Sie bei jeder Änderung erneut prüfen.
Sechs Header-Fehler, die verborgen bleiben
Keiner davon ist auf der Seite zu sehen, und genau deshalb halten sie sich jahrelang.
Eine Richtlinie mit unsafe-inline
Sie sieht wie eine Content-Policy aus, lässt aber eingeschleustes Skript laufen. Nutzen Sie stattdessen eine Nonce oder einen Hash.
HSTS über unverschlüsseltes HTTP
Dort ignorieren Browser ihn. Er zählt nur, wenn er mit einer HTTPS-Antwort ankommt.
Sicherheitsheader allein auf der Homepage
Sicherheits-Header in nur einer Vorlage fehlen auf allen anderen Seiten. Setzen Sie sie deshalb besser auf dem Server.
Komprimierung von einem Proxy abgeschaltet
Ein CDN oder eine Firewall vor der Website kann rückgängig machen, was der Ursprung gesetzt hat. Prüfen Sie also die Adresse, die Besucher nutzen.
Doppelte Header
Zwei verschiedene Werte für denselben Header, einer von der App und einer vom Server, lassen den Browser wählen.
Feature-Policy statt Permissions-Policy
Der alte Name wurde vor Jahren abgelöst. Aktuelle Browser lesen nur noch den neuen.
Häufige Fragen zu HTTP-Headern
Was sind HTTP-Header?
Das sind kurze Zeilen, die mit jeder Antwort vor der Seite selbst mitkommen. Sie sagen dem Browser, wie er mit dem Folgenden umgehen soll.
Welche Sicherheits-Header sollte jede Website senden?
Mindestens Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Frame-Schutz, Referrer-Policy und Permissions-Policy. Die beiden Cross-Origin-Richtlinien schützen zudem weiter.
Beeinflussen Sicherheits-Header die SEO?
Nicht direkt. HTTPS ist jedoch ein Rankingsignal, und Komprimierung und Caching machen Seiten schneller, was sehr wohl zählt.
Wo füge ich die Korrektur ein?
Bei Apache in die .htaccess mit aktiviertem mod_headers. Bei Nginx in den server-Block. Bei Netlify oder Cloudflare Pages in eine _headers-Datei im Stammverzeichnis.
Macht die Content-Policy meine Website kaputt?
Die hier geschriebene nicht, weil sie Report-Only ist. Sie blockiert nichts und listet stattdessen auf, was eine aktive Richtlinie stoppen würde.
Warum weicht meine Punktzahl von anderen Tools ab?
Jedes Tool gewichtet die Zeilen auf seine Weise. Außerdem zählt dieses Komprimierung und Caching, die reine Sicherheitsscanner ignorieren.
Ich nutze WordPress. Woher kommen die Header?
Meist vom Server oder von einem Plugin. Deshalb funktionieren die .htaccess-Zeilen auf den meisten WordPress-Hostings mit Apache.
Warum wird die Komprimierung nicht gemessen?
Die zweite Verbindung, die nach gzip fragt, wurde nicht abgeschlossen. Dann bleibt die Zeile unbewertet, statt geraten zu werden.
Was unterscheidet das vom Statuscode-Prüfer?
Der Statuscode-Prüfer zeigt, was eine Adresse antwortet und wohin sie weiterleitet. Dieses Tool bewertet dagegen die Header dieser Antwort und schreibt die Korrektur.
Speichern Sie die Adresse, die ich hier prüfen lasse?
Nein. Sie dient einer einzigen Prüfung und ist dann weg, und nichts davon wird protokolliert.
Tools zum Prüfen eines Servers
Header sind eine Schicht der Antwort. Diese drei prüfen die übrigen.
HTTP-Statuscode-Prüfer
Der Status, den eine Adresse liefert, und jeder Sprung auf dem Weg.
Tool öffnen →SSL-Prüfer
Ablauf des Zertifikats, abgedeckte Namen und ob Browser ihm vertrauen.
Tool öffnen →Weiterleitungsketten-Prüfer
Jeder Sprung zwischen eingegebener Adresse und Zielseite.
Tool öffnen →
Bereit, Ihre Header zu prüfen?
Fügen Sie eine Adresse ein, lesen Sie die Note und kopieren Sie die Korrektur für Ihren Server. Der HTTP-Header-Prüfer ist kostenlos, braucht kein Konto und speichert nichts.