OWASP Top 10 2025 — Complete Guide for SMEs

Was sind die OWASP Top 10?

Das Open Worldwide Application Security Project (OWASP) ist eine gemeinnützige Stiftung, die sich der Verbesserung der Softwaresicherheit widmet. Ihre Leitpublikation, die OWASP Top 10, katalogisiert die zehn kritischsten Sicherheitsrisiken für Webanwendungen. Erstmals 2003 veröffentlicht, ist sie zum De-facto-Standard für das Bewusstsein für Webanwendungssicherheit geworden.

Die Ausgabe 2025 basiert auf Daten von über 500.000 Anwendungen und Beiträgen von Hunderten von Sicherheitsexperten. Für KMU sind diese Risiken nicht theoretisch — sie stellen die exakten Angriffsvektoren dar, die bei der Mehrheit realer Sicherheitsverletzungen verwendet werden. Laut Verizons 2024 Data Breach Investigations Report betrafen 83 % der Verletzungen externe Akteure, die Schwachstellen in Webanwendungen ausnutzten, die direkt auf die OWASP Top 10 abbildbar sind.

A01: Fehlerhafte Zugriffskontrolle

Was ist das:Die Zugriffskontrolle setzt Richtlinien durch, damit Benutzer nicht außerhalb ihrer vorgesehenen Berechtigungen handeln können. Wenn diese Kontrollen versagen, können Angreifer Daten anderer Benutzer einsehen, Datensätze ändern oder ihre Privilegien auf Administratorebene erhöhen.

Auswirkungen in der Praxis:2023 hat ein großer australischer Telekommunikationsanbieter 10 Millionen Kundendatensätze offengelegt, weil ein fehlerhafter API-Endpunkt die Identität des Anfragenden nicht überprüfte. Der Angreifer iterierte einfach durch Kunden-IDs in der URL. Die durchschnittlichen Kosten einer Verletzung durch fehlerhafte Zugriffskontrolle betragen 4,35 Millionen US-Dollar (IBM Cost of a Data Breach Report 2024).

Wie prüft man:Testen Sie, ob authentifizierte Benutzer auf Ressourcen anderer Benutzer zugreifen können, indem sie URL-Parameter, API-Request-Bodies oder Cookies ändern. Überprüfen Sie, dass Administrationsfunktionen für reguläre Benutzer nicht zugänglich sind.

Wie behebt man:Implementieren Sie serverseitige Zugriffskontrollprüfungen bei jeder Anfrage. Verwenden Sie standardmäßige Ablehnungsrichtlinien. Erzwingen Sie die Datensatzzugehörigkeit auf Datenbankabfrageebene (z.B. immer nach authentifizierter Benutzer-ID filtern). Deaktivieren Sie Verzeichnisauflistungen und stellen Sie sicher, dass Metadatendateien (.git, .env) nicht zugänglich sind.

A02: Kryptographische Fehler

Was ist das:Früher als "Exposition sensibler Daten" bezeichnet, deckt diese Kategorie Fehler in der Kryptographie ab, die zur Offenlegung sensibler Daten führen. Dazu gehören die Übertragung von Daten im Klartext, die Verwendung veralteter Algorithmen (MD5, SHA1 für Passwörter), schwache Schlüsselgenerierung und unsachgemäße Zertifikatsvalidierung.

Auswirkungen in der Praxis:Die MOVEit-Verletzung 2024 betraf über 2.600 Organisationen wegen unzureichender Verschlüsselung ruhender Daten. Gesundheitsorganisationen sind besonders gefährdet: HIPAA-Verstöße aufgrund kryptographischer Fehler haben zu Geldstrafen von über 10 Millionen US-Dollar geführt.

Wie prüft man:Überprüfen Sie, dass alle Daten im Transit TLS 1.2 oder höher verwenden. Überprüfen Sie, dass Passwörter mit bcrypt, scrypt oder Argon2 gehasht sind. Stellen Sie sicher, dass keine sensiblen Daten im Klartext in Datenbanken oder Protokollen gespeichert sind. Suchen Sie nach abgelaufenen oder selbstsignierten Zertifikaten.

