Beliebte Tools

Design

HTTP-Header-Checker

HTTP-Header jeder URL prüfen, genau so, wie der Server sie sendet, in Reihenfolge und mit jedem Duplikat, dazu eine Sicherheitsnote nach den Tests des Mozilla HTTP Observatory und die Lösung für nginx, Apache, IIS, Cloudflare, Vercel, Netlify oder Express. Auch Caching, Cookies und Serverdetails.

Eine Anfrage von unserem Server, der rohe Kopf in Reihenfolge gespeichert · die veröffentlichten Tests des Mozilla HTTP Observatory (Algorithmus 6) · Cookie-Werte werden nie angezeigt oder gespeichert

Wir folgen Weiterleitungen bis zur Zielseite und bewerten diese Seite. Die Header jedes Schritts stehen unter Redirects.

Als
Beispiele

Was sind HTTP-Header?

HTTP-Header sind die Zeilen, die ein Server vor der Seite selbst sendet: eine Statuszeile, dann ein Feld name: value pro Zeile, dann eine Leerzeile und der Body (RFC 9110). Namen unterscheiden nicht zwischen Groß- und Kleinschreibung; die Werte gehören dem Server.

Response Header sagen dem Browser, was der Inhalt ist, wie lange er eine Kopie behalten darf, welche Cookies er speichern soll und welche Sicherheitsregeln er durchsetzen muss. Dieser Checker zeigt sie genau so, wie gesendet, in Reihenfolge und mit jedem Duplikat, und färbt jede Zeile nach ihrer Aufgabe ein.

Der Aufbau einer Antwortgithub.com · aufgezeichnet 24. Oktober 2026
StatuszeileHTTP/1.1200OK
FeldzeilenStrict-Transport-Security: max-age=31536000; includeSubdomains; preload
X-Frame-Options: deny
Cache-Control: max-age=0, private, must-revalidate
Content-Type: text/html; charset=utf-8
Set-Cookie: _gh_sess=‹344 Zeichen›; path=/; HttpOnly; secure; SameSite=Lax
Server: github.com
… 14 weitere Zeilen
Body<!DOCTYPE html><html lang="en" …
Sicherheitwas der Browser durchsetzen muss
Cachingwie lange eine Kopie wiederverwendet werden darf
Cookieswas der Browser speichert
Server & Edgewer geantwortet hat, über welches CDN

Wie kann ich die HTTP-Header einer Website prüfen?

Geben Sie oben die URL ein und wählen Sie Header prüfen: Der Checker fragt sie von unserem Server an, folgt Weiterleitungen bis zur Zielseite und zeigt den Antwortkopf dieser Seite Zeile für Zeile, mit der Sicherheitsnote daneben. Wählen Sie HEAD im Methodenfeld, um nur den Kopf anzufragen.

Wählen Sie eine beliebige Zeile, um zu sehen, was sie bewirkt und was ihr Wert bedeutet. Die Ansichten darunter sortieren die Befunde: Sicherheit mit der Lösung pro Server, Caching, Cookies, Server & Protokoll und Weiterleitungen.

Header-Checker: die Antwort genau wie gesendet

Ursprüngliche Schreibweise und Reihenfolge, Duplikate bleiben, gelesen über HTTP/1.1; lange Werte werden umgebrochen, Cookie-Werte nie angezeigt. Eine Website hinter Cloudflare wird über Cloudflares Netzwerk gelesen, und das Ergebnis sagt das.

Security Headers prüfen mit den Tests des Mozilla Observatory

Dieselben 12 Tests und Punkte wie im Code des Observatory, beide Runden in der Punktespalte durchgerechnet, und ein Link zum Scan des Hosts von Mozilla selbst.

Server-Header-Checker: Software, CDN und Protokoll

Server und X-Powered-By mit jeder Version, die sie verraten, das CDN und sein Cache-Status, die TLS-Version, HTTP/2 und HTTP/3.

HSTS-Checker und Preload-Bereitschaft

