Webanwendungen werden täglich angegriffen. Nicht nur große Konzerne — auch Mittelständler, Handwerksbetriebe mit Onlineshops und Startups sind Ziele. Laut BSI (Bundesamt für Sicherheit in der Informationstechnik) hat die Zahl der Cyberangriffe auf deutsche Unternehmen 2025 erneut zugenommen. Und der häufigste Angriffsvektor sind keine Nullday-Exploits — es sind bekannte, gut dokumentierte Schwachstellen, die einfach nicht behoben wurden.
Dieser Artikel gibt einen praxisnahen Überblick über die häufigsten Schwachstellen und konkrete Maßnahmen, die jede moderne Webanwendung implementieren sollte.
OWASP Top 10: Die kritischsten Schwachstellen
Das Open Web Application Security Project (OWASP) veröffentlicht regelmäßig eine Liste der zehn kritischsten Web-Sicherheitsrisiken. Diese Liste ist der De-facto-Standard für Web-Sicherheitsaudits. Die wichtigsten fünf für 2025/2026:
- A01 – Broken Access Control: Nutzer können auf Daten oder Funktionen zugreifen, die für sie nicht freigegeben sind. Häufigstes Problem: fehlende Serverside-Prüfungen, die nur clientseitig (im Browser) implementiert sind.
- A02 – Cryptographic Failures: Sensible Daten werden unverschlüsselt gespeichert oder übertragen. Beispiel: Passwörter im Klartext, unverschlüsselte HTTP-Verbindungen für Formulare.
- A03 – Injection: SQL-Injection, Command Injection, LDAP Injection — alle entstehen durch fehlende oder falsche Eingabe-Validierung.
- A07 – Identification and Authentication Failures: Schwache Passwörter erlaubt, kein MFA, schlecht implementiertes Session-Management.
- A05 – Security Misconfiguration: Standard-Passwörter nicht geändert, Debug-Modus in Produktion aktiv, zu freizügige CORS-Einstellungen.
SQL-Injection & Co.: Eingaben niemals vertrauen
SQL-Injection ist seit Jahrzehnten bekannt — und trotzdem eine der häufigsten Schwachstellen. Das Prinzip: Nutzereingaben werden ungefiltert in eine SQL-Abfrage eingebaut. Ein Angreifer gibt statt eines normalen Namens SQL-Syntax ein und manipuliert die Datenbankabfrage.
// Verwundbar:
const query = "SELECT FROM users WHERE name = '" + userInput + "'";
// Mit userInput = "'; DROP TABLE users; --"
// wird daraus: SELECT FROM users WHERE name = ''; DROP TABLE users; --
// Sicher — Prepared Statement:
const query = "SELECT * FROM users WHERE name = ?";
db.execute(query, [userInput]);
Die Lösung ist konsequenter Einsatz von Prepared Statements / Parameterized Queries. Rohe String-Konkatenation für Datenbankabfragen ist 2026 absolut inakzeptabel. Gleiches gilt für Command Injection: Benutzereingaben niemals direkt an Shell-Befehle weitergeben.
Cross-Site Scripting (XSS) folgt demselben Prinzip: Nutzereingaben, die als HTML ausgegeben werden, müssen escaped werden. Moderne Frameworks wie React, Vue oder Angular machen das standardmäßig — aber sobald `dangerouslySetInnerHTML` oder `v-html` eingesetzt wird, öffnet sich ein Einfallstor.
Sichere Authentifizierung implementieren
Authentifizierung richtig zu implementieren ist schwieriger als es scheint. Das sind die Mindestanforderungen für jede professionelle Webanwendung 2026:
- Passwort-Hashing: Niemals Passwörter im Klartext oder mit MD5/SHA1 speichern. Standard 2026: bcrypt, scrypt oder Argon2 mit ausreichendem Work Factor.
- Multi-Faktor-Authentifizierung (MFA): Für alle administrativen Zugänge und empfohlen als Option für alle Nutzer. TOTP (Google Authenticator, Authy) ist der einfachste Standard.
- Session Management: Session-IDs müssen zufällig, lang und nach dem Login neu generiert werden (Session Fixation verhinden). Sessions müssen serverseitig invalidierbar sein (Logout).
- Rate Limiting für Login: Nach 5–10 Fehlversuchen muss der Account temporär gesperrt oder eine CAPTCHA-Abfrage eingebaut werden.
- Sichere Password-Reset-Flows: Reset-Tokens müssen zeitlich begrenzt sein (30 Minuten), einmalig verwendbar und kryptographisch zufällig.
HTTPS & Security-Header
HTTPS ist 2026 keine Option, sondern Grundvoraussetzung. Aber HTTPS allein reicht nicht. Security-Header im HTTP-Response vervollständigen den Schutz:
- Strict-Transport-Security (HSTS): Erzwingt HTTPS für alle zukünftigen Requests. Verhindert Downgrade-Angriffe.
- Content-Security-Policy (CSP): Definiert, welche Quellen für Scripts, Styles und andere Ressourcen erlaubt sind. Verhindert XSS und Daten-Exfiltration.
- X-Frame-Options: Verhindert Clickjacking-Angriffe, bei denen Ihre Seite in einem unsichtbaren iframe eingebettet wird.
- X-Content-Type-Options: nosniff: Verhindert, dass Browser MIME-Typen "erraten" und dadurch potenziell gefährliche Dateien ausführen.
# Beispiel: Nginx Security Headers
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'" always;
Abhängigkeiten als Sicherheitsrisiko
Moderne Webanwendungen haben oft hunderte von npm-Paketen oder Python-Bibliotheken als Abhängigkeiten. Jede davon ist ein potenzieller Angriffspunkt. Das ist keine Theorie: Der SolarWinds-Angriff und das Log4Shell-Desaster haben Supply-Chain-Angriffe aus der akademischen Diskussion in die Unternehmensrealität gebracht.
Konkrete Maßnahmen:
- npm audit / pip audit: Regelmäßige Prüfung auf bekannte Schwachstellen in Abhängigkeiten. Am besten automatisiert in der CI/CD-Pipeline.
- Dependabot / Renovate: Automatische Pull Requests für Sicherheits-Updates. Halten Sie Abhängigkeiten aktuell.
- Dependency Lockfiles: package-lock.json oder yarn.lock committen — sie verhindern, dass unterschiedliche Versionen auf verschiedenen Systemen installiert werden.
- Minimal Dependencies: Jede Abhängigkeit ist ein Risiko. Brauchen Sie wirklich ein 50 KB-npm-Paket für eine Funktion, die in 5 Zeilen Code selbst implementierbar ist?
Fazit
Web-Sicherheit ist kein einmaliges Projekt — es ist eine kontinuierliche Aufgabe. Die gute Nachricht: Die meisten kritischen Angriffsvektoren sind bekannt und mit klaren, dokumentierten Maßnahmen zu schließen. Wer die OWASP Top 10 als Checkliste nutzt, Abhängigkeiten aktuell hält und Security als Teil des Entwicklungsprozesses betrachtet, ist deutlich sicherer aufgestellt als die meisten.
Sicherheit ist keine Frage des Budgets — sie ist eine Frage der Priorisierung.
Möchten Sie Ihre Web-Anwendung auf Sicherheits-Schwachstellen prüfen lassen? Jetzt Kontakt aufnehmen.
Haben Sie Fragen zu diesem Thema? Jetzt Kontakt aufnehmen.