Wie hängen Verschlüsselung, Sicherheitsheader, Cookies und die Anwendung zusammen, wenn ich meine Website absichern will?
Eine Website absichern heißt, mehrere Schichten aufeinanderzusetzen, von denen jede eine andere Frage beantwortet. Keine ersetzt eine andere, und die oberen setzen die unteren voraus:
- Die Verbindung. HTTPS sorgt dafür, dass unterwegs niemand mitliest oder verändert und dass der Server zu dem Namen in der Adresszeile gehört. Ob dahinter jemand Ehrliches steht und was auf dem Server geschieht, sagt es nicht. HSTS verhindert, dass ein Browser auf unverschlüsseltes HTTP zurückfällt.
- Die Anweisungen an den Browser. Sicherheitsheader wirken im Browser jedes Besuchers: Eine Zeile in deiner Konfiguration schützt alle, ohne dass sie etwas tun müssen. Zu den wichtigsten gehört die Content Security Policy (CSP), die zweite Linie gegen eingeschleuste Skripte (Cross-Site-Scripting (XSS)).
- Die Grenzen zwischen Websites. Die Regel der gleichen Herkunft verbietet einer Seite, die Antworten einer anderen zu lesen. CORS lockert diese Regel gezielt — es schützt nichts, es öffnet etwas.
- Die Cookies. Ihre Attribute legen fest, dass ein Anmelde-Cookie nur verschlüsselt reist, für Skripte unsichtbar bleibt und nicht mitgeht, wenn eine fremde Seite ein Formular abschickt oder im Hintergrund etwas abruft.
Die Schichten greifen ineinander. Ein Cookie mit Secure nimmt der Browser von einer unverschlüsselten Antwort gar nicht an, und HSTS setzt eine Verschlüsselung voraus, die vollständig und dauerhaft funktioniert — fällt sie später aus, kommen Besucher bis zum Ablauf der Frist nicht mehr auf die Seite. Die Attribute schützen das Cookie, doch ein eingeschleustes Skript kann trotzdem im Namen des Besuchers handeln; dagegen hilft die Abwehr im Code und, als zweite Linie, die CSP. Gegen untergeschobene Aktionen wiederum, bei denen eine fremde Seite deinen Besucher etwas auslösen lässt, hilft weder CORS noch allein SameSite: Dafür braucht dein Server einen eigenen Schutz.
Und keine Schicht ersetzt eine sichere Anwendung. Header begrenzen, was ein Angreifer aus einer Lücke machen kann; schließen müssen sie Code und Server. Ein fehlender Header ist deshalb kein Beweis für einen Angriff, sondern eine fehlende Schutzschicht, deren Gewicht von deiner Seite abhängt: Derselbe fehlende Header wiegt auf einer Seite mit Anmeldung schwerer als auf einer ohne.
Daraus ergibt sich die Reihenfolge der Arbeit: erst verstehen, was jede Schicht leistet; dann den heutigen Stand deiner Antworten aufnehmen; dann ändern, jedes Mal mit Sicherung, Test und Weg zurück; zuletzt erneut prüfen — auf mehreren Seiten, denn Startseite, Anmeldeseite, Dateien und Fehlerseiten tragen oft verschiedene Header.
Die Header-Werkstatt wertet Header aus, die du selbst einfügst, und zwar nur in deinem Tab. Eine fremde Website ruft sie nicht ab, auf Knopfdruck nur die Startseite von HexWarte selbst. Zertifikat, Umleitung, Preload-Eintrag und Vorabanfragen prüft sie nicht, und sie vergibt keine Note: Jeder Befund nennt, unter welchen Voraussetzungen er zählt.