Wie behebt man:Erzwingen Sie überall HTTPS mit HSTS-Headern (einschließlich Subdomains). Verwenden Sie moderne Hashing-Algorithmen für Passwörter. Verschlüsseln Sie sensible ruhende Daten mit AES-256. Rotieren Sie Verschlüsselungsschlüssel regelmäßig. Protokollieren Sie niemals sensible Daten wie Passwörter, Token oder Kreditkartennummern.

A03: Injection

Was ist das:Injection-Schwachstellen treten auf, wenn nicht vertrauenswürdige Daten als Teil eines Befehls oder einer Abfrage an einen Interpreter gesendet werden. SQL-Injection, NoSQL-Injection, OS-Befehlsinjektion und LDAP-Injection sind die häufigsten Varianten. Cross-Site Scripting (XSS) wird in der Ausgabe 2025 ebenfalls hier eingeordnet.

Auswirkungen in der Praxis:SQL-Injection bleibt die am häufigsten ausgenutzte Schwachstellenklasse. Die Fortra GoAnywhere-Verletzung 2024 nutzte eine Deserialisierungs-Injection, um über 130 Organisationen zu kompromittieren. XSS-Angriffe machten 27 % aller gemeldeten Webanwendungsschwachstellen im Jahr 2024 aus (HackerOne Annual Report).

Wie prüft man:Testen Sie alle Benutzereingaben (Formulare, URL-Parameter, Header, Cookies) mit Injection-Payloads. Verwenden Sie automatisierte Scanner, um reflektiertes und gespeichertes XSS zu erkennen. Überprüfen Sie, dass API-Endpunkte unerwartete Datentypen ablehnen.

Wie behebt man:Verwenden Sie ausschließlich parametrisierte Abfragen oder Prepared Statements — verketten Sie niemals Benutzereingaben in Abfragen. Validieren und bereinigen Sie alle Eingaben serverseitig mit strikten Schemas (Zod, Joi). Implementieren Sie Content Security Policy (CSP)-Header zur XSS-Minderung. Verwenden Sie ORMs mit integrierter Parametrisierung (Prisma, Drizzle).

A04: Unsicheres Design

Was ist das:Eine 2021 eingeführte neue Kategorie. Unsicheres Design bezieht sich auf Fehler in der Architektur und im Design einer Anwendung, die nicht allein durch die Implementierung behoben werden können. Dazu gehören fehlende Bedrohungsmodellierung, unsichere Geschäftslogik und mangelnde Defense-in-Depth.

Auswirkungen in der Praxis:Ein europäisches Fintech verlor 2,3 Millionen Euro, als Angreifer einen Geschäftslogikfehler in ihrem Zahlungsfluss ausnutzten — die Anwendung erlaubte negative Transaktionsbeträge, wodurch Angreifer Geld auf sich selbst überweisen konnten. Keine noch so gute Eingabevalidierung hätte dies ohne ordnungsgemäße Bedrohungsmodellierung erkannt.

Wie prüft man:Überprüfen Sie die Anwendungsarchitektur auf Defense-in-Depth. Stellen Sie sicher, dass Sicherheitsanforderungen vor der Entwicklung definiert wurden. Prüfen Sie die Ratenbegrenzung bei kritischen Funktionen (Anmeldung, Passwort-Zurücksetzung, Zahlung). Bewerten Sie, ob eine Bedrohungsmodellierung durchgeführt wurde.

Wie behebt man:Integrieren Sie Sicherheit von der Designphase an. Führen Sie Bedrohungsmodellierungen mit STRIDE- oder PASTA-Methodologien durch. Definieren Sie Missbrauchsfälle parallel zu Anwendungsfällen. Implementieren Sie Ratenbegrenzung, Circuit Breaker und Transaktionslimits. Trennen Sie Mandanten und Vertrauensebenen architektonisch.

A05: Sicherheitsfehlkonfiguration

Was ist das:Das am häufigsten in der Praxis beobachtete Problem. Dazu gehören Standard-Zugangsdaten, offener Cloud-Speicher, unnötig aktivierte Funktionen, unvollständige Konfigurationen, zu permissive CORS-Einstellungen, fehlende Sicherheitsheader und ausführliche Fehlermeldungen, die Stack-Traces offenlegen.

