HTTP-Header-Analysator

HTTP-Header transportieren Metadaten über Anfragen und Antworten. Dieses Tool parst vollständige HTTP-Nachrichten einschließlich Request-/Status-Zeile, Header und Body-Inhalt. Es analysiert Sicherheitsheader (HSTS, CSP), Authentifizierung (Basic, Bearer), Cookies, CORS-Konfiguration und Caching-Direktiven. Body-Inhalte werden automatisch formatiert und syntaxhervorgehoben basierend auf Content-Type (JSON, HTML, XML).

Spezifikationen

• RFC 9110 - HTTP Semantics
• RFC 9111 - HTTP Caching
• MDN HTTP Headers

Haeufige Anwendungsfaelle

• API-Anfragen aus dem Browser-DevTools-Netzwerk-Tab debuggen
• Ausgabe von curl -i oder curl -v mit Headern und Body analysieren
• Sicherheitsheader auf Compliance prüfen (OWASP-Empfehlungen)
• CORS-Preflight- und Cross-Origin-Probleme beheben
• Authentifizierungsheader und Cookie-Konfiguration untersuchen
• Caching-Verhalten für CDN und Browser-Caching überprüfen

Funktionen

• Vollständige HTTP-Anfragen parsen (GET /path HTTP/1.1)
• HTTP-Antworten mit Statuscodes und Begründungen parsen
• Body-Inhalt formatieren und syntaxhervorheben (JSON, HTML, XML, CSS)
• Authorization-Header dekodieren (Basic-Auth-Credentials, Bearer-Tokens)
• Sicherheitsheader analysieren (HSTS, CSP, X-Frame-Options, X-Content-Type-Options)
• Set-Cookie-Attribute parsen (Secure, HttpOnly, SameSite, Ablauf)
• Cookie-Extraktion und -Auflistung aus Headern
• CORS-Header anzeigen (Access-Control-Allow-Origin usw.)
• Cache-Control-Direktiven erklären (max-age, no-cache, private)

Beispiele

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Cache-Control: max-age=3600, public
X-Frame-Options: DENY
Strict-Transport-Security: max-age=31536000; includeSubDomains

{
  "status": "success",
  "data": {
    "id": 12345,
    "name": "Example User"
  }
}

GET /api/users HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Accept: application/json
Cookie: session=abc123; theme=dark

Tipps

• Verwenden Sie "curl -i URL", um Antwort-Header in der Ausgabe einzuschließen.
• In den Browser-DevTools rechtsklicken Sie eine Anfrage und wählen "Als cURL kopieren", um die vollständige Anfrage zu erhalten.
• HSTS (Strict-Transport-Security) weist Browser an, nur HTTPS für die Domain zu verwenden.
• CSP (Content-Security-Policy) steuert, welche Ressourcen die Seite laden darf.
• Das SameSite-Cookie-Attribut hilft, CSRF-Angriffe zu verhindern.

Verstaendnis HTTP-Header-Analysator

HTTP-Header sind Schlüssel-Wert-Paare, die zwischen Client und Server als Teil jeder HTTP-Anfrage und -Antwort gesendet werden. Sie transportieren Metadaten über die Nachricht: Inhaltstyp, Caching-Direktiven, Authentifizierungsdaten und Sicherheitsrichtlinien. Header erscheinen nach der Anfrage- oder Statuszeile und vor dem optionalen Body, getrennt vom Body durch eine Leerzeile.

Anfrage-Header liefern Kontext über den Client und die gewünschte Antwort. Host identifiziert den Zielserver. Accept und Content-Type verhandeln das Medienformat. Authorization transportiert Anmeldedaten (Basic, Bearer, API-Schlüssel). Cookie sendet gespeicherte Sitzungsdaten. User-Agent identifiziert die Client-Software.

Antwort-Header steuern, wie der Client den Inhalt behandelt. Cache-Control und ETag steuern das Caching-Verhalten. Set-Cookie etabliert clientseitigen Zustand. Content-Security-Policy schränkt das Laden von Ressourcen ein, um XSS zu verhindern. Strict-Transport-Security erzwingt HTTPS. CORS-Header (Access-Control-Allow-Origin und verwandte) steuern das Cross-Origin Resource Sharing, einen der am häufigsten fehlkonfigurierten Aspekte von Web-APIs.

Das Verständnis von Headern ist essenziell für das Debuggen von Webanwendungen. Wenn eine API unerwartete Ergebnisse liefert, offenbaren Header oft die Ursache: ein fehlender Content-Type, ein abgelaufenes Authentifizierungstoken, eine Caching-Direktive, die veraltete Daten liefert, oder eine CORS-Richtlinie, die die Anfrage blockiert.

Die Cache-Control-Direktive ist einer der am meisten missverstandenen Header. Die no-cache-Direktive bedeutet nicht "nicht zwischenspeichern" — sie bedeutet, dass der Cache vor der Verwendung einer gespeicherten Antwort beim Ursprungsserver revalidieren muss. Die Antwort kann trotzdem zwischengespeichert werden. Die no-store-Direktive ist das, was tatsächlich das Caching vollständig verhindert, und sie sollte für sensible Daten verwendet werden. Für häufig wechselnde Inhalte, die von bedingten Anfragen profitieren, ist no-cache kombiniert mit ETag oder Last-Modified die geeignete Strategie.

CORS-Fehler treten auf, wenn eine Browser-Anfrage an einen anderen Origin den Antwort-Header Access-Control-Allow-Origin vermisst. Der Server muss diesen Header mit entweder dem anfragenden Origin oder * für öffentliche APIs einschließen. Wenn Anmeldedaten (Cookies oder Authorization-Header) beteiligt sind, ist der Platzhalter nicht erlaubt — der Header muss den exakten Origin angeben. Preflight-OPTIONS-Anfragen erfordern zusätzlich Access-Control-Allow-Methods und Access-Control-Allow-Headers. Bearer-Token-Authentifizierung verwendet das Format Authorization: Bearer <token>, wobei das Token typischerweise ein JWT oder undurchsichtiges Access-Token aus einem OAuth-2.0-Flow ist. Im Gegensatz zu Cookies werden Bearer-Tokens nicht automatisch gesendet — der Client muss den Header explizit an jede Anfrage anhängen.

Jede Website sollte einen Mindestsatz an Sicherheitsheadern setzen. Strict-Transport-Security (HSTS) stellt sicher, dass immer HTTPS verwendet wird. Content-Security-Policy verhindert XSS, indem das Laden von Ressourcen eingeschränkt wird. X-Content-Type-Options: nosniff verhindert MIME-Typ-Sniffing. X-Frame-Options schützt vor Clickjacking, und Referrer-Policy steuert, welche Informationen im Referer-Header gesendet werden. APIs sollten zusätzlich geeignete CORS-Header konfigurieren, um zu steuern, welche Origins Anfragen stellen können.