max-age, includeSubDomains und preload gegen die Regeln von hstspreload.org gelesen, als Information: Preloading ist optional.

HTTP-Header prüfen bei github.com: die Response Header, wie gesendet, und eine Sicherheitsnote A+ mit 115 PunktenHTTP-Header prüfen bei github.com: die Response Header, wie gesendet, und eine Sicherheitsnote A+ mit 115 PunktenDie Note und das UrteilNote und Punkte des Observatory für die Zielseite, mit den wertvollsten Korrekturen zuerst.Eine Header-Zeile, wie gesendetJede Zeile in Schreibweise und Reihenfolge des Servers; die Marke am Rand ist das Testergebnis dieses Headers.Die BonusrundeBoni zählen nur, wenn die Punktzahl nach allen Abzügen noch 90 oder mehr beträgt: die zwei Runden des Observatory.Die AnsichtenSicherheit mit der Lösung pro Server, dann Caching, Cookies, Server und Protokoll sowie die Weiterleitungen.
Ein Header-Check von github.com: Note und Urteil, die Antwort genau wie gesendet und die zwei Runden des Mozilla HTTP Observatory durchgerechnet. Wählen Sie eine Nummer, um zu sehen, was der jeweilige Teil zeigt.

Welche Security Header sollte jede Website senden?

Beginnen Sie mit vier: Content-Security-Policy, Strict-Transport-Security, Schutz vor Einbettung (X-Frame-Options oder CSP frame-ancestors) und X-Content-Type-Options: nosniff. Fehlen sie, kostet das in der Note des Mozilla HTTP Observatory die meisten Punkte.

Referrer-Policy und die Cross-Origin-Richtlinien (COOP, COEP und CORP) bringen Bonuspunkte, sobald die Grundlagen stimmen. Permissions-Policy lohnt sich, aber nur Chromium-Browser lesen sie, und das Observatory bewertet sie nicht.

Die Security Header und was jeder wert istMozilla HTTP Observatory · Algorithmus 6
HeaderVerhindertFehltGut gesetztFunktioniert in
Content-Security-Policyeingeschleuste Skripte−25+5 / +10
Strict-Transport-Securityein Downgrade auf http://−20+5 preloaded
X-Frame-Options · frame-ancestorsClickjacking in einem versteckten Frame−20+5
X-Content-Type-OptionsDateien, die als falscher Typ ausgeführt werden−50
Referrer-Policyvollständige URLs, die an andere Websites gelangen0+5
Cross-Origin-Opener-Policyandere Fenster, die hineingreifen0+10
Cross-Origin-Embedder-PolicyLaden von allem, was nicht zugestimmt hat0+10
Cross-Origin-Resource-Policyandere Websites, die Ihre Dateien einbetten0+10
Permissions-PolicyEinbettungen, die Kamera, Mikrofon, Standort nutzen—nicht bewertetnur
Boni zählen nur, wenn die Punktzahl nach den Abzügen noch 90 oder mehr beträgt. Die anderen Tests des Observatory betrachten Cookies, Subresource Integrity, CORS und die Weiterleitung auf HTTPS.

Wie wird die Sicherheitsnote berechnet?

Wir folgen der Methode des Mozilla HTTP Observatory Test für Test: Start bei 100, jeden Abzug abziehen, und nur wenn das Ergebnis noch 90 oder mehr beträgt, die Boni addieren. Die Punktzahl wird dann einer Note von F bis A+ zugeordnet (Scoring-Dokumentation des Observatory).

Diese zweite Runde überrascht viele: Eine Website mit einem teuren Fehler behält keinen ihrer Boni. Mit COOP und COEP, die 2026 hinzukamen, erlaubt der Code des Observatory bis zu 165 Punkte, während seine Dokumentation am 24. Oktober 2026 noch 145 nannte; wir folgen dem Code. Jedes Ergebnis verlinkt auf den Scan des Hosts von Mozilla selbst, sodass Sie vergleichen können.