Auswirkungen in der Praxis:2024 wurden Tausende von Organisationen durch falsch konfigurierte S3-Buckets, exponierte Docker-APIs und Standard-Kubernetes-Dashboard-Zugangsdaten kompromittiert. Microsofts Sicherheitsbericht 2024 stellte fest, dass 80 % der Cloud-Verletzungen auf Fehlkonfigurationen zurückgingen, nicht auf Zero-Day-Exploits.

Wie prüft man:Scannen Sie nach fehlenden Sicherheitsheadern (X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security, Content-Security-Policy, Permissions-Policy). Testen Sie auf Standard-Zugangsdaten. Überprüfen Sie, dass Fehlerseiten keine Stack-Traces oder internen Pfade preisgeben. Prüfen Sie, dass unnötige HTTP-Methoden (TRACE, OPTIONS) deaktiviert sind.

Wie behebt man:Implementieren Sie eine Härtungscheckliste für jedes Deployment. Setzen Sie umfassende Sicherheitsheader. Deaktivieren Sie Verzeichnisauflistungen, Standardkonten und Debug-Modi in der Produktion. Verwenden Sie Infrastructure-as-Code, um konsistente Konfigurationen durchzusetzen. Automatisieren Sie Konfigurationsaudits mit Tools wie WarDek.

A06: Verwundbare und veraltete Komponenten

Was ist das:Anwendungen, die Bibliotheken, Frameworks oder andere Softwaremodule mit bekannten Schwachstellen verwenden. Dazu gehören ungepatchte Betriebssysteme, Webserver, Datenbankmanagementsysteme, APIs und alle Komponenten einschließlich Bibliotheken, Frameworks und anderer Softwaremodule.

Auswirkungen in der Praxis:Die Log4Shell-Schwachstelle (CVE-2021-44228) in Apache Log4j betraf weltweit Millionen von Anwendungen. 2024 zeigten kritische Schwachstellen in XZ Utils (CVE-2024-3094), wie Supply-Chain-Angriffe über Open-Source-Abhängigkeiten ganze Ökosysteme kompromittieren können. Synopsys berichtete, dass 84 % der Codebasen mindestens eine bekannte Schwachstelle in Open-Source-Komponenten enthalten.

Wie prüft man:Führen Sie ein Software-Komponentenverzeichnis (SBOM). Führen Sie regelmäßig Abhängigkeitsaudits durch (npm audit, pip-audit, Trivy). Überwachen Sie Schwachstellendatenbanken (NVD, GitHub Advisory Database) für verwendete Komponenten. Überprüfen Sie, dass keine End-of-Life-Komponenten eingesetzt werden.

Wie behebt man:Automatisieren Sie Abhängigkeitsaktualisierungen mit Tools wie Dependabot oder Renovate. Entfernen Sie ungenutzte Abhängigkeiten. Abonnieren Sie Sicherheitshinweise für kritische Komponenten. Pinnen Sie exakte Abhängigkeitsversionen in der Produktion. Testen Sie Updates im Staging vor dem Deployment.

A07: Identifikations- und Authentifizierungsfehler

Was ist das:Schwächen in Authentifizierungsmechanismen, die es Angreifern ermöglichen, Passwörter, Sitzungstoken zu kompromittieren oder Implementierungsfehler auszunutzen, um die Identität anderer Benutzer anzunehmen. Dazu gehören Credential Stuffing, Brute-Force-Angriffe, schwache Passwortrichtlinien und unsachgemäßes Sitzungsmanagement.

Auswirkungen in der Praxis:Credential-Stuffing-Angriffe kosten Unternehmen schätzungsweise 6 Milliarden US-Dollar jährlich (Akamai 2024 State of the Internet Report). Die 23andMe-Verletzung 2023 kompromittierte 6,9 Millionen Benutzerprofile durch Credential Stuffing mit Zugangsdaten, die aus anderen Datenlecks stammten.

Wie prüft man:Testen Sie auf schwache Passwortrichtlinien (Mindestlänge, Komplexität). Überprüfen Sie die Kontosperrung nach fehlgeschlagenen Versuchen. Prüfen Sie, dass Sitzungstoken bei der Abmeldung ungültig gemacht werden. Testen Sie auf Session-Fixation und unsichere Sitzungsspeicherung. Überprüfen Sie, dass Multi-Faktor-Authentifizierung verfügbar ist.

