HTTP, Requests & DevTools

Jede Webseite, jedes Formular und jeder Login ist am Ende ein Gespräch zwischen Browser und Server – geführt in HTTP-Nachrichten. Wer Web-Sicherheit verstehen will, muss diese Nachrichten lesen können. Die gute Nachricht: Dein Browser zeigt sie dir, mit den Entwickler-Werkzeugen (DevTools).

Anfrage und Antwort

HTTP ist ein textbasiertes Protokoll mit einem einfachen Muster: Der Browser schickt eine Anfrage (Request), der Server antwortet (Response). Jede Nachricht besteht aus einer Startzeile, mehreren Kopfzeilen (Headern) und optional einem Inhalt (Body).

So sieht eine einfache Suche aus – oben die Anfrage, unten die Antwort:

GET /suche?q=manta HTTP/1.1
Host: www.example.org
Cookie: session=3f1c9a…
User-Agent: Mozilla/5.0 …

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: session=3f1c9a…; Secure; HttpOnly; SameSite=Lax

<!doctype html> …

Methoden: Was soll passieren?

Statuscodes: Was ist passiert?

Für Angreifer sind schon Unterschiede in den Antworten eine Information: Liefert ein Login bei unbekannten Nutzern eine andere Meldung als bei einem falschen Passwort, lässt sich herausfinden, welche Konten existieren.

Header, die du kennen solltest

• Host – für welche Website die Anfrage gedacht ist. Er kommt vom Client und kann gefälscht werden.
• Cookie / Set-Cookie – der Browser schickt gespeicherte Cookies mit, der Server setzt neue.
• Content-Type – welches Format der Body hat (HTML, JSON, Formulardaten …).
• Location – Ziel einer Umleitung.
• Referer und User-Agent – woher die Anfrage kommt und welcher Browser sie stellt. Beides ist frei wählbar und taugt nicht als Sicherheitsmerkmal.
• Sicherheits-Header wie Content-Security-Policy, Strict-Transport-Security oder X-Content-Type-Options – sie weisen den Browser an, bestimmte Angriffe zu blockieren.

Cookies und Sitzungen

HTTP ist zustandslos: Jede Anfrage steht für sich. Damit ein Server weiß, dass du angemeldet bist, gibt er dir nach dem Login ein Cookie mit einer zufälligen Sitzungs-ID. Bei jeder weiteren Anfrage schickt der Browser es automatisch mit. Daraus folgt: Wer dieses Cookie besitzt, ist für den Server du.

Darum sind die Attribute eines Sitzungs-Cookies so wichtig:

• Secure – das Cookie wird nur über HTTPS übertragen.
• HttpOnly – JavaScript kann es nicht auslesen. Das bremst Sitzungsdiebstahl über XSS.
• SameSite (Strict, Lax oder None) – ob das Cookie auch bei Anfragen mitgeschickt wird, die von fremden Websites ausgelöst werden. Ein wichtiger Baustein gegen CSRF.
• Domain, Path und Ablaufzeit – für welche Adressen das Cookie gilt und wie lange.

HTTPS – verschlüsselt, aber nicht automatisch sicher

HTTPS verschlüsselt den Transport mit TLS: Niemand im WLAN oder beim Provider kann mitlesen oder Inhalte unbemerkt verändern. Der Header Strict-Transport-Security (HSTS) sorgt dafür, dass der Browser die Seite künftig nur noch verschlüsselt aufruft.

Wichtig: HTTPS schützt den Weg, nicht die Anwendung. Eine SQL-Injection funktioniert über HTTPS genauso gut.

Die DevTools: dein Röntgenblick

Alle gängigen Browser bringen Entwickler-Werkzeuge mit. Öffnen mit F12 bzw. Strg+Umschalt+I – auf dem Mac mit Cmd+Option+I.

1. 1
   Netzwerk (Network)

   Zeigt jede Anfrage der Seite. Ein Klick darauf öffnet Header, gesendete Daten (Payload), Antwort und Cookies. Aktiviere „Log beibehalten“ (Preserve log), damit Umleitungen nach einem Formular-Absenden sichtbar bleiben.

2. 2
   Anfrage nachbauen

   Rechtsklick auf eine Anfrage → „Als cURL kopieren“ (Copy as cURL). Im Terminal lässt sie sich dann beliebig verändern und erneut senden. Firefox kann Anfragen direkt im Browser bearbeiten und erneut senden.

3. 3
   Speicher (Application/Storage)

   Hier siehst du Cookies samt Attributen sowie Local und Session Storage – und kannst sie zum Testen ändern oder löschen.

4. 4
   Elemente (Elements/Inspector)

   Zeigt das HTML so, wie es gerade im Browser ist. Versteckte Formularfelder, deaktivierte Buttons oder eine maximale Eingabelänge lassen sich hier mit zwei Klicks ändern.

5. 5
   Konsole (Console)

   Fehlermeldungen von Skripten und eine JavaScript-Eingabe. Praktisch, um zu prüfen, was eine Seite im Browser preisgibt.

Die wichtigste Lektion: Der Browser gehört dem Nutzer

Alles, was im Browser passiert, kann verändert werden: versteckte Felder, JavaScript-Prüfungen, ausgegraute Buttons, Preise oder IDs in der URL. Eine Anfrage muss nicht einmal aus einem Browser kommen – ein Werkzeug wie curl reicht.

Deshalb gilt: Prüfungen im Browser sind Komfort, keine Sicherheit. Ob jemand etwas sehen oder tun darf und ob eine Eingabe gültig ist, muss der Server entscheiden – bei jeder einzelnen Anfrage.

# Dieselbe Formular-Anfrage – ohne Browser, mit veränderten Werten
curl -X POST https://www.example.org/bestellung \
  -H 'Cookie: session=3f1c9a…' \
  -d 'artikel=42&menge=1&preis=0'

// config/system/additional.php (TYPO3 v12+)
$GLOBALS['TYPO3_CONF_VARS']['SYS']['trustedHostsPattern'] = '(www\\.)?example\\.org';

Weiter im Wissen

Interaktiv üben

In der Lernplattform probierst du das an einer echten, isolierten TYPO3-Instanz aus:

Quellen & weiterlesen

• MDN: Überblick über HTTP
• MDN: Set-Cookie (Secure, HttpOnly, SameSite)
• Chrome DevTools: Netzwerk-Analyse
• Firefox: Netzwerkanalyse
• TYPO3: Content Security Policy
• TYPO3: SYS-Konfiguration (trustedHostsPattern)

Jetzt interaktiv üben →