Zwei Websites, durchgerechnetErgebnisse des Observatory selbst, 24. Oktober 2026

github.comA+

  1. Start100
  2. Kein SRI bei externen Skripten−595
  3. 90 oder mehr: die Bonusrunde zählt
  4. Cookies: Secure, HttpOnly, SameSite+5
  5. Referrer-Policy+5
  6. HSTS preloaded+5
  7. Einbettungsschutz über CSP+5
  8. Punktzahl115

www.mozilla.orgB+

  1. Start100
  2. CSP erlaubt 'unsafe-inline'−2080
  3. unter 90: die Bonusrunde entfällt
  4. COOP same-origin+10
  5. Referrer-Policy+5
  6. Einbettungsschutz über CSP+5
  7. Punktzahl80
Mozillas Website verliert 20 Punkte durch eine CSP-Direktive, und dann zählen die 20 Bonuspunkte, die sie bereits verdient hat, nicht mehr. Ohne 'unsafe-inline' und 'unsafe-eval' in diesem script-src würden dieselben Header 120 erreichen.

Was ist HSTS, und sollten Sie es preloaden?

Strict-Transport-Security sagt Browsern, für einen Host max-age Sekunden lang nur https:// zu verwenden, und includeSubDomains dehnt das auf jede Subdomain aus (RFC 6797). Browser ignorieren ihn über reines http://, und nur der erste solche Header zählt. Das Observatory zieht 20 Punkte ab, wenn er fehlt, und 10, wenn max-age unter sechs Monaten liegt.

Preloading ist optional: hstspreload.org sagt inzwischen, HSTS sei empfohlen, Preloading aber nicht, weil Chrome und Safari Navigationen ohnehin auf HTTPS hochstufen und der Austritt aus der Liste Monate dauert. Wer trotzdem eintragen will, braucht ein max-age von mindestens einem Jahr, includeSubDomains, preload und HTTPS auf jeder Subdomain; erhöhen Sie max-age zuerst schrittweise.

Zwei Domains gegen die Regeln von hstspreload.orgaufgezeichnet 24. Oktober 2026 · zur Information

github.comauf der Preload-Liste

  • Gültiges Zertifikat
  • zuerst http:// auf https:// auf demselben Hosthttp://github.com → https://github.com/
  • www auch über HTTPS
  • max-age von 31536000 oder mehrmax-age=31536000
  • includeSubDomains
  • preload
  • HSTS auch auf seiner https://-Weiterleitung

mozilla.orgnicht auf der Liste

  • Gültiges Zertifikat
  • zuerst http:// auf https:// auf demselben Host302 → https://mozilla.org:443/
  • www auch über HTTPS
  • max-age von 31536000 oder mehrmax-age=60
  • includeSubDomains
  • preload · nicht gesendet
  • HSTS auch auf seiner https://-Weiterleitung

max-age erhöhen, wie hstspreload.org es vorschlägt

  1. 3005 Min. · zum Testen
  2. 6048007 Tage
  3. 259200030 Tage
  4. 31536000365 Tage · das Preload-Minimum

Keines der Ergebnisse ist ein Fehler: hstspreload.org sagt, Preloading sei für die meisten Websites nicht empfohlen, und HSTS ohne Preload schützt jeden Besucher nach seinem ersten Besuch.

Was bewirkt eine Content-Security-Policy?

Eine Content-Security-Policy listet auf, woher eine Seite Skripte, Stile, Bilder und Frames laden darf, sodass ein Skript, das ein Angreifer von anderswo einschleust, nicht läuft. Ihre Direktive frame-ancestors bestimmt auch, wer die Seite einbetten darf, und überschreibt X-Frame-Options (CSP Level 3).

'unsafe-inline' in script-src hebt den größten Teil dieses Schutzes auf, weshalb das Observatory dafür 20 Punkte abzieht; nutzen Sie stattdessen Nonces oder Hashes (steht eines davon in der Liste, ignorieren Browser 'unsafe-inline'). Ein Header Content-Security-Policy-Report-Only blockiert nichts, er meldet nur, und ist damit der sichere Weg, eine neue Richtlinie zuerst auszuprobieren.

