HTTP-Header-Prüfer
Kostenloser HTTP-Header-Prüfer für jede URL. Untersuchen Sie Server-, Cache-, Sicherheits- (HSTS, CSP, X-Frame-Options) und Performance-Header für Sicherheits- und Test-Reviews.
Was ist ein HTTP-Header-Prüfer?
Ein HTTP-Header-Prüfer öffnet eine reale HTTP- oder HTTPS-Verbindung zu einer URL und liest die Antwort-Header zurück, die der Server tatsächlich bereitstellt. HTTP-Header sind die Metadatenschicht des Protokolls (RFC 7230 bis 7237) und tragen eine überraschend große Menge des Serververhaltens: wie Inhalte zwischengespeichert werden, welche Inhaltstypen zulässig sind, welche Cross-Origin-Richtlinie gilt und, wichtig, welche Sicherheits-Header gesetzt sind.
Sicherheits-Header sind der Teil, der die meisten Menschen interessiert. HSTS hält eine Website bei HTTPS, CSP schränkt ein, welche Skripte ausgeführt werden können, X-Frame-Options blockiert Clickjacking, und einige weitere schützen vor MIME-Sniffing, Referrer-Lecks und Protokoll-Downgrade. Dieses Tool sendet die Anfrage, liest die Antwort, bewertet den Sicherheits-Header-Satz anhand von OWASP- und Mozilla-Leitlinien und zeigt die restlichen Header an, damit Sie sie prüfen können.
Was sind HTTP-Header?
HTTP-Header sind grundlegende Bestandteile der Web-Kommunikation und dienen als Metadaten, die steuern, wie Browser und Server interagieren. Unser HTTP-Header-Prüfer konzentriert sich auf Antwort-Header, die die Serverkonfiguration, Sicherheitslage und Einstellungen zur Inhaltsbereitstellung offenbaren. Antwort-Header umfassen Sicherheitsdirektiven (HSTS, CSP, X-Frame-Options), Caching-Richtlinien (Cache-Control, ETag), Inhaltsspezifikationen (Content-Type, Content-Length) und Serverinformationen (Server, X-Powered-By).
HTTP-Header funktionieren identisch in HTTP- (Port 80) und HTTPS-Verbindungen (Port 443), aber HTTPS fügt TLS/SSL-Verschlüsselung (RFC 8446) hinzu, die Header vor dem Abfangen während der Übertragung schützt. HTTPS ist für Sicherheits-Header wie HSTS unerlässlich, die speziell HTTPS-Verbindungen für ihre Funktion erfordern. Es unterstützt beide Protokolle und verarbeitet die TLS/SSL-Verschlüsselung für HTTPS- Verbindungen automatisch, um eine genaue Header-Analyse unabhängig vom Protokoll zu gewährleisten.
Wie die HTTP-Header-Analyse funktioniert
Die HTTP-Header-Analyse umfasst das Herstellen von Netzwerkverbindungen, das Abrufen von HTTP-Antworten, das Analysieren von Header-Daten und das Auswerten von Sicherheitskonfigurationen. Dieser Prüfer verwendet maßgebliche Methoden, die auf Internet-Standards basieren, um genaue Header-Informationen bereitzustellen:
1. Verbindungsaufbau und DNS-Auflösung
Das Tool löst den Ziel-Domainnamen mithilfe von DNS-Abfragen (A/AAAA-Einträge gemäß RFC 1035) in eine IP-Adresse auf und stellt dann eine TCP-Verbindung zu Port 80 (HTTP) oder Port 443 (HTTPS) her. Für HTTPS- Verbindungen führt das Tool einen TLS-Handshake gemäß RFC 8446 durch, um eine verschlüsselte Verbindung herzustellen, bevor HTTP-Anfragen gesendet werden.
Wandelt Domainnamen mithilfe von DNS-Abfragen (A/AAAA-Einträge) gemäß RFC 1035 in IP-Adressen um.
Stellt eine TCP-Verbindung zu Port 80 (HTTP) oder Port 443 (HTTPS) für die HTTP-Kommunikation her.
Führt den TLS/SSL-Handshake gemäß RFC 8446 für HTTPS-Verbindungen durch, um eine verschlüsselte Kommunikation herzustellen.
Erkennt automatisch das HTTP- oder HTTPS-Protokoll aus der URL und verarbeitet den entsprechenden Verbindungstyp.
Unterstützt sowohl IPv4- als auch IPv6-Adressen. Bei IP-Adressen fügt das Tool automatisch das http://-Protokoll hinzu und versucht die Verbindung herzustellen. Schlägt HTTP fehl, wird automatisch HTTPS als Fallback versucht, um maximale Kompatibilität zu gewährleisten.
Die SSL-Zertifikatsprüfung ist absichtlich deaktiviert, damit Sie Header auf Servern mit selbstsignierten oder anderweitig ungültigen Zertifikaten prüfen können. Wenn Sie das Zertifikat selbst bewerten möchten, verwenden Sie stattdessen den SSL-Zertifikat-Prüfer.
Anfragen haben ein 15-Sekunden-Timeout, um unbegrenztes Warten zu verhindern. Wenn ein Server innerhalb dieser Zeitspanne nicht antwortet, wird die Verbindung mit einer entsprechenden Fehlermeldung beendet.
2. HTTP-Anfrageübertragung
Das Tool sendet eine HTTP-Anfrage (in der Regel per GET- oder HEAD-Methode) an den Zielserver, einschließlich Standard-Anfrage-Header wie Host, User-Agent, Accept und Connection. Der Server verarbeitet die Anfrage und generiert eine HTTP-Antwort mit Statuscodes, Antwort-Headern und optionalem Antwort-Body-Inhalt.
Sendet HTTP-Anfragen per GET- oder HEAD-Methode, um Antwort-Header effizient abzurufen. Die HEAD-Methode wird bevorzugt, wenn nur Header benötigt werden, da der Antwort-Body nicht heruntergeladen wird, was schneller und bandbreiteneffizienter ist.
Sendet browserähnliche Anfrage-Header einschließlich User-Agent (Chrome), Accept, Accept-Language, Accept-Encoding, Upgrade-Insecure-Requests, Sec-Fetch-*-Header, Cache-Control und Connection, um reales Browserverhalten nachzuahmen und einen genauen Header-Abruf zu gewährleisten.
Empfängt die HTTP-Antwort mit Statuscodes, Antwort-Headern und optionalem Antwort-Body-Inhalt.
Behandelt Verbindungs-Timeouts, DNS-Fehler und HTTP-Fehler mit entsprechenden Fehlermeldungen und geordnetem Abbau.
3. Header-Analyse und Sicherheitsprüfung
Die abgerufenen HTTP-Antwort-Header werden analysiert und in Sicherheits-Header, Caching- Header, Inhalts-Header, Serverinformations-Header, CORS-Header und benutzerdefinierte Header kategorisiert. Jeder Header wird auf Syntaxkonformität gemäß RFC 7230-7237 geprüft, und Sicherheits-Header werden anhand der Empfehlungen des OWASP Secure Headers Project und der Mozilla-Sicherheitsrichtlinien analysiert.
Analysiert HTTP-Antwort-Header gemäß RFC 7230-7237 und extrahiert Header-Namen und -Werte.
Ordnet Header in Kategorien ein: Sicherheit, Inhalt, Cache, Serverinformationen, CORS und benutzerdefinierte Header.
Erkennt moderne Header-Alternativen, z. B. CSP frame-ancestors als Ersatz für X-Frame-Options. Das Tool analysiert sowohl traditionelle als auch moderne Header und bevorzugt moderne Implementierungen, wenn beide vorhanden sind.
Validiert die Header-Syntax auf Konformität mit HTTP-Standards gemäß RFC 7230-7237.
Analysiert Sicherheits-Header anhand der Empfehlungen des OWASP Secure Headers Project und der Mozilla-Sicherheitsrichtlinien.
Identifiziert fehlende Sicherheits-Header, die auf potenzielle Schwachstellen und Sicherheitslücken hinweisen.
So verwenden Sie den HTTP-Header-Prüfer
Unser HTTP-Header-Prüfer ist für Nutzer aller technischen Niveaus konzipiert. Folgen Sie diesem einfachen Prozess:
-
Schritt 1: Geben Sie einen Domainnamen (z. B. example.com), eine vollständige URL (z. B. https://example.com) oder eine IP-Adresse (IPv4 wie 192.168.1.1 oder IPv6 wie 2001:db8::1) ein. Das Tool erkennt automatisch den Eingabetyp und das Protokoll. Bei Domains ohne Protokoll wird standardmäßig HTTPS verwendet. Bei IP-Adressen wird zunächst HTTP versucht, mit HTTPS als Fallback, wenn HTTP fehlschlägt.
-
Schritt 2: Vervollständigen Sie die CAPTCHA-Verifizierung, um eine sichere Nutzung zu gewährleisten und automatisierten Missbrauch zu verhindern.
- Schritt 3: Klicken Sie auf die Schaltfläche „HEADER PRÜFEN“. Das Tool stellt eine HTTP-Verbindung her und ruft die Header ab.
Die Ergebnisse umfassen vollständige HTTP-Antwort-Header, geordnet nach Kategorien (Sicherheit, Inhalt, Cache, Server- informationen, CORS, Benutzerdefiniert), eine Sicherheits-Header-Analyse zum Vergleich der Konfigurationen mit OWASP-Empfehlungen, die Identifizierung fehlender Sicherheits-Header und detaillierte Sicherheitsempfehlungen. Sie können Header in geordneten Abschnitten anzeigen, Sicherheitskonfigurationen analysieren, Header-Werte kopieren oder vollständige Ergebnisse in JSON, CSV oder TXT exportieren.
Was sind kritische Sicherheits-Header?
Sicherheits-Header sind HTTP-Antwort-Header, die Websites und Nutzer vor verschiedenen Angriffen schützen. Das Verständnis dieser Header ist entscheidend für die Aufrechterhaltung sicherer Web-Anwendungen:
HTTP Strict Transport Security (HSTS)
Header:
Strict-Transport-Security (RFC 6797)Zweck: Zwingt Browser zur Verwendung von HTTPS-Verbindungen und verhindert so Protokoll-Downgrade-Angriffe und Man-in-the-Middle-Angriffe.
Beispiel:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Fehlende HSTS ermöglicht es Angreifern, HTTPS-Verbindungen auf HTTP herunterzustufen und sensible Daten abzufangen. HSTS stellt sicher, dass alle Verbindungen Verschlüsselung verwenden, und schützt so Nutzeranmeldedaten und persönliche Informationen.
Content Security Policy (CSP)
Header: Content-Security-Policy (RFC 7762)
Zweck: Mildert Cross-Site-Scripting (XSS)-Angriffe, indem gesteuert wird, welche Ressourcen geladen und ausgeführt werden können.
Beispiel: Content-Security-Policy: default-src 'self'; script-src 'self'
Fehlende CSP macht Websites anfällig für XSS-Angriffe und ermöglicht es Angreifern, bösartige Skripte einzuschleusen. CSP schränkt das Laden von Ressourcen ein und verhindert so unautorisierte Skriptausführung.
X-Frame-Options
Header:
X-Frame-Options (RFC 7034)Zweck: Verhindert Clickjacking-Angriffe, indem gesteuert wird, ob Seiten in Frames angezeigt werden können.
Werte:
DENY (kein Einbetten), SAMEORIGIN (nur gleicher Ursprung)Beispiel:
X-Frame-Options: DENY
Fehlendes X-Frame-Options ermöglicht es Angreifern, Seiten in bösartige Frames einzubetten und Nutzer dazu zu verleiten, auf versteckte Elemente zu klicken.
X-Content-Type-Options
Header:
X-Content-Type-Options: nosniffZweck: Verhindert MIME-Type-Sniffing-Angriffe, indem Browser gezwungen werden, deklarierte Inhaltstypen zu respektieren.
Das Fehlen dieses Headers ermöglicht es Browsern, Inhaltstypen zu erraten und möglicherweise bösartige Inhalte als Skripte auszuführen. Die nosniff-Direktive stellt sicher, dass Browser deklarierte MIME-Typen respektieren.
Referrer-Policy
Header: Referrer-Policy
Zweck: Steuert, wie viele Referrer-Informationen mit Anfragen geteilt werden, und schützt so die Privatsphäre der Nutzer.
Beispiel: Referrer-Policy: strict-origin-when-cross-origin
Steuert die Weitergabe von Referrer-Informationen und verhindert so, dass sensible URL-Parameter an Drittanbieter-Websites weitergegeben werden.
X-XSS-Protection (Veraltet)
Header: X-XSS-Protection
Status: Veraltet - moderne Browser haben die XSS-Filterung entfernt
Zweck: Diente zur Aktivierung der Browser-XSS-Filterung, diese Funktion wurde jedoch aus modernen Browsern entfernt.
Moderne Alternative: Content-Security-Policy (CSP) bietet überlegenen XSS-Schutz.
Verlassen Sie sich nicht auf X-XSS-Protection. Implementieren Sie stattdessen eine strikte Content-Security-Policy. CSP ist der moderne Weg, Cross-Site-Scripting zu blockieren, und gibt Ihnen eine detaillierte Kontrolle darüber, welche Quellen Skripte im Browser ausführen können.
Expect-CT (Veraltet)
Header: Expect-CT
Status: Veraltet (RFC 9163) - ersetzt durch Certificate-Transparency-Überwachung
Zweck: Diente zur Erkennung falsch ausgestellter SSL-Zertifikate über Certificate-Transparency-Protokolle.
Hinweis: Dieser Header ist veraltet und sollte nicht verwendet werden. Moderne Zertifikatsüberwachung verwendet Certificate-Transparency-Protokolle direkt.
Implementieren Sie Expect-CT nicht. Verwenden Sie stattdessen Certificate-Transparency-Überwachungsdienste oder Tools, die CT-Protokolle direkt für die Zertifikatsüberwachung und Sicherheit abfragen.
Bewertungssystem für Sicherheits-Header
Die Sicherheitsbewertung ist ein 100-Punkte-Score, inspiriert von securityheaders.com. Jeder Header wird auf Vorhandensein, Konfigurationsqualität und Übereinstimmung mit aktuellen Best Practices geprüft:
Maximal 25 Punkte. Grundpunktzahl für Vorhandensein (6 Punkte), Bonus für max-age ≥ 1 Jahr (bis zu 20 Punkte), includeSubDomains-Direktive (+3 Punkte) und preload-Direktive (+2 Punkte). Eine ausgezeichnete Konfiguration mit max-age ≥ 31536000, includeSubDomains und preload erhält die vollen 25 Punkte.
Maximal 25 Punkte. Grundpunktzahl für Vorhandensein (12 Punkte), Bonus für default-src-Direktive (+4 Punkte), script-src-Direktive (+3 Punkte) und Nonce/Hash-Verwendung (+6 Punkte). Abzüge für unsafe-inline (-3 Punkte) und unsafe-eval (-2 Punkte). Eine ausgezeichnete CSP mit strengen Richtlinien erhält bis zu 25 Punkte.
Maximal 12 Punkte. DENY erhält 12 Punkte, SAMEORIGIN erhält 10 Punkte. CSP frame-ancestors wird ebenfalls als moderne Alternative anerkannt und erhält 12 Punkte. Fehlen beide, werden 0 Punkte vergeben.
Maximal 12 Punkte. Korrekte Konfiguration mit „nosniff“ ergibt 12 Punkte. Fehlend oder falsch konfiguriert ergibt 0 bis 5 Punkte.
Maximal 13 Punkte. Korrekte Konfiguration mit standardmäßigen Richtlinienwerten ergibt 13 Punkte. Strengere Richtlinien (strict-origin, strict-origin-when-cross-origin, same-origin, no-referrer) werden bevorzugt.
Maximal 13 Punkte. Grundpunktzahl für Vorhandensein (5 Punkte), Bonus für eingeschränkte Funktionen (bis zu 8 Punkte). Mehr eingeschränkte Funktionen weisen auf eine bessere Sicherheitskonfiguration hin.
Bewertungsskala für Sicherheits-Header im Detail erklärt
Wir glauben an Transparenz. Wenn Sie verstehen, wie Ihre Sicherheits-Header-Konfiguration in eine Bewertung umgerechnet wird, können Sie fundierte Entscheidungen zur Sicherheitslage Ihrer Website treffen. Hier ist die detaillierte Aufschlüsselung unseres Bewertungssystems:
Sicherheits-Header-Bewertungen (7 Stufen)
Nahezu perfekte Sicherheits-Header-Konfiguration. Alle kritischen Sicherheits-Header sind vorhanden und mit optimalen Einstellungen korrekt konfiguriert. HSTS enthält max-age ≥ 1 Jahr, includeSubDomains und preload. CSP verwendet strenge Richtlinien mit Nonces/Hashes und keine unsicheren Direktiven. Alle anderen Header sind optimal konfiguriert. Diese Bewertung weist auf eine Sicherheits-Header-Implementierung auf Unternehmensebene hin.
Ausgezeichnete Sicherheits-Header-Konfiguration mit geringfügigen Verbesserungsmöglichkeiten. Die meisten kritischen Header sind vorhanden und gut konfiguriert. Möglicherweise bestehen geringfügige Mängel wie CSP ohne Nonces/Hashes, HSTS ohne preload oder kleinere Konfigurationsoptimierungen. Diese Bewertung weist auf eine robuste Implementierung hin, die für Produktionsumgebungen geeignet ist.
Gute Sicherheits-Header-Konfiguration mit Verbesserungspotenzial. Die meisten Sicherheits-Header sind vorhanden, können aber suboptimale Konfigurationen aufweisen. Häufige Probleme sind CSP mit unsafe-inline oder unsafe-eval Direktiven, HSTS mit unzureichendem max-age oder fehlende empfohlene Header wie Permissions-Policy. Diese Bewertung weist auf akzeptable Sicherheit hin, erfordert jedoch Optimierung für besseren Schutz.
Ausreichende Sicherheits-Header-Konfiguration mit erheblichen Lücken. Einige kritische Header fehlen möglicherweise oder sind falsch konfiguriert. Häufige Probleme sind fehlende CSP, schwache HSTS-Konfiguration oder fehlende X-Frame-Options/X-Content-Type-Options. Diese Bewertung weist darauf hin, dass grundlegende Sicherheitsmaßnahmen vorhanden sind, aber kritische Verbesserungen zum Schutz gegen gängige Web-Angriffe erforderlich sind.
Schlechte Sicherheits-Header-Konfiguration mit erheblichen Sicherheitslücken. Mehrere kritische Header fehlen oder sind falsch konfiguriert. Websites mit dieser Bewertung sind anfällig für gängige Angriffe wie XSS, Clickjacking und Protokoll-Downgrade-Angriffe. Sofortige Maßnahmen sind erforderlich, um fehlende Sicherheits-Header zu implementieren und Konfigurationen zu verbessern.
Sehr schlechte Sicherheits-Header-Konfiguration mit kritischen Sicherheitslücken. Die meisten Sicherheits-Header fehlen oder sind erheblich falsch konfiguriert. Websites mit dieser Bewertung sind äußerst anfällig für Angriffe und sollten nicht ohne sofortige Implementierung von Sicherheits-Headern in der Produktion eingesetzt werden. Diese Konfiguration stellt ein erhebliches Sicherheitsrisiko für Nutzer dar.
Katastrophale Sicherheits-Header-Konfiguration mit minimalem oder keinem Schutz. Kritische Sicherheits-Header fehlen vollständig oder sind erheblich falsch konfiguriert. Websites mit dieser Bewertung sind extrem anfällig und sollten nicht in der Produktion eingesetzt werden. Die sofortige Implementierung aller kritischen Sicherheits-Header ist vor dem Livegang erforderlich.
Best Practices für Sicherheits-Header
Die korrekte Implementierung von Sicherheits-Headern ist entscheidend für den Schutz von Websites und Nutzern vor Angriffen. Dieser Abschnitt enthält Best Practices basierend auf OWASP-Empfehlungen und identifiziert häufige Fehlkonfigurationen:
Implementieren Sie HSTS immer mit einem geeigneten max-age (mindestens 31536000 Sekunden für ein Jahr) und der includeSubDomains-Direktive. Fehlende HSTS macht Websites anfällig für Protokoll-Downgrade-Angriffe.
Implementieren Sie strikte CSP-Richtlinien, die das Laden von Ressourcen nur von vertrauenswürdigen Quellen erlauben. Verwenden Sie default-src 'self' als Basis und vermeiden Sie nach Möglichkeit 'unsafe-inline' und 'unsafe-eval'. Schwache CSP-Richtlinien mit diesen Direktiven bieten minimalen Schutz gegen XSS-Angriffe.
Verwenden Sie DENY, um jegliches Einbetten zu verhindern, oder SAMEORIGIN, um nur Same-Origin-Einbetten zu erlauben. Alternativ verwenden Sie die Content-Security-Policy-Direktive frame-ancestors (z. B. frame-ancestors 'none' oder frame-ancestors 'self'), die den modernen Ersatz für X-Frame-Options darstellt. CSP frame-ancestors bietet eine feinere Kontrolle und wird X-Frame-Options vorgezogen. Fehlendes X-Frame-Options oder CSP frame-ancestors macht Websites anfällig für Clickjacking-Angriffe.
Setzen Sie diesen Header immer auf nosniff, um MIME-Type-Sniffing-Angriffe zu verhindern. So stellen Sie sicher, dass Browser deklarierte Inhaltstypen respektieren und Inhaltstyp-Verwechslungsangriffe verhindert werden.
Entfernen oder minimieren Sie den Server-Header, um Informationspreisgabe zu verhindern. Die Offenlegung von Serversoftware und Versionsinformationen (z. B. Server: nginx/1.18.0) hilft Angreifern, Schwachstellen zu identifizieren und gezielte Angriffe zu planen.
Entfernen Sie den X-Powered-By-Header, um die Offenlegung des Anwendungs-Frameworks zu verhindern. Die Preisgabe von Framework-Informationen (PHP, Express usw.) hilft Angreifern, framework-spezifische Schwachstellen zu identifizieren. Entfernen Sie diesen Header in Produktionsumgebungen.
Überprüfen Sie benutzerdefinierte X-*-Header auf Informationspreisgabe. Benutzerdefinierte Header können interne Anwendungsdetails, API-Endpunkte oder Systemarchitekturinformationen offenbaren. Entfernen oder bereinigen Sie Header, die vertrauliche Informationen preisgeben.
Implementieren Sie eine angemessene Referrer-Policy zum Schutz der Privatsphäre der Nutzer. Verwenden Sie strict-origin-when-cross-origin für ein ausgewogenes Verhältnis zwischen Datenschutz und Funktionalität oder no-referrer für maximalen Datenschutz. So wird verhindert, dass sensible URL-Parameter an Drittanbieter-Websites weitergegeben werden.
Verwenden Sie geeignete Cache-Direktiven: no-store für sensible Inhalte, public, max-age=3600 für statische Ressourcen und private für nutzerspezifische Inhalte. Falsch konfigurierte Cache-Control-Header können Sicherheitsprobleme (Zwischenspeicherung sensibler Inhalte) oder Leistungsprobleme verursachen.
Häufige Anwendungsfälle des HTTP-Header-Prüfers
Die häufigsten Gründe, warum Nutzer einen Header-Prüfer verwenden:
Überprüfen Sie die Implementierung der Sicherheits-Header auf Konformität mit OWASP-Empfehlungen, PCI-DSS-Anforderungen und Sicherheitsstandards. Identifizieren Sie fehlende Sicherheits-Header, die auf potenzielle Schwachstellen hinweisen, und bewerten Sie die Sicherheitslage für das Risikomanagement.
Analysieren Sie Caching-Header (Cache-Control, ETag, Expires), um die Inhaltsbereitstellung zu optimieren und die Serverlast zu reduzieren. Identifizieren Sie Fehlkonfigurationen beim Caching, die die Leistung beeinträchtigen, und optimieren Sie Cache-Richtlinien für eine bessere Nutzererfahrung.
Beheben Sie CORS-Probleme, indem Sie Access-Control-Allow-Origin-Header und zugehörige CORS-Direktiven analysieren. Identifizieren Sie CORS-Fehlkonfigurationen, die den API-Zugriff verhindern, und überprüfen Sie CORS-Richtlinien auf Sicherheitskonformität.
Überprüfen Sie die Serversoftware-Identifikation, analysieren Sie benutzerdefinierte Anwendungs-Header und identifizieren Sie Schwachstellen bei der Informationspreisgabe. Überprüfen Sie Server-Header-Konfigurationen auf Best Practices für die Sicherheit.
Funktionen und Möglichkeiten
Was Sie erhalten, an einem Ort. Nützlich für technische Fachleute und nicht-technische Nutzer gleichermaßen:
Unterstützt sowohl HTTP- (Port 80) als auch HTTPS-Verbindungen (Port 443) mit ordnungsgemäßer TLS/SSL-Verarbeitung gemäß RFC 8446, um Kompatibilität mit allen Webservern zu gewährleisten.
Stellt Live-HTTP-Verbindungen her, um aktuelle Header-Informationen direkt von Zielservern abzurufen und stets aktuelle und genaue Header-Daten zu gewährleisten.
Analysiert Sicherheits-Header anhand der Empfehlungen des OWASP Secure Headers Project und der Mozilla-Sicherheitsrichtlinien, identifiziert fehlende Header und gibt Sicherheitsempfehlungen.
Ordnet Header in logische Kategorien (Sicherheit, Inhalt, Cache, Serverinformationen, CORS, Benutzerdefiniert) ein, um die Analyse und das Verständnis zu erleichtern.
Ermöglicht den Export von Header-Informationen in JSON (RFC 8259), CSV und TXT für Dokumentation, Analyse und Integration in andere Systeme.
Alle Header-Prüfungen erfolgen in Echtzeit ohne Datenspeicherung, sodass Ihre Header-Informationen privat und sicher bleiben. Wir speichern oder protokollieren weder Domainnamen, URLs, Header noch Suchergebnisse.
Häufig gestellte Fragen (FAQ)
Die Header-Prüfung zeigt, was der Server seinen Clients tatsächlich mitteilt: welche Sicherheits-Header gesetzt sind (und wie streng), die Caching-Richtlinie, den deklarierten Inhaltstyp, Server-Identifikationsbanner, CORS-Regeln und alle benutzerdefinierten Anwendungs-Header. Nützlich zum Erkennen von Sicherheitslücken, zum Debuggen des Cache-Verhaltens, zur Fehlersuche bei einem falsch konfigurierten CDN und zum Bestätigen der Header, die Ihr Compliance-Programm erwartet.
Sicherheits-Header schützen Websites und Nutzer vor verschiedenen Angriffen, darunter XSS (Cross-Site-Scripting), Clickjacking, MIME-Type-Sniffing, Protokoll-Downgrade-Angriffe und Man-in-the-Middle-Angriffe. Fehlende Sicherheits-Header weisen auf potenzielle Schwachstellen hin, die Angreifer ausnutzen können. Sicherheits-Header wie HSTS, CSP, X-Frame-Options und X-Content-Type-Options bieten wesentliche Schutzschichten, die gängige Web-Angriffe verhindern und Nutzerdaten schützen.
HTTP-Header funktionieren identisch in HTTP- (Port 80) und HTTPS-Verbindungen (Port 443). HTTPS fügt TLS/SSL-Verschlüsselung (RFC 8446) zu HTTP hinzu und schützt Header-Daten vor dem Abfangen während der Übertragung. Sicherheits-Header wie HSTS sind speziell für HTTPS-Verbindungen konzipiert und zwingen Browser zur Verwendung verschlüsselter Verbindungen. Der Prüfer unterstützt beide Protokolle und verarbeitet die TLS/SSL-Verschlüsselung automatisch.
Nein, unser HTTP-Header-Prüfer speichert keine Domainnamen, URLs, HTTP-Header oder Suchergebnisse in unserer Anwendungsdatenbank. Alle Header-Prüfungen werden ausschließlich für die Dauer Ihrer Anfrage in Echtzeit durchgeführt und sofort verworfen. Standard-Serverzugriffsprotokolle können weiterhin gemäß unserer Datenschutzerklärung erstellt werden.
HTTP-Header können Serversoftware-Versionen, Anwendungs-Frameworks und benutzerdefinierte Anwendungsdetails über Server, X-Powered-By und benutzerdefinierte X-*-Header offenbaren. Diese Informationspreisgabe kann Angreifern helfen, Schwachstellen zu identifizieren und gezielte Angriffe zu planen. Der Prüfer identifiziert Header, die Informationen preisgeben, und empfiehlt deren Entfernung oder Minimierung, um Lecks vertraulicher Informationen zu verhindern.