Web-App-Sicherheit: Was Unternehmen vor dem Launch prüfen müssen

Warum Sicherheit kein Nachgedanke sein darf

Viele Unternehmen denken bei der Entwicklung einer Web-App zuerst an Funktionen, Design und Geschwindigkeit – Sicherheit kommt auf die Liste, wenn noch Zeit bleibt. Das ist ein strukturelles Problem. Angreifer suchen nicht nach besonders ausgefeilten Schwachstellen, sondern nach dem einfachsten Weg hinein. Und der liegt häufig in den Grundlagen: ein Login ohne Brute-Force-Schutz, ein API-Endpunkt ohne Authentifizierung, ein Passwort, das im Klartext gespeichert wird.

Sicherheitsvorfälle bei mittelständischen Unternehmen landen selten in den Schlagzeilen, passieren aber regelmäßig. Die Folgen sind Datenschutzverletzungen nach DSGVO, Vertrauensverlust bei Kunden und im schlimmsten Fall empfindliche Bußgelder. Ein gemeldeter Datenschutzvorfall kann selbst dann kostspielig werden, wenn kein direkter Schaden entstanden ist, weil die Pflicht zur Meldung an die Aufsichtsbehörde innerhalb von 72 Stunden besteht.

Wir prüfen Sicherheitsaspekte nicht am Ende eines Projekts, sondern von Anfang an im Entwicklungsprozess. Das ist kein Aufwand – es spart ihn. Nachträgliche Sicherheitsfixes in produktiven Systemen sind aufwendiger, teurer und riskanter als sauber implementierte Lösungen von Beginn an. Grundlage dafür ist der OWASP-Standard.

Authentifizierung: Der häufigste Angriffspunkt

Der Login ist das Eingangstor jeder Web-App – und gleichzeitig der am häufigsten angegriffene Punkt. Klassische Fehler: kein Rate-Limiting, keine Multi-Faktor-Authentifizierung für privilegierte Accounts, schwache Passwortrichtlinien oder Standardpasswörter, die nach dem Deployment nicht geändert wurden. Jeder dieser Punkte allein kann eine vollständige Kompromittierung ermöglichen.

Multi-Faktor-Authentifizierung (MFA) ist heute Mindeststandard für alle Accounts mit Schreibrechten oder Zugriff auf sensible Daten. TOTP-Apps sind für Endnutzer zumutbar und für Entwickler in wenigen Stunden integrierbar. OAuth2 ermöglicht zusätzlich die sichere Anbindung externer Identity-Provider, ohne dass die Anwendung selbst Passwörter speichern muss.

Passwörter müssen gehasht gespeichert werden, mit modernen Algorithmen wie bcrypt, Argon2 oder scrypt. MD5 und SHA1 gelten für Passwort-Hashing seit Jahren als unsicher; Regenbogentabellen für MD5-Hashes sind öffentlich verfügbar und in Sekunden durchsuchbar. Rate-Limiting beim Login bedeutet: Nach fünf bis zehn fehlgeschlagenen Versuchen wird der Account temporär gesperrt oder eine CAPTCHA-Abfrage ausgelöst – das eliminiert automatisierte Brute-Force-Angriffe fast vollständig und wird trotzdem erstaunlich häufig vergessen.

Authentifizierungs-Checkliste vor dem Launch

• Rate-Limiting: maximal 10 Login-Versuche, dann temporäre Sperre
• Passwort-Hashing: bcrypt oder Argon2, niemals MD5/SHA1
• MFA aktiviert: Pflicht für Admin-Accounts, empfohlen für alle
• OAuth2-Integration: externe Provider sicher anbinden
• Passwortrichtlinien: Mindestlänge 12 Zeichen, Komplexitätsprüfung
• Kein Standard-Admin-Account: Zugangsdaten nach Setup ändern
• Login-Logs: Fehlversuche protokollieren und auswertbar machen
• Passwort-Reset: sichere Token mit Ablaufzeit, kein Klartext per E-Mail

Session-Management und Autorisierung