Eine CSP, Direktive für Direktivegithub.com und www.mozilla.org · 24. Oktober 2026

github.com

default-srcalles, was unten nicht aufgeführt ist'none'
base-uridas <base href> der Seite'self'
script-srcwoher Skripte geladen werden dürfengithub.githubassets.com 'sha256-6AKuI+cDd1MoUL1u4eqrA9PXmnPAkOB4h7421hPUUm0='
style-srcStylesheets'unsafe-inline' github.githubassets.com
img-srcBilder'self' data: blob: github.githubassets.com media.githubusercontent.com camo.githubusercontent.com …
frame-ancestorswer diese Seite einbetten darf'none'
form-actionwohin Formulare senden dürfen'self' github.com gist.github.com copilot-workspace.githubnext.com …
script-src bei www.mozilla.org'self' 'unsafe-eval' 'unsafe-inline' *.google-analytics.com *.googletagmanager.com google-analytics.com …
github.com beginnt mit default-src 'none' und erlaubt jede Quelle namentlich. Steht ein Nonce oder Hash in der Liste, ignorieren Browser 'unsafe-inline'; das Observatory zählt es dann auch nicht.

Cache-Control erklärt: wie lange darf eine Kopie wiederverwendet werden?

So viele Sekunden, wie ihr max-age angibt: Cache-Control sagt Browsern und CDNs, wie lange sie eine Antwort wiederverwenden dürfen, ohne den Server erneut zu fragen, und s-maxage legt eine eigene Lebensdauer für gemeinsame Caches wie CDNs fest (RFC 9111).

no-cache heißt nicht „nicht zwischenspeichern“: Es heißt speichern, aber vor jeder Wiederverwendung beim Server nachfragen; no-store hält die Antwort aus jedem Cache heraus. Der Header Age sagt, wie alt die Kopie eines CDN schon ist, und ohne jedes Cache-Control darf ein Browser eine Lebensdauer von etwa 10 % der Zeit seit Last-Modified schätzen.

Wie lange eine Kopie frisch bleibtwww.wikipedia.org · aufgezeichnet 24. Oktober 2026

Cache-Control: s-maxage=86400, must-revalidate, max-age=3600

Gemeinsame Caches (CDN)s-maxage=86400 · 24 Std.noch 21 Std., 39 Min.

Browsermax-age=3600 · 1 Std.veraltet

no-storenie in einen Cache schreiben
no-cachespeichern, aber vor jeder Wiederverwendung den Server fragen
max-age=NN Sekunden frisch (Expires wird dann ignoriert)
s-maxage=Ndasselbe, nur für gemeinsame Caches
privatenur Browser, nie ein CDN
immutablebeim Neuladen nicht neu validieren (Chrome ignoriert es)
Die CDN-Kopie war schon 2 Std., 20 Min. alt, als sie uns erreichte, über der Browser-Lebensdauer von 1 Std.: Ein Browser, der sie bekommt, muss beim Server nachfragen (eine ETag-Anfrage), bevor er sie wiederverwendet.

Welche HTTP-Header sind veraltet?

X-XSS-Protection, Expect-CT, Public-Key-Pins, Feature-Policy und P3P tun in aktuellen Browsern nichts Nützliches mehr. X-XSS-Protection sollte 0 sein oder fehlen, weil der alte Filter selbst Lücken öffnen konnte (OWASP).

Versionsnummern in Server und jeder X-Powered-By-Header sind nicht veraltet, aber RFC 9110 und OWASP raten beide davon ab: Sie verraten Angreifern, welche bekannten Fehler sie versuchen sollten (RFC 9110 §10.2.4).

Header, die Sie löschen könnenOWASP · Chromium · RFC 9110
X-XSS-Protection: 1; mode=block

0 senden oder nichts

