HTTP-Header verständlich erklärt: Was Entwickler wissen müssen

Bei jedem Laden einer Website im Browser, beim Senden von Formulardaten oder beim Abfragen einer API läuft im Hintergrund ein unsichtbarer, aber extrem wichtiger Austausch ab: die Übertragung von HTTP-Headern. Diese Metadaten steuern, wie Client und Server miteinander kommunizieren. Sie definieren Caching-Regeln, Medientypen, Sicherheitsvorgaben, Autorisierungen und vieles mehr. Wer moderne Webanwendungen optimieren, absichern oder Fehler effizient debuggen will, muss die wichtigsten HTTP-Header kennen.

Was sind HTTP-Header überhaupt?

HTTP-Header sind einfache Schlüssel-Wert-Paare (Key-Value Pairs), die dem eigentlichen Inhalt (dem Body) einer HTTP-Anfrage oder -Antwort vorangestellt sind. Sie sind für Endnutzer unsichtbar, liefern aber Browsern, Webservern, CDNs und Proxies essenzielle Anweisungen zur Verarbeitung der Daten. Ein einfacher Zeilenumbruch trennt die Header-Sektion vom eigentlichen Inhalt der Nachricht.

GET /api/v1/users HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
Accept: application/json
Content-Type: application/json
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

Content-Type — Das Datenformat richtig deklarieren

Der Content-Type-Header teilt dem Empfänger mit, um welchen Medientyp (MIME-Typ) es sich bei den gesendeten Daten handelt. Dies betrifft sowohl die Anfrage (was der Client an den Server schickt) als auch die Antwort (was der Server an den Browser zurücksendet).

Content-Type: application/json
Content-Type: application/x-www-form-urlencoded
Content-Type: multipart/form-data
Content-Type: text/html; charset=UTF-8
Content-Type: text/plain
Content-Type: image/webp

Ein falsch konfigurierter Content-Type ist eine der häufigsten Fehlerquellen in der API-Entwicklung. Wenn du JSON-Daten an eine Schnittstelle sendest, den Header aber fälschlicherweise auf text/plain setzt, verweigern viele Server das korrekte Parsing und antworten mit einem Fehler des Typs *415 Unsupported Media Type*.

Cache-Control — Ladezeiten optimieren und Ressourcen schonen

Der Cache-Control-Header gehört zu den wichtigsten Performance-Stellschrauben im Web. Er bestimmt, wie lange und unter welchen Bedingungen Browser und CDNs eine Antwort zwischenspeichern dürfen:

• no-cache — Die Ressource muss vor jeder Verwendung erst beim Server validiert werden.
• no-store — Es darf keinerlei Speicherung im Cache erfolgen (wichtig für sensible Daten).
• max-age=31536000 — Gibt die maximale Speicherdauer in Sekunden an (hier 1 Jahr für statische Assets).
• public — Jede Zwischenstation (Browser, CDN, Proxy-Server) darf diese Antwort cachen.
• private — Nur der Browser des Nutzers darf die Antwort speichern. Ideal bei personalisierten Benutzerdaten.
• immutable — Teilt dem Browser mit, dass sich die Datei während der Cache-Laufzeit niemals ändern wird. Erspart erneute Validierungsanfragen.

Authorization — APIs und Routen absichern

Der Authorization-Header transportiert Anmeldedaten (Credentials), um die Identität des anfragenden Clients zu überprüfen. In modernen Web-Apps dominieren zwei Standards:

• Bearer-Token — Weit verbreitet bei der Verwendung von JSON Web Tokens (JWT) und OAuth 2.0: Authorization: Bearer <token>
• Basic Auth — Benutzername und Passwort werden via Base64 codiert übertragen: Authorization: Basic <base64(user:pass)>

Achtung: Eine Base64-Codierung ist keine Verschlüsselung! Daten im Basic-Auth-Header können spielend leicht ausgelesen werden. Nutze solche Verfahren daher zwingend und ausschließlich über verschlüsselte HTTPS-Verbindungen.

CORS-Header — Domainübergreifende Zugriffe steuern

Cross-Origin Resource Sharing (CORS) ist ein Sicherheitsmechanismus, der festlegt, welche externen Websites (Origins) auf die Ressourcen deiner API zugreifen dürfen. Ohne die passenden CORS-Header blockieren moderne Browser solche clientseitigen Cross-Origin-Anfragen automatisch:

Access-Control-Allow-Origin: https://deine-app.de
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true

Ein typischer Fehler in der Praxis ist die Kombination aus der Wildcard Access-Control-Allow-Origin: * und der Erlaubnis für Cookies via Access-Control-Allow-Credentials: true. Dies ist laut Sicherheitsstandard unzulässig und führt dazu, dass Browser den Zugriff komplett blockieren.

Sicherheits-Header — Deine Web-App vor Angriffen schützen

Mit speziellen HTTP-Antwort-Headern kannst du Sicherheitsrisiken direkt im Browser des Benutzers minimieren und bekannte Angriffsvektoren blockieren:

• Content-Security-Policy (CSP) — Definiert präzise, aus welchen Quellen Skripte, Stylesheets und Bilder geladen werden dürfen. Ein hochwirksamer Schutz gegen Cross-Site Scripting (XSS).
• X-Frame-Options: DENY — Schützt vor Clickjacking, indem verhindert wird, dass deine Website unbefugt in einem <iframe> eingebettet wird.
• Strict-Transport-Security (HSTS) — Erzwingt, dass der Browser die Domain nur noch über verschlüsselte HTTPS-Verbindungen aufruft.
• X-Content-Type-Options: nosniff — Unterbindet das sogenannte MIME-Sniffing, bei dem Browser versuchen, Dateitypen eigenständig und potenziell gefährlich zu interpretieren.
• Referrer-Policy: strict-origin-when-cross-origin — Kontrolliert, wie viele Informationen über die verweisende Seite bei ausgehenden Links übertragen werden.

ETag und Last-Modified — Intelligente Cache-Validierung

Mithilfe der Header ETag und Last-Modified lassen sich bedingte HTTP-Anfragen realisieren. Der Server teilt dem Browser mit: „Diese Version der Datei hat den Hash-Wert X.“ Bei einer erneuten Anfrage sendet der Browser diesen Hash im Header If-None-Match mit zurück. Hat sich die Datei auf dem Server nicht verändert, antwortet dieser einfach mit einem schlanken 304 Not Modified-Status. Es wird kein Response-Body übertragen, was Ladezeiten radikal verkürzt.

Accept-Encoding — Komprimierung für maximale Performance

Der Request-Header Accept-Encoding signalisiert dem Server, welche Komprimierungsalgorithmen der Browser nativ entschlüsseln kann. Der Server packt die Daten daraufhin vor dem Senden zusammen:

# Der Client gibt an, welche Verfahren er unterstützt:
Accept-Encoding: gzip, deflate, br

# Der Server bestätigt das genutzte Kompressionsverfahren (hier Brotli):
Content-Encoding: br

Brotli (br) erzielt bei Textdateien (HTML, CSS, JS) oft eine um 15–25 % bessere Kompressionsrate als das ältere GZIP. Ein aktiviertes Brotli-Verfahren auf dem Server verbessert die Ladezeiten und optimiert direkt deine Core Web Vitals.