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

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; sie suchen 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.

Datenverluste und Sicherheitsvorfälle bei mittelständischen Unternehmen landen selten in den Schlagzeilen — aber sie passieren regelmäßig. Die Folgen sind Datenschutzverletzungen nach DSGVO, Vertrauensverlust bei Kunden und im schlimmsten Fall empfindliche Bußgelder. Was viele nicht wissen: 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.

INREMA prüft Sicherheitsaspekte nicht am Ende eines Projekts, sondern integriert sie von Anfang an in den 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. Wer Sicherheit als Feature behandelt statt als Pflichtübung, baut bessere Software.

Der folgende Artikel zeigt die zentralen Prüfpunkte vor dem Launch — strukturiert nach den Bereichen, in denen Fehler am häufigsten auftreten. Grundlage ist der OWASP-Standard, der international anerkannte Maßstab für Web-Anwendungssicherheit.

Der Login ist das Eingangstor zu jeder Web-App — und gleichzeitig der am häufigsten angegriffene Punkt. Die klassischen Fehler: kein Rate-Limiting (ein Angreifer kann unbegrenzt Passwörter ausprobieren), 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 kein Luxus mehr — sie ist Mindeststandard für alle Accounts mit Schreibrechten oder Zugriff auf sensible Daten. TOTP-Apps wie Google Authenticator oder Authy sind für Endnutzer zumutbar und für Entwickler in wenigen Stunden integrierbar. OAuth2 als Authentifizierungsprotokoll ermöglicht zusätzlich die sichere Anbindung externer Identity-Provider (Google, Microsoft) — 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 sind für Passwort-Hashing seit Jahren als unsicher eingestuft. Wer heute noch MD5-gehashte Passwörter in seiner Datenbank hat, hat ein akutes Problem — nicht ein theoretisches. 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 allein eliminiert automatisierte Brute-Force-Angriffe vollständig. Es ist eine der einfachsten und wirkungsvollsten Schutzmaßnahmen — und wird erstaunlich häufig vergessen.

Authentifizierung prüft wer jemand ist — Autorisierung prüft was jemand darf. Beide Konzepte müssen korrekt implementiert sein. Ein häufiges Problem: die Anwendung prüft beim Login die Berechtigung, danach jedoch nicht mehr konsequent. Ein Nutzer ruft direkt eine URL auf (/admin/users/42/edit) — und die Anwendung zeigt den Inhalt, weil die Routen-Ebene nicht abgesichert ist. Das nennt sich Broken Access Control und ist 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. Eine Session die serverseitig weiter gültig ist kann gestohlen und weitergenutzt werden, auch wenn der Nutzer sich längst ausgeloggt hat.

Rollenkonzepte müssen durchdacht und konsequent umgesetzt sein. Eine klare Trennung zwischen Endnutzer, Redakteur und Administrator verhindert Rechteausweitung. Wenn ein einfacher Nutzer durch Manipulation von Request-Parametern Admin-Funktionen aufrufen kann, ist das Rollenkonzept nicht implementiert — sondern nur simuliert. INREMA prüft 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 synchronisierten Tokens gesichert sein, die an die Session gebunden sind. Moderne Frameworks wie Laravel oder Symfony bieten das out-of-the-box — aber nur wenn es nicht versehentlich deaktiviert wird.