HTTP-Header-Prüfer — Kostenlos Online
Analysieren Sie HTTP-Antwort-Header und prüfen Sie die Serversicherheit.
Paste raw HTTP response headers below. Get them by running curl -I https://example.com in your terminal.
Who uses the HTTP-Header-Prüfer?
- Sicherheitsingenieure, die Antwort-Header von Webanwendungen durch Einfügen von curl-Ausgaben für eine schnelle Compliance-Prüfung auditieren.
- DevOps-Ingenieure, die Cache-Control- und CDN-Header-Konfiguration nach dem Deployment verifizieren.
- Webentwickler, die lernen, welche Sicherheits-Header sie zu ihrer Serverkonfiguration hinzufügen sollten.
How the HTTP-Header-Prüfer works
Führen Sie `curl -I https://example.com` in Ihrem Terminal aus (oder kopieren Sie Header aus dem Network-Tab Ihres Browsers) und fügen Sie die Rohausgabe in das Textfeld ein.
Klicken Sie auf „Analyze Headers", um jeden Header gegen einen festen Satz von Sicherheits- und wichtigen Header-Kategorien zu prüfen.
Betrachten Sie die farbcodierte Checkliste: grüner Haken (vorhanden) oder rotes X (fehlt) für jeden der 7 überwachten Sicherheits-Header.
Scrollen Sie zur vollständigen Header-Tabelle unten für jeden gefundenen Header, alphabetisch sortiert und nach Kategorie farbcodiert.
Tips & tricks
- Es gibt kein Live-Abrufen per URL — Sie müssen rohen Header-Text einfügen; der Platzhalter zeigt den genauen `curl -I`-Befehl dafür.
- Es gibt kein aufklappbares Dokumentationspanel — die Sicherheits-Header-Checkliste zeigt nur vorhanden/fehlend mit dem Wert daneben, ziehen Sie also die FAQs unten heran, um zu erfahren, was jeder Header enthalten sollte.
- Das Tool parst die Statuszeile (HTTP/2 200 usw.), falls sie die erste eingefügte Zeile ist, und färbt sie je nach Statuscode-Bereich grün/gelb/rot.
- Die vollständige Header-Tabelle unter der Sicherheits-Checkliste sortiert alphabetisch und hebt Sicherheits-Header grün hervor, andere bekannte Header (content-type, cache-control, etag usw.) in Ihrer Akzentfarbe.
Frequently Asked Questions
Kann ich statt Header einzufügen einfach eine URL eingeben?
Nein — dieses Tool parst nur eingefügten Rohtext. Holen Sie sich die Header zuerst mit `curl -I https://example.com` im Terminal oder kopieren Sie sie aus dem Network-Tab der Browser-DevTools, und fügen Sie die Ausgabe hier ein.
Welche HTTP-Sicherheits-Header prüft dieses Tool?
Sieben Header: Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy und Permissions-Policy. Jeder wird als vorhanden oder fehlend markiert, mit angezeigtem Wert falls vorhanden.
Was ist der Strict-Transport-Security-Header (HSTS)?
HSTS weist Browser an, für Ihre Domain immer HTTPS zu verwenden. Empfohlen: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. Die preload-Direktive meldet Sie für Browser-HSTS-Preload-Listen zum maximalen Schutz an.
Wovor schützt Content-Security-Policy (CSP)?
CSP verhindert XSS-Angriffe (Cross-Site Scripting), indem festgelegt wird, welche Quellen für Skripte, Stile, Bilder und andere Ressourcen erlaubt sind. Eine strikte CSP ist eine der wirksamsten Abwehrmaßnahmen gegen Injection-Angriffe.
Wie funktionieren Cache-Control-Header?
Cache-Control: max-age=31536000 weist Browser an, die Ressource 1 Jahr lang zu cachen. no-cache bedeutet Revalidierung mit dem Server vor Verwendung der gecachten Kopie. no-store bedeutet niemals cachen. Verwenden Sie für statische Assets mit gehashten Dateinamen einen langen max-age. Für HTML verwenden Sie no-cache.
Is my data safe when using the HTTP-Header-Prüfer?
Completely safe. The HTTP-Header-Prüfer processes everything locally in your browser. No input data, results, or usage information is ever transmitted to or stored on any server.
How current is the data returned by the HTTP-Header-Prüfer?
The HTTP-Header-Prüfer fetches live data in real time each time you run it. Results reflect the current state of the server or domain at the moment of the request.
Why does the HTTP-Header-Prüfer sometimes return different results than other tools?
Results depend on the real-time state of the target server and DNS propagation, which can vary by geographic region and caching TTL. If you see inconsistencies, wait a few minutes and re-test — DNS changes can take up to 48 hours to propagate fully worldwide.