Chrome 78 und Safari 15.4 haben ihre XSS-Filter entfernt; Firefox hatte nie einen. github.com und www.google.com senden 0.

Chrome
Expect-CT

entfernen

Seit Chrome 107 veraltet: Certificate Transparency wird ohnehin erzwungen.

Chrome
Public-Key-Pins

entfernen

In Chrome 72 entfernt; kein aktueller Browser unterstützt ihn.

Chrome
Feature-Policy

Permissions-Policy nutzen

Umbenannt: der alte Header ist veraltet.

Chrome
P3P

entfernen

Ein toter Datenschutzstandard, den kein aktueller Browser liest; www.youtube.com sendet noch einen.

YouTube
Server: Apache/2.4.62 (Ubuntu) X-Powered-By: PHP/8.3.12

Version weglassen

Ein erfundenes Beispiel: RFC 9110 und OWASP sagen, dieses Detail hilft nur Angreifern.

Apache

Wie sehe ich HTTP-Header in Chrome oder mit curl?

Öffnen Sie in Chrome die DevTools (F12), wählen Sie Netzwerk, laden Sie neu, klicken Sie die erste Zeile an und öffnen Sie Header. Mit curl gibt curl -sI https://example.com den Antwortkopf aus; mit --http1.1 sehen Sie die Schreibweise des Servers.

Über HTTP/2 und HTTP/3 ist jeder Header-Name per Regel kleingeschrieben (RFC 9113 §8.2.1), daher zeigen die DevTools strict-transport-security, wo der Server vielleicht Strict-Transport-Security geschrieben hat. Dieser Checker liest über HTTP/1.1 und behält den Kopf genau wie gesendet.

Die Header selbst ansehencurl · Chrome DevTools
$ curl -sI --http1.1 https://github.com
HTTP/1.1 200 OK
Date: Sat, 24 Oct 2026 08:19:43 GMT
Content-Type: text/html; charset=utf-8
Vary: X-PJAX, X-PJAX-Container, Turbo-Visit, Turbo-Frame, X-Reques…
content-language: en-US
ETag: W/"6995be88733b84f6fb0c35e84ad1df53"
Cache-Control: max-age=0, private, must-revalidate
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
X-Frame-Options: deny
X-Content-Type-Options: nosniff
…
HeaderVorschauAntwortTiming

DevTools › Netzwerk › die Dokumentzeile › Header. Aktivieren Sie Rohdaten, um die Zeilen wie empfangen zu sehen. Über HTTP/2 kommt jeder Name kleingeschrieben an; --http1.1 zeigt die Schreibweise des Servers.

HTTP-Header-Checker: häufig gestellte Fragen

Was ist eine gute Note für Security Header?

A oder A+ auf der Skala des Mozilla HTTP Observatory: 90 Punkte oder mehr, sodass die Bonusrunde zählt. Eine Website ganz ohne Security Header landet meist bei D oder F; eine, die eine CSP ohne unsichere Quellen, HSTS, Einbettungsschutz und nosniff ergänzt, erreicht 100, und Referrer-Policy, Cookies und die Cross-Origin-Richtlinien heben sie dann über 100 auf A+.

Warum weicht meine Note von securityheaders.com ab?

Sie messen Unterschiedliches. securityheaders.com bewertet vor allem, welche Header vorhanden sind, nach einem Punkteschema, das sein Gründer zuletzt 2023 beschrieb. Wir folgen den veröffentlichten Tests des Mozilla HTTP Observatory, die auch Werte, Cookies und die Weiterleitung auf HTTPS lesen und Boni nur ab 90 zählen. Jedes Ergebnis verlinkt auf den Scan des Hosts von Mozilla selbst, damit Sie vergleichen können.

Können Security Header meine Website kaputt machen?

Ja, zwei davon können es. Eine strenge Content-Security-Policy kann Skripte oder Stile blockieren, die die Website braucht, und HSTS mit includeSubDomains legt jede Subdomain ohne HTTPS lahm. Führen Sie eine neue CSP zuerst als Content-Security-Policy-Report-Only ein, lesen Sie die Berichte und erzwingen Sie sie dann; erhöhen Sie das HSTS-max-age schrittweise, beginnend mit fünf Minuten, bevor Sie sich auf ein Jahr festlegen.

