Web-Sicherheit ist die Disziplin, das Web als alltägliches Werkzeug verlässlich nutzbar zu machen — für Menschen, die surfen, mailen und Konten verwalten, und für Teams, die Anwendungen darauf bauen. Sie umspannt alles vom korrekt gesetzten Cookie über das stark gehashte Passwort bis zum gehärteten Reverse-Proxy. Dieser Artikel ordnet das Feld: welche Schutzziele es überhaupt gibt, wer im Web angreift und warum, mit welchen Grundprinzipien man sich verteidigt — und warum Sicherheit nie ein Produkt, sondern immer ein Prozess ist.
Kurz gesagt: Worum geht es?
Web-Sicherheit ist der Versuch, die Lücke zwischen dem zu schließen, was eine Web-Anwendung tun soll, und dem, was sie unter Beschuss tatsächlich tut. Beschuss heißt: ein Angreifer schickt Eingaben, die der Entwickler nicht erwartet hat, oder nutzt Vertrauen aus, das der Nutzer fälschlich gewährt. Aus dieser Lücke entstehen die klassischen Disziplinen:
- Anwendungssicherheit — XSS, CSRF, SQL-Injection, kaputte Autorisierung. Was passiert, wenn der Browser einer Seite Code ausführt, der dort nicht hingehört, oder eine API Daten zurückgibt, die der Nutzer nicht sehen darf?
- Authentifizierung und Sitzungs-Sicherheit — wie weiß ein Server, dass am anderen Ende wirklich Alice sitzt? Passwörter, 2FA, Passkeys, Sessions, Tokens.
- Transport- und Infrastruktur-Sicherheit — TLS, Zertifikate, Reverse-Proxies, Server-Härtung, Logging und Monitoring.
- Nutzer- und Geräte-Sicherheit — Browser-Härtung, Phishing-Erkennung, Tracking-Schutz, Privatsphäre, Anonymität, Recovery-Strategien.
Diese Doku-Section behandelt alle vier Bereiche, klar getrennt nach Zielgruppe: die Kapitel 1 bis 9 sprechen Menschen an, die das Web benutzen; die Kapitel 10 bis 18 sprechen Menschen an, die das Web bauen; die Kapitel 19 und 20 schlagen die Brücke zum Betrieb.
Die Schutzziele
Im Kern jeder Sicherheits-Betrachtung stehen wenige, klassische Ziele. Das bekannteste Akronym ist CIA — und meint hier ausdrücklich nicht den Geheimdienst:
- Confidentiality (Vertraulichkeit) — Daten sind nur für berechtigte Personen lesbar. Beispiel: dein Kontoauszug bleibt zwischen dir und deiner Bank, auch wenn dazwischen ein WLAN-Hotspot, ein ISP und drei Router liegen.
- Integrity (Integrität) — Daten kommen so an, wie sie gesendet wurden. Beispiel: eine Überweisung von 50 € wird unterwegs nicht zu 5000 € umgeschrieben.
- Availability (Verfügbarkeit) — das System ist erreichbar, wenn es gebraucht wird. Beispiel: ein DDoS-Angriff legt den Online-Shop am Black-Friday-Wochenende nicht lahm.
In der Praxis kommen zwei weitere Ziele dazu, die im modernen Web mindestens gleich wichtig sind:
- Authentizität — kommt die Nachricht wirklich von der angegebenen Quelle? E-Mail-Spoofing, manipulierte Updates, gefälschte API-Antworten sind alles Verstöße gegen Authentizität.
- Nichtabstreitbarkeit (Non-Repudiation) — der Absender kann später nicht behaupten, etwas nicht gesendet zu haben. Signierte Verträge, kryptografische Audit-Logs.
Jede konkrete Schutzmaßnahme adressiert eines oder mehrere dieser Ziele. CSP schützt primär Integrität (kein fremder Code im Browser), HTTPS primär Vertraulichkeit (Mitlesen verhindern), Code-Signing Authentizität (Update kommt vom echten Hersteller).
| Schutzziel | Beispiel-Maßnahmen | Typische Bedrohungen |
|---|---|---|
| Vertraulichkeit | TLS, Disk-Encryption, RBAC, E2E-Verschlüsselung | Sniffing, Datenleck, Insider-Zugriff |
| Integrität | HMAC, Signaturen, CSP, Subresource Integrity | MITM, XSS, Tampering, Cache Poisoning |
| Verfügbarkeit | Rate-Limit, CDN, Redundanz, Backups | DDoS, Ransomware, Konfigurations-Fehler |
| Authentizität | Signaturen, DKIM, mTLS, WebAuthn | Spoofing, Phishing, gefälschte Updates |
| Nichtabstreitbarkeit | Signierte Logs, Audit-Trails, Zeitstempel | Streit nach Vorfall, Log-Manipulation |
Wichtig: diese Ziele konkurrieren miteinander. Maximale Vertraulichkeit (alles Ende-zu-Ende-verschlüsselt, niemand kommt rein) sabotiert Verfügbarkeit (Recovery wird schwer) und Auditierbarkeit. Sicherheits-Entscheidungen sind immer Trade-offs.
Wer greift an — und warum?
Ein häufiger Anfängerfehler ist, sich „den Hacker" als einheitliche Figur vorzustellen. Tatsächlich gibt es im Web sehr verschiedene Akteure mit sehr verschiedenen Mitteln und Zielen.
- Skript-Kiddies und opportunistische Bots — automatisierte Massen-Scans, die nach exakt einer bekannten Lücke suchen (z. B. ein veraltetes WordPress-Plugin). Wenig Aufwand, riesige Reichweite. Verteidigung: gepatcht bleiben, Default-Credentials raus, Standard-Pfade absichern.
- Organisierte Kriminalität — meist auf Geld aus. Ransomware-Banden, Phishing-Kits-as-a-Service, Banking-Trojaner, Credential-Stuffing-Operatoren. Verteidigung: 2FA überall, Backups offline, Mitarbeitende auf Phishing schulen.
- Hacktivisten — politisch motiviert, oft auf öffentliche Wirkung aus (Defacement, Doxxing, DDoS). Verteidigung: Aufmerksamkeit für die eigene Angriffsfläche, Krisen-Kommunikation vorbereitet halten.
- Insider — Mitarbeitende oder ehemalige Mitarbeitende mit legitimen Zugängen. Verteidigung: Least Privilege, vollständige Off-Boarding-Prozesse, Audit-Logs für administrative Aktionen.
- APTs und staatliche Akteure — gut finanziert, geduldig, zielgerichtet. Greifen Journalist:innen, Aktivist:innen, Behörden, Unternehmen mit IP-Wert an. Verteidigung: realistisch eingestehen, dass ein normales Web-Setup hier nicht ausreicht; spezialisierte Quellen heranziehen (EFF Surveillance Self-Defense, Access Now).
Vor allen drei großen Klassen schützen 90 Prozent der Maßnahmen aus dieser Doku. Vor APTs schützt eine Web-Sicherheits-Doku nicht — wer ein solches Threat-Model hat, braucht zusätzliche Beratung.
Was angreifbar ist: die Web-Stack-Karte
Eine Web-Anwendung ist eine Kette. Jeder Knoten kann angegriffen werden — und jede Verbindung dazwischen. Wer sich die Stack-Karte einmal eingeprägt hat, hat eine Sprache für Schwachstellen-Diskussionen:
Nutzer
│
▼
Endgerät (Browser, OS, Erweiterungen)
│ TLS, Phishing, Malware, Tracking
▼
Netzwerk (WLAN, ISP, DNS, CDN)
│ Sniffing, DNS-Spoofing, Cert-MITM
▼
Reverse-Proxy / WAF
│ Header-Injection, Slowloris, Bypass
▼
Anwendung (Frontend + Backend)
│ XSS, CSRF, Injection, IDOR, SSRF
▼
Datenbank, Cache, Storage
│ SQLi, NoSQL-Injection, Bucket-Leak
▼
Externe APIs (Zahlung, Auth, Mail)
OAuth-Flow-Bugs, Webhook-ForgeryDiese Schichten sind die Strukturierung der gesamten Section: Kapitel 4 bis 8 behandeln Endgerät und Netz aus Nutzer-Sicht. Kapitel 11 bis 15 behandeln die Anwendung selbst. Kapitel 16 bis 18 schauen auf Header, Crypto und APIs. Kapitel 19 und 20 nehmen Reverse-Proxy, TLS und Betrieb in den Blick.
Defense-in-Depth: Ringe um den Kern
Das wichtigste strategische Prinzip in der Sicherheit heißt Defense-in-Depth — Verteidigung in der Tiefe. Statt sich auf eine einzige starke Schutzmauer zu verlassen, baut man mehrere Schichten, die alle versagen müssten, bevor ein Angriff erfolgreich ist.
Praktisches Beispiel aus dem Web: Schutz vor XSS
- Eingabe-Validierung — verwerfe oder normalisiere alles, was nicht ins erwartete Schema passt.
- Output-Encoding — beim Rendern werden alle dynamischen Werte für ihr Ziel-Format codiert (HTML, JS, URL).
- Content Security Policy — selbst wenn doch HTML-Tags durchrutschen, lehnt der Browser fremdes JavaScript ab.
- Trusted Types — DOM-Sinks wie
innerHTMLakzeptieren nur explizit als sicher markierte Werte. - HttpOnly-Cookies — selbst wenn ein Angreifer Code im Browser ausführt, kommt er nicht ans Session-Cookie.
- Kurze Session-Lebensdauer + Re-Auth — und falls er doch dran kommt, ist es bald ungültig.
Sechs Schichten gegen ein Problem. Keine ist allein perfekt. Zusammen bilden sie eine sehr hohe Hürde — und genau das ist der Punkt.
Der Gegensatz dazu heißt Single Point of Failure: eine einzige Maßnahme, deren Versagen den ganzen Schutz kippt. Sicherheits-Architektur erkennt man daran, dass es so etwas nicht gibt.
Least Privilege: nur das Nötigste
Direkt verwandt mit Defense-in-Depth ist Least Privilege — das Prinzip der minimalen Rechte. Jeder Bestandteil eines Systems bekommt genau die Berechtigungen, die er für seine Aufgabe braucht, und nicht mehr.
- Ein Datenbank-User für eine Web-App braucht
SELECT/INSERT/UPDATEauf wenige Tabellen — nichtDROP TABLEoderSUPERUSER. - Ein Cron-Job-Container, der Bilder skaliert, braucht keinen Netzwerk-Zugang.
- Ein Browser-Extension darf nur auf die Domains zugreifen, für die sie tatsächlich gebraucht wird.
- Ein API-Token für eine Integration darf nur die Scopes haben, die diese Integration nutzt.
Klingt selbstverständlich. In der Realität sehen Produktiv-Systeme oft so aus, dass eine Datenbank-Verbindung postgres://admin:pass@… heißt und alles darf. Wenn diese Credentials leaken — und sie leaken — ist der Schaden maximal.
Sicherheit ist ein Prozess
Der wahrscheinlich häufigste Missverständnis-Punkt: Sicherheit ist kein Zustand, sondern eine Aktivität. Ein „sicheres System" gibt es nicht — es gibt nur Systeme, deren bekannte Schwachstellen gerade gepatcht sind und deren Konfiguration gerade dem aktuellen Stand der Technik entspricht.
Was das bedeutet:
- Patching-Disziplin. Eine Anwendung, die heute frei von bekannten Schwachstellen ist, ist in zwei Wochen möglicherweise verwundbar — weil eine neue CVE in einer Dependency veröffentlicht wurde. Automatisierte Dependency-Updates (Dependabot, Renovate) sind heute Standard.
- Monitoring und Erkennung. Selbst beste Prävention ist nicht perfekt. Wer Vorfälle früh sehen will, braucht strukturierte Logs, Alerting auf Anomalien und einen geübten Incident-Response-Prozess.
- Übung. Backups, die nie restored werden, funktionieren erfahrungsgemäß im Ernstfall nicht. Incident-Response-Runbooks, die nie durchgespielt werden, helfen unter Druck wenig.
- Lernen. Jeder Vorfall — eigener oder bei anderen — ist eine Quelle. Lessons Learned werden in Maßnahmen übersetzt.
Aus Nutzer-Sicht heißt das Gleiche in Kleinformat: alle paar Monate die wichtigsten Konten durchschauen, aktive Sessions widerrufen, Recovery-Daten prüfen, schauen, ob Mail oder Passwörter in Lecks aufgetaucht sind.
Worüber diese Section nicht spricht
Klare Abgrenzung gehört zu jedem Doku-Anfang. Dieser Bereich ist bewusst:
- Defensiv, nicht offensiv. Wir zeigen, wie Angriffe funktionieren — soweit nötig, damit Verteidigung verständlich wird. Wir liefern keine fertigen Exploits gegen Live-Systeme. Pentest-Anleitungen, Red-Team-Playbooks, Exploit-Entwicklung sind eigene Disziplinen mit eigenen, sehr guten Quellen.
- Web-zentriert. Mobile-Apps, Desktop-Apps, IoT-Geräte, OT/SCADA-Sicherheit werden gestreift, wo sie das Web berühren, aber nicht im Kern behandelt.
- Keine Rechtsberatung. DSGVO und TTDSG werden eingeordnet, wo sie Sicherheits-Pflichten begründen (Meldepflichten, Daten-Minimierung). Konkrete rechtliche Bewertung gehört in Anwaltskanzleien und Datenschutz-Beauftragten-Hände.
- Anbieter-neutral. Wo Werkzeuge empfohlen werden — Passwort-Manager, VPN-Anbieter, sichere Messenger — gibt es immer mehrere Alternativen mit klar genannten Trade-offs. Affiliate-getriebene „Best-of"-Empfehlungen vermeiden wir bewusst.
Interessantes
"Sicherheit ist ein Prozess, kein Produkt" — Bruce Schneier
Der Satz ist über zwanzig Jahre alt und altert nicht. Schneier wendet sich damit gegen die Illusion, ein Stück Software oder ein Gerät könnte ein System dauerhaft sicher machen. Sicherheit lebt davon, dass Menschen sie wiederholt anwenden, prüfen, anpassen.
Das Wort "Hacker" ist neutral, "Cracker" historisch
In der ursprünglichen Bedeutung (MIT, 1960er) bezeichnet Hacker jemanden, der Systeme tief versteht und kreativ nutzt — neutral oder positiv. Für böswillige Akteure prägte die Szene Anfang der 1980er den Gegenbegriff Cracker. In Medien hat sich „Hacker" als pauschaler Negativ-Begriff durchgesetzt, in technischen Communities ist die Trennung bis heute lebendig.
OWASP ist eine Stiftung, kein Standards-Gremium.
Die Open Worldwide Application Security Project-Foundation ist eine US-amerikanische Non-Profit-Organisation. Ihre Veröffentlichungen — Top 10, ASVS, Cheat Sheets — sind keine bindenden Standards, gelten aber als Industrie-Konsens und werden von Audits, Compliance-Programmen und Regulierern referenziert.
"CIA" ist älter als das Web
Die Trias Confidentiality, Integrity, Availability wurde 1977 von Steve Lipner und Kollegen im Kontext militärischer Computer-Systeme formalisiert. Erst Jahrzehnte später wanderte das Akronym in die Mainstream-IT — und ist heute fast überall die Eingangs-Definition.
Kerckhoffs-Prinzip: das System muss öffentlich sicher sein
Auguste Kerckhoffs schrieb 1883: ein Krypto-System muss auch dann sicher sein, wenn alles außer dem Schlüssel öffentlich bekannt ist. „Sicherheit durch Verschleierung" — geheime Algorithmen, versteckte Endpunkte als Schutz — fällt seit über 140 Jahren als Strategie durch. Übertragen auf das Web: niemand sollte sich darauf verlassen, dass eine URL „niemand findet".
Die meisten Datenlecks sind banal.
Die jährlichen Verizon-DBIR-Berichte zeigen seit Jahren das gleiche Bild: ein Großteil aller erfolgreichen Angriffe nutzt menschliche Faktoren (Phishing, schwache Passwörter, Fehlkonfigurationen) — nicht hochwertige Zero-Days. Das ist eine gute Nachricht für Verteidigung: die wirksamsten Maßnahmen sind oft unspektakulär.
Weiterführende Ressourcen
Externe Quellen
- OWASP Foundation – Übersicht
- OWASP Top 10 – aktuelle Edition
- OWASP Cheat Sheet Series
- MDN Web Docs – Web Security
- web.dev – Secure
- BSI – IT-Grundschutz
- Bruce Schneier – „Security is a Process, Not a Product" (Crypto-Gram 2000)
- Verizon Data Breach Investigations Report (jährlich)
- EFF Surveillance Self-Defense