Authentifizierung prüft, wer jemand ist – Autorisierung prüft, was jemand darf. Ein häufiges Problem: Die Anwendung prüft beim Login die Berechtigung, danach jedoch nicht mehr konsequent. Ein Nutzer ruft direkt eine URL auf, etwa `/admin/users/42/edit`, und die Anwendung zeigt den Inhalt, weil die Routen-Ebene nicht abgesichert ist. Das nennt sich Broken Access Control und steht seit Jahren auf Platz 1 der OWASP Top 10.

Session-Tokens müssen ausreichend lang und zufällig sein (mindestens 128 Bit Entropie), über HTTPS übertragen werden und ein angemessenes Ablaufdatum haben. Nach dem Logout muss das Token serverseitig invalidiert werden, nicht nur clientseitig gelöscht – sonst kann eine weiterhin gültige Session gestohlen und weitergenutzt werden.

Rollenkonzepte müssen durchdacht und konsequent umgesetzt sein. Eine klare Trennung zwischen Endnutzer, Redakteur und Administrator verhindert Rechteausweitung. Kann ein einfacher Nutzer durch Manipulation von Request-Parametern Admin-Funktionen aufrufen, ist das Rollenkonzept nicht implementiert, sondern nur simuliert. Wir prüfen deshalb in jedem Projekt explizit, ob jeder API-Endpunkt und jede Datenbankabfrage die Berechtigungen des anfragenden Nutzers korrekt validiert.

CSRF-Schutz (Cross-Site Request Forgery) ist ein weiterer Pflichtpunkt: Formulare und state-verändernde Aktionen müssen mit an die Session gebundenen Tokens gesichert sein. Moderne Frameworks bieten das oft direkt an, aber nur, wenn es nicht versehentlich deaktiviert wird.

Ablauf: Sicherheitsprüfung vor dem Launch

• OWASP Top 10 als Checkliste durcharbeiten: Injection, Broken Access Control, Cryptographic Failures, Insecure Design und weitere Kategorien systematisch gegen die eigene Anwendung prüfen – bei einer gut dokumentierten Anwendung zwei bis vier Stunden Aufwand.
• Automatisierter Vulnerability-Scan: Tools wie OWASP ZAP oder Nikto scannen auf offene Verzeichnisse, fehlende Security-Header, veraltete Komponenten und unsichere Konfigurationen; kritische Findings werden vor dem Launch behoben.
• Manueller Penetrationstest für kritische Bereiche: Ein erfahrener Tester versucht aktiv, Berechtigungen zu umgehen, Sessions zu stehlen oder Parameter zu manipulieren – für eine mittelgroße Web-App mit Kundendaten ein halber bis ganzer Tag Aufwand.
• Dependency-Check: veraltete npm-Pakete, PHP-Bibliotheken oder Framework-Versionen mit Tools wie npm audit, Composer outdated oder OWASP Dependency-Check identifizieren; Bibliotheken mit bekannten CVEs vor dem Launch aktualisieren oder ersetzen.
• Security-Header und HTTPS konfigurieren: Content-Security-Policy, X-Frame-Options, HSTS, X-Content-Type-Options verhindern XSS-Angriffe, Clickjacking und Protocol-Downgrade-Attacken; HTTPS mit gültigem Zertifikat ist Pflicht, keine Option.
• Ergebnisse dokumentieren und Freigabe erteilen: alle Findings als kritisch, mittel oder niedrig einstufen; kritische Punkte werden vor dem Launch behoben, mittlere innerhalb von zwei Wochen nach Launch.

Ein häufiger Fehler bei schnell entwickelten Web-Apps: Die Benutzeroberfläche ist gesichert, aber die zugrundeliegenden API-Endpunkte sind öffentlich erreichbar. Wer die URL kennt, kann ohne Login Daten abrufen oder verändern. Das passiert besonders häufig bei React- oder Vue-Frontends mit separatem Backend: Der Entwickler sichert das Frontend-Routing, vergisst aber die REST-API dahinter. Jeder Endpunkt muss individuell auf Authentifizierung und Autorisierung geprüft werden, nicht nur die Hauptrouten.

Lassen Sie vor jedem Launch mindestens einen automatisierten Scan und einen manuellen Test auf die kritischsten Bereiche – Login, Datenzugriff, Admin-Funktionen – durchführen. Kein Aufwand ist teurer als ein Sicherheitsvorfall nach dem Go-live.