Kann ich HTTP-Header mit einer HEAD-Anfrage prüfen?

Ja: Wählen Sie HEAD im Methodenfeld neben der URL. Der Server sollte mit denselben Headern antworten wie bei GET, nur ohne Body, doch manche Server oder CDNs beantworten HEAD anders, und die Tests, die das HTML lesen, etwa Subresource Integrity, haben keine Seite zum Lesen. GET ist der Standard, weil es genau zeigt, was ein Browser bekommt.

Wird X-XSS-Protection noch gebraucht?

Nein. Kein aktueller Browser hat noch den XSS-Filter, den er steuerte: Chrome hat ihn in Version 78 entfernt, Safari in 15.4, und Firefox hatte nie einen. OWASP rät, X-XSS-Protection: 0 oder nichts zu senden, weil der alte Filter selbst missbraucht werden konnte, und das Mozilla Observatory hat seinen Test 2024 gestrichen. Eine Content-Security-Policy stoppt heute eingeschleuste Skripte.

Was bewirkt X-Content-Type-Options: nosniff?

Es sagt dem Browser, dem vom Server gesendeten Content-Type zu vertrauen, statt am Inhalt zu raten. Mit nosniff wird ein Skript oder Stylesheet mit falschem Typ blockiert, sodass eine hochgeladene Datei nicht als JavaScript laufen kann. Es ist der einzige gültige Wert, und das Observatory zieht 5 Punkte ab, wenn der Header fehlt oder ungültig ist.

Warum sind Header-Namen in den Chrome DevTools kleingeschrieben?

Weil die Seite über HTTP/2 oder HTTP/3 kam, wo jeder Header-Name kleingeschrieben sein muss (RFC 9113 §8.2.1). Header-Namen unterscheiden nicht zwischen Groß- und Kleinschreibung, es ist also nichts falsch. Über HTTP/1.1 kommt die Schreibweise des Servers an, und die liest dieser Checker, daher sehen Sie für dieselbe Antwort hier Strict-Transport-Security und in den DevTools strict-transport-security.

Wie füge ich Security Header in nginx oder Cloudflare hinzu?

Fügen Sie in nginx im server-Block pro Header eine add_header-Zeile hinzu, mit always, damit auch Fehlerseiten sie bekommen, und laden Sie neu. Bei Cloudflare nutzen Sie eine Response Header Transform Rule oder bei Pages eine _headers-Datei. Prüfen Sie die Website danach hier: Zu jedem fehlgeschlagenen Test in der Security-Ansicht gibt es ein fertiges Snippet für nginx, Apache, IIS, Cloudflare, Vercel, Netlify und Express.

Was ist der Server-Header, und sollte ich ihn verbergen?

Er nennt die Software, die geantwortet hat, etwa nginx oder cloudflare. Ein bloßer Produktname ist harmlos, doch RFC 9110 warnt vor feinkörnigen Details und OWASP empfiehlt, sie zu kürzen, weil eine Versionsnummer wie Apache/2.4.62 Angreifern verrät, welche bekannten Fehler sie versuchen sollten. Entfernen Sie X-Powered-By ganz. Die Server-Ansicht des Checkers zeigt, was beide verraten.

Speichert der Header-Checker die Header oder Cookies?

Nein. Wir rufen die URL von unserem Server ab, zeigen das Ergebnis und behalten es zwei Minuten, damit ein Neuladen oder ein geteilter Link schnell antwortet; danach ist es weg. Cookie-Werte werden nie angezeigt oder gespeichert: Der Checker listet nur den Namen jedes Cookies, die Länge seines Werts und seine Flags. Nichts wird mit Ihnen verknüpft, und die geprüfte Website sieht Ihre Adresse nie.

Ähnliche Website-Tools