Wie behebt man:Implementieren Sie Multi-Faktor-Authentifizierung (MFA). Verwenden Sie bewährte Authentifizierungsbibliotheken (Better Auth, NextAuth, Auth0). Erzwingen Sie starke Passwortrichtlinien (mindestens 12 Zeichen). Begrenzen Sie die Rate der Anmeldeversuche. Machen Sie Sitzungen bei Passwortänderungen ungültig. Speichern Sie Sitzungstoken in HttpOnly- und Secure-Cookies.

A08: Software- und Datenintegritätsfehler

Was ist das:Code und Infrastruktur, die nicht vor Integritätsverletzungen schützen. Dazu gehören die Verwendung von Software-Updates ohne Verifizierung, unsichere CI/CD-Pipelines und die Deserialisierung nicht vertrauenswürdiger Daten. Supply-Chain-Angriffe fallen voll in diese Kategorie.

Auswirkungen in der Praxis:Die SolarWinds-Verletzung (2020) und die Codecov-Bash-Uploader-Kompromittierung (2021) sind Lehrbuchbeispiele für Supply-Chain-Angriffe. 2024 zeigte die XZ-Utils-Backdoor (CVE-2024-3094), dass sogar Kern-Linux-Dienstprogramme durch Social Engineering der Maintainer kompromittiert werden können. Diese Angriffe betreffen gleichzeitig Tausende von nachgelagerten Organisationen.

Wie prüft man:Überprüfen Sie, dass Software-Updates über signierte Kanäle bereitgestellt werden. Prüfen Sie CI/CD-Pipelines auf unsignierte Skripte oder Abhängigkeiten, die ohne Integritätsprüfung bezogen werden. Auditieren Sie die Subresource Integrity (SRI) für extern geladene Skripte und Stylesheets.

Wie behebt man:Überprüfen Sie digitale Signaturen auf allen Software-Updates. Implementieren Sie Subresource Integrity (SRI)-Hashes für CDN-gehostete Assets. Sichern Sie CI/CD-Pipelines mit signierten Commits und geschützten Branches. Verwenden Sie Lockfiles und überprüfen Sie Prüfsummen für Abhängigkeiten. Vermeiden Sie die Deserialisierung nicht vertrauenswürdiger Daten.

A09: Fehler bei Sicherheitsprotokollierung und -überwachung

Was ist das:Unzureichende Protokollierung, Erkennung, Überwachung und aktive Reaktion. Ohne angemessene Protokollierung können Verletzungen nicht erkannt werden, und ohne Überwachung werden protokollierte Ereignisse nie überprüft. Die durchschnittliche Zeit zur Erkennung einer Verletzung beträgt 204 Tage (IBM 2024), größtenteils aufgrund unzureichender Überwachung.

Auswirkungen in der Praxis:Die Equifax-Verletzung blieb 78 Tage unentdeckt, obwohl der Einbruch in Protokollen sichtbar war, die niemand überprüfte. Organisationen mit ordnungsgemäßer Sicherheitsüberwachung erkennen Verletzungen durchschnittlich 68 Tage schneller, was die Kosten um 1,76 Millionen US-Dollar reduziert (IBM 2024).

Wie prüft man:Überprüfen Sie, dass Anmeldeversuche (erfolgreiche und fehlgeschlagene) protokolliert werden. Prüfen Sie, dass Zugriffskontrollfehler Alarme auslösen. Stellen Sie sicher, dass Protokolle sicher gespeichert sind und nicht manipuliert werden können. Überprüfen Sie, dass Protokolldaten für einen ausreichenden Zeitraum aufbewahrt werden (mindestens 90 Tage, vorzugsweise 12 Monate).

Wie behebt man:Protokollieren Sie alle Authentifizierungsereignisse, Zugriffskontrollfehler und serverseitige Eingabevalidierungsfehler. Verwenden Sie strukturierte Protokollierung (JSON-Format) für maschinenlesbare Analyse. Implementieren Sie Alarmierung für verdächtige Muster (mehrfache fehlgeschlagene Anmeldungen, Versuche zur Privilegienerhöhung). Speichern Sie Protokolle zentral mit Manipulationsschutz. Protokollieren Sie niemals sensible Daten (Passwörter, Token, PII).

A10: Server-Side Request Forgery (SSRF)

