Anwendungssicherheit

Web App Security

Web-App-Sicherheit bedeutet: Eine Anwendung tut nur das, was sie tun soll. Das muss auch dann gelten, wenn jemand unerwartete oder schädliche Eingaben sendet. Neben dem Code zählen die Konfiguration und die Annahmen dahinter.

Diese Seite folgt einer Anfrage durch die Anwendung. Sie zeigt, wo Vertrauen wechselt, wo Risiken entstehen und warum bekannte Schutzmaßnahmen oft falsch verstanden werden.

Was Web-App-Sicherheit tatsächlich schützt

Das Ziel ist nicht unangreifbare Software. Es geht darum, Daten zu schützen, unerlaubte Aktionen zu verhindern und den Dienst verfügbar zu halten.

Der wichtigste Begriff ist die Vertrauensgrenze. Der Nutzer kontrolliert den Browser. Deshalb darf der Server Formularfelder, Cookies, Header, URLs und Uploads nicht ungeprüft übernehmen. Dasselbe gilt an Übergängen zu Datenbanken, Drittdiensten und internen Systemen.

Viele Schwachstellen entstehen, weil eine Anwendung Daten zu früh vertraut. Sie behandelt Eingaben als Befehl, übernimmt Angaben zu Rechten oder gibt gespeicherte Inhalte als ausführbaren Code aus. Die OWASP Top 10 ordnen solche wiederkehrenden Fehler in breite Kategorien ein.

Frameworks liefern sichere Voreinstellungen. Sie wissen aber nicht, welcher Kunde einen Datensatz besitzt oder wer eine Zahlung freigeben darf. Diese Regeln muss die Anwendung selbst durchsetzen.

Wie eine Anfrage durch die Anwendung läuft

Folge einer Anfrage vom Browser bis zur Antwort. An jeder Station fällt eine andere Sicherheitsentscheidung.

01 · Transport
HTTPS schützt Daten auf dem Transportweg. Ob die Anwendung dahinter sicher ist, sagt das noch nicht.
02 · Eingangspunkt
Der Server zerlegt die Anfrage in Pfade, Parameter, Header und Cookies. All diese Daten sind zunächst nicht vertrauenswürdig.
03 · Authentifizierung
Die Anwendung stellt fest, wer die Anfrage sendet. Dafür prüft sie meist Zugangsdaten, eine Session oder ein Token. Authentifizierung beantwortet nur die Frage nach der Identität.
04 · Session
Nach dem Login steht eine Session oder ein Token für den Nutzer. Wird sie gestohlen oder erraten, kann ein Angreifer ohne Passwort in dessen Namen handeln.
05 · Autorisierung
Der Server muss jede Aktion und jeden Datensatz prüfen. Er entscheidet bei jeder Anfrage, ob die jeweilige Identität darauf zugreifen darf. Ein ausgeblendeter Button ist keine Zugriffskontrolle.
06 · Eingabeverarbeitung und Geschäftslogik
Validierung begrenzt die akzeptierten Daten. Die Geschäftslogik entscheidet über ihre Bedeutung. Viele folgenreiche Fehler liegen genau hier. Beispiele sind negative Mengen, überspringbare Bezahlschritte oder Objekt-IDs ohne Eigentumsprüfung.
07 · Datenzugriff und Ausgabe
Datenbankabfragen müssen Eingaben als Daten behandeln, nicht als Code. Output-Encoding verhindert, dass gespeicherte Inhalte im Browser zu Skript werden. Validierung und Encoding lösen verschiedene Probleme.

Wo sich Risiko konzentriert

In vielen Anwendungen tauchen dieselben Schwachstellen auf. Diese Bereiche sind ein guter Startpunkt.

Authentifizierung

Prüfe Passwörter, Kontowiederherstellung, Rate Limits und Mehr-Faktor-Authentifizierung. Die Wiederherstellung kann das Passwort umgehen und braucht deshalb starke Kontrollen.

Autorisierung

Auf Objekt- und Funktionsebene fehlen Prüfungen oder sie sind uneinheitlich. Broken Access Control steht in den OWASP Top 10:2025 an erster Stelle. Sinnvolle Prüfungen hängen vom Domänenmodell ab. Der Server muss sie konsequent durchsetzen.

Sessions und Tokens

Cookie-Attribute, Token-Laufzeiten und das Ungültigmachen bei Logout und Passwortwechsel. Ein langlebiges Token im Browser-Speicher vergrößert das Zeitfenster für Missbrauch und braucht einen geplanten Widerruf.

APIs

APIs stellen dieselbe Logik ohne die Leitplanken der Oberfläche bereit. Jeder Endpunkt braucht eine klare Zugriffsregel. Er kann öffentlich, authentifiziert oder enger autorisiert sein. Der Server muss diese Regel auch bei internen Endpunkten durchsetzen.

Abhängigkeiten und Konfiguration

Pakete, Basis-Images und Infrastruktur gehören zur Angriffsfläche. Halte den Bestand aktuell und entferne, was nicht mehr gebraucht wird.

Fehlerbehandlung und Logging

Detaillierte Fehler können zu viel über das System verraten. Fehlende Logs erschweren die Aufklärung eines Vorfalls. Protokolliere relevante Ereignisse, aber keine Secrets.

Geschäftslogik

Einzelne Aktionen können gültig sein und zusammen trotzdem Schaden verursachen. Beispiele sind Race Conditions bei Rabatten, wiederholte Anfragen und übersprungene Prüfschritte. Automatische Scanner können Geschäftsregeln nicht zuverlässig ableiten. Dafür braucht es eine Analyse des Kontexts.

Ein realistisches Beispiel entlang einer Anfrage

Ein eingeloggter Nutzer fordert in einer Rechnungs-App die Rechnung 8241 als PDF an. Die Verbindung ist verschlüsselt, die Session gültig und der Nutzer korrekt angemeldet. Danach liefert der Server die Datei aus.

Eine Prüfung fehlt: Gehört Rechnung 8241 wirklich zu diesem Konto? Jede angemeldete Person kann die Nummer in der URL ändern und so fremde Rechnungen lesen.

TLS, Passwort-Hashing und Session-Verwaltung funktionieren. Trotzdem fließen Daten ab, weil die Autorisierung für den einzelnen Datensatz fehlt.

Die Abfrage muss deshalb auf das angemeldete Konto begrenzt werden. Diese fachliche Regel kann weder ein Scanner noch das Framework für das Team festlegen.

Verbreitete Missverständnisse

Diese Aussagen klingen plausibel. Aber jede lässt einen wichtigen Teil der Sicherheit aus.

„HTTPS macht die Anwendung sicher“

TLS schützt den Transportkanal. Injection, fehlerhafte Zugriffskontrolle oder Logikfehler in Anwendungsanfragen behebt es nicht.

„Authentifizierung deckt Autorisierung ab“

Identität und Berechtigung sind zwei getrennte Prüfungen. Ein gültiger Login erlaubt nicht automatisch jede Aktion und jeden Datensatz.

„Eingabevalidierung ersetzt Output-Encoding“

Validierung begrenzt die eingehenden Daten. Encoding steuert ihre Interpretation bei der Ausgabe. Auch validierte Daten können zu Skript werden. Das passiert, wenn passendes Output-Encoding im HTML-Kontext fehlt.

„UI-Beschränkungen erzwingen serverseitige Sicherheit“

Deaktivierte Buttons, versteckte Felder und Prüfungen im Browser lassen sich umgehen. Die eigentlichen Regeln muss der Server durchsetzen.

„Ein sauberer Scan bedeutet eine sichere Anwendung“

Automatische Scanner finden bekannte technische Muster. Geschäftsregeln, Eigentumsmodelle und verkettete Schwächen verstehen sie nicht. Ein Scanner ist ein Baustein einer Sicherheitsprüfung, nicht die Prüfung selbst.

„Die OWASP Top 10 sind eine vollständige Checkliste“

OWASP beschreibt die Top 10 als Awareness-Dokument. Tests gegen zehn Kategorien ergeben noch kein Sicherheitsprogramm. Prüfstandards wie der ASVS bieten deutlich mehr Tiefe.

Was Tests belegen können - und was nicht

Ein Sicherheitstest betrachtet eine bestimmte Version, Konfiguration und Zeitspanne. Er kann eine Schwachstelle belegen. Er kann nicht beweisen, dass es keine weiteren gibt. Jede größere Änderung kann das Ergebnis verändern.

Sicherheit muss deshalb Teil der Entwicklung bleiben. Standards wie der OWASP ASVS helfen bei der Auswahl der Prüfungen. Risiko und Änderungstempo bestimmen, wann erneut geprüft wird.

Ein Befund belegt eine Schwäche. Ein leerer Bericht belegt keine Sicherheit
Schweregrade beschreiben technische Auswirkungen, nicht Geschäftsauswirkungen
Testergebnisse veralten mit jeder Änderung der Anwendung
Werkzeuge unterstützen Urteilsvermögen, sie ersetzen es nicht
Teste nur, was dir gehört oder wofür du eine ausdrückliche Erlaubnis hast

Das Wichtigste in Kürze

01Markiere alle Stellen, an denen Daten aus fremder Kontrolle in deine wechseln.
02Prüfe zuerst die Identität und dann die Rechte für jede Aktion und jeden Datensatz.
03Validiere Eingaben und encodiere Ausgaben. Beides löst unterschiedliche Probleme.
04Behandle Abhängigkeiten und Konfiguration als Teil der Anwendung.
05Nutze die OWASP Top 10 für den Überblick und den ASVS für genaue Prüfungen.
06Behandle jeden Test als Momentaufnahme, nicht als Garantie.

Quellen und weiterführende Literatur

Eine kompakte Auswahl an Primärquellen, Standards und öffentlich zugänglicher technischer Orientierung, auf die sich dieser Artikel stützt.