Was ist das:SSRF-Schwachstellen treten auf, wenn eine Webanwendung eine Remote-Ressource abruft, ohne die vom Benutzer bereitgestellte URL zu validieren. Angreifer können den Server zwingen, Anfragen an interne Dienste, Cloud-Metadaten-Endpunkte oder externe Systeme zu stellen, wobei häufig Firewalls und Zugriffskontrollen umgangen werden.

Auswirkungen in der Praxis:Die Capital One-Verletzung (2019) nutzte eine SSRF-Schwachstelle, um auf AWS-Metadaten zuzugreifen und 100 Millionen Kundendatensätze zu stehlen. In Cloud-Umgebungen ist SSRF besonders gefährlich, da der Cloud-Metadaten-Endpunkt (169.254.169.254) Zugriff auf IAM-Zugangsdaten bietet, die zum Zugriff auf jede Cloud-Ressource verwendet werden können, die die Instanz erreichen darf.

Wie prüft man:Testen Sie alle URL-Eingabefelder auf SSRF, indem Sie interne Adressen einreichen (127.0.0.1, 169.254.169.254, interne Hostnamen). Prüfen Sie, ob die Anwendung Weiterleitungen folgt, die zu internen Adressen aufgelöst werden. Überprüfen Sie, dass ein DNS-Rebinding-Schutz vorhanden ist.

Wie behebt man:Validieren und bereinigen Sie alle URLs serverseitig. Implementieren Sie Allowlists für erlaubte Domänen und Protokolle. Blockieren Sie Anfragen an private IP-Bereiche (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) und Cloud-Metadaten-Endpunkte. Deaktivieren Sie HTTP-Weiterleitungen oder validieren Sie Weiterleitungsziele. Verwenden Sie Netzwerksegmentierung, um den ausgehenden Datenverkehr des Servers zu begrenzen.

Warum KMU besonders gefährdet sind

Kleine und mittlere Unternehmen stehen vor einer überproportionalen Sicherheitsherausforderung. Obwohl sie wertvolle Kundendaten besitzen und Finanztransaktionen verarbeiten, fehlen ihnen in der Regel dedizierte Sicherheitsteams. Laut dem Hiscox Cyber Readiness Report 2024:

• 43 % der Cyberangriffe zielen auf kleine Unternehmen
• 60 % der KMU, die von einer Verletzung betroffen sind, schließen innerhalb von 6 Monaten
• Die durchschnittlichen Kosten einer Verletzung für ein KMU betragen 108.000 $
• Nur 14 % der KMU verfügen über einen formalen Plan zur Vorfallreaktion

Die gute Nachricht ist, dass die Behandlung der OWASP Top 10 den überwiegenden Teil der Angriffsfläche eliminiert. Die meisten Schwachstellen in diesen Kategorien können automatisch erkannt und durch Konfigurationsanpassungen oder geringfügige Code-Änderungen behoben werden — kein sechsstelliges Sicherheitsbudget erforderlich.

Erste Schritte mit OWASP-Compliance

Der effektivste Ansatz für KMU ist, mit automatisierten Scans zu beginnen, um die kritischsten Probleme zu identifizieren, und dann Korrekturen nach Risiko zu priorisieren. Hier ist ein praxisnaher Drei-Schritte-Ansatz:

1. Scannen:Führen Sie einen automatisierten Sicherheitsscan durch, um fehlende Header, TLS-Probleme, verwundbare Komponenten und häufige Fehlkonfigurationen zu identifizieren. Dies deckt A02, A05, A06 sowie teilweise A03 und A10 ab.
2. Kritische Probleme zuerst beheben:Beheben Sie Sicherheitsheader, aktivieren Sie HTTPS mit HSTS, aktualisieren Sie verwundbare Abhängigkeiten und überprüfen Sie die Authentifizierungskonfiguration. Dies sind typischerweise Konfigurationsänderungen, die Stunden, nicht Wochen dauern.
3. Sicherheit in Ihren Prozess integrieren:Integrieren Sie automatisiertes Scanning in Ihre CI/CD-Pipeline, planen Sie regelmäßige Abhängigkeitsaktualisierungen und führen Sie vierteljährliche Sicherheitsüberprüfungen durch. Prävention ist immer günstiger als Behebung.