OWASP Top 10:2025 für Entscheider: zehn Risiken, zehn Fragen an Ihr Team

Was die OWASP Top 10 sind und was nicht

Das Open Worldwide Application Security Project (OWASP) ist eine gemeinnützige Stiftung. Ihre bekannteste Veröffentlichung ist die OWASP Top 10: eine Liste der zehn wichtigsten Sicherheitsrisiken für Webanwendungen. Sie beruht auf Testdaten, die Unternehmen und Prüfer beisteuern, und auf einer Umfrage unter Fachleuten.

Die OWASP selbst nennt die Liste ein Aufklärungsdokument. Sie soll Entwicklern, Architekten und Führungskräften zeigen, wo die größten Risiken liegen. Was sie nicht ist:

• Keine Zertifizierung. Es gibt kein OWASP-Siegel und keine OWASP-Konformität. Wer Ihnen eine verkaufen will, verkauft etwas anderes.
• Kein vollständiger Prüfkatalog. Für detaillierte Anforderungen gibt es den OWASP Application Security Verification Standard (ASVS).
• Kein Gesetz. Aber ein verbreiteter Maßstab dafür, was „Stand der Technik“ bei Webanwendungen bedeutet.

Für Sie als Entscheider ist die Liste trotzdem nützlich: Sie zeigt in zehn Punkten, wo Anwendungen am häufigsten und am folgenreichsten verwundbar sind. Und sie gibt Ihnen eine gemeinsame Sprache mit Ihrem Team und Ihren Dienstleistern.

Was sich 2025 geändert hat

Die Ausgabe 2025 löst die Version von 2021 ab. Laut OWASP gibt es zwei neue Kategorien und eine Zusammenlegung:

• Neu: Fehler in der Software-Lieferkette (A03). Sie erweitert die frühere Kategorie „veraltete Komponenten“ um alles, was zwischen Abhängigkeiten, Build-Systemen und Auslieferung schiefgehen kann. Die Fachleute in der Umfrage stimmten mit großer Mehrheit dafür.
• Neu: Fehlerhafter Umgang mit Ausnahmesituationen (A10). Fehlerbehandlung, Logikfehler und Systeme, die bei Störungen „offen“ statt „geschlossen“ ausfallen.
• Zusammengelegt: Server-Side Request Forgery (SSRF), 2021 noch eine eigene Kategorie, gehört jetzt zur fehlerhaften Zugriffskontrolle (A01).
• Aufgestiegen: Sicherheitsrelevante Fehlkonfiguration springt von Platz 5 auf Platz 2. Immer mehr Verhalten einer Anwendung steckt in Konfiguration statt in Code.

Die Grundlage ist breiter geworden: OWASP hat 589 Schwachstellentypen (CWE) ausgewertet, 2021 waren es knapp 400. Acht Kategorien stammen aus den Daten, zwei aus der Umfrage, weil manche Risiken in Testdaten kaum auftauchen.

Für Sie bedeutet das: Wenn Ihr letzter Sicherheitsbericht noch nach der Liste von 2021 gegliedert ist, fehlen darin vor allem die Lieferkette und der Umgang mit Ausnahmesituationen. Beides lohnt einen eigenen Blick, gerade bei Software mit vielen Abhängigkeiten oder mit Code aus KI-Assistenten.

Die zehn Risiken im Überblick

Zu jedem Risiko finden Sie drei Dinge: was es ist, was es Ihr Unternehmen kosten kann, und die eine Frage, die Sie Ihrem Team stellen sollten. Alle Beispiele sind fiktiv.

A01: Fehlerhafte Zugriffskontrolle

Was es ist: Nutzer können Daten sehen oder Aktionen ausführen, für die sie keine Berechtigung haben.

Was es kostet (Beispiel, fiktiv): Ein Kundenportal zeigt Rechnungen unter einer fortlaufenden Nummer. Ein Kunde ändert die Zahl in der Adresszeile und sieht die Rechnungen anderer Kunden. Es folgen eine Meldung an die Datenschutzaufsicht, Schreiben an alle Betroffenen und ein Großkunde, der seinen Vertrag überprüft.

Die Frage an Ihr Team: „Prüft unser Server bei jedem Zugriff, ob dieser Nutzer genau diesen Datensatz sehen darf, oder verlassen wir uns darauf, dass niemand die Adresse ändert?“

A02: Sicherheitsrelevante Fehlkonfiguration

Was es ist: Unsichere Standardeinstellungen, offene Verwaltungsoberflächen, ausführliche Fehlermeldungen oder fehlende Schutzmechanismen in Server, Framework oder Cloud.

Was es kostet (Beispiel, fiktiv): Ein Speicher-Bucket mit Backups ist versehentlich öffentlich lesbar. Niemand bemerkt es, bis ein Sicherheitsforscher sich meldet. Ob vorher schon jemand anderes die Daten geladen hat, lässt sich nicht mehr klären.

Die Frage an Ihr Team: „Wer prüft, ob unsere Konfiguration in Produktion so sicher ist wie geplant, und wie oft?“

A03: Fehler in der Software-Lieferkette

Was es ist: Schwachstellen oder Schadcode, die über Bibliotheken, Werkzeuge, Build-Systeme oder Updates in Ihre Software gelangen.

Was es kostet (Beispiel, fiktiv): Ein beliebtes Open-Source-Paket erhält ein manipuliertes Update. Ihre Build-Pipeline lädt es automatisch, und ein paar Tage später liefert Ihre Anwendung Schadcode an Ihre eigenen Kunden aus.

Die Frage an Ihr Team: „Wissen wir, welche Komponenten in welcher Version in unserer Software stecken, und wie erfahren wir von einer neuen Lücke darin?“

A04: Kryptografische Fehler

Was es ist: Sensible Daten sind nicht, falsch oder mit veralteten Verfahren verschlüsselt, oder Schlüssel liegen ungeschützt herum.

Was es kostet (Beispiel, fiktiv): Passwörter werden mit einem veralteten Verfahren gespeichert. Nach einem Datenabfluss sind sie innerhalb kurzer Zeit im Klartext lesbar, und weil viele Nutzer Passwörter mehrfach verwenden, trifft der Schaden auch andere Dienste.

Die Frage an Ihr Team: „Welche sensiblen Daten speichern wir, wie sind sie verschlüsselt, und wo liegen die Schlüssel?“

A05: Injection

Was es ist: Eingaben von Nutzern werden als Befehl ausgeführt, etwa als Datenbankabfrage oder als Skript im Browser anderer Nutzer.

Was es kostet (Beispiel, fiktiv): Ein Suchfeld im Online-Shop setzt die Eingabe direkt in eine Datenbankabfrage ein. Ein Angreifer liest darüber die komplette Kundentabelle aus, samt Adressen und Bestellhistorie.

Die Frage an Ihr Team: „Verwenden wir überall parametrisierte Abfragen und eine einheitliche Ausgabekodierung, oder gibt es Stellen, an denen Eingaben direkt weiterverarbeitet werden?“

A06: Unsicheres Design

Was es ist: Die Schwäche steckt nicht in einer Codezeile, sondern im Konzept: Ein Ablauf wurde nie auf Missbrauch hin durchdacht.

Was es kostet (Beispiel, fiktiv): Ein Gutscheinsystem prüft zwar jeden Code, begrenzt aber nicht, wie oft ein Konto Codes ausprobieren darf. Ein Skript findet über Nacht Hunderte gültige Gutscheine.

Die Frage an Ihr Team: „Haben wir für unsere wichtigsten Abläufe überlegt, wie jemand sie missbrauchen könnte, und das dokumentiert?“

A07: Fehler bei der Authentifizierung

Was es ist: Schwächen beim Anmelden und bei Sitzungen: schwache Passwortregeln, fehlender Schutz gegen massenhaftes Ausprobieren, Sitzungen, die nie ablaufen.

Was es kostet (Beispiel, fiktiv): Angreifer testen Zugangsdaten aus fremden Datenlecks automatisiert gegen Ihr Login. Ohne Begrenzung der Versuche übernehmen sie Dutzende Kundenkonten und bestellen auf deren Rechnung.

Die Frage an Ihr Team: „Was passiert, wenn jemand tausendmal pro Minute versucht, sich anzumelden, und bieten wir eine Zwei-Faktor-Anmeldung an?“

A08: Fehler bei der Integrität von Software oder Daten

Was es ist: Die Anwendung vertraut Code, Updates oder Daten, ohne zu prüfen, ob sie unverändert aus einer vertrauenswürdigen Quelle stammen.

Was es kostet (Beispiel, fiktiv): Die Website bindet ein Skript von einem fremden Server ein. Der Server wird kompromittiert, das Skript liest ab sofort Zahlungsdaten im Bestellformular mit.

Die Frage an Ihr Team: „Prüfen wir, dass Updates, Skripte und Daten von außen nicht manipuliert wurden, bevor wir sie verwenden?“

A09: Fehler bei Sicherheitsprotokollierung und Alarmierung

Was es ist: Sicherheitsrelevante Ereignisse werden nicht protokolliert, oder es schaut niemand hin, weil kein Alarm ausgelöst wird.

Was es kostet (Beispiel, fiktiv): Ein Angreifer probiert wochenlang Zugänge aus. Die Logs zeigen es, aber niemand wird benachrichtigt. Den Vorfall bemerken Sie erst, als ein Kunde anruft, und die Frist für die Meldung an die Behörde ist dann schon knapp.

Die Frage an Ihr Team: „Woran würden wir einen laufenden Angriff erkennen, und wer bekommt dann wie schnell eine Nachricht?“

A10: Fehlerhafter Umgang mit Ausnahmesituationen

Was es ist: Die Anwendung reagiert falsch auf Unerwartetes: Fehler werden verschluckt, Prüfungen übersprungen oder interne Details preisgegeben.

Was es kostet (Beispiel, fiktiv): Fällt der Dienst für die Rechteprüfung kurz aus, lässt die Anwendung im Zweifel alle Anfragen durch. Für einige Minuten ist jeder Nutzer Administrator.

Die Frage an Ihr Team: „Was macht unsere Anwendung, wenn ein Dienst, eine Datenbank oder eine Prüfung ausfällt: blockieren oder durchlassen?“

Wie Sie die Antworten Ihres Teams einordnen

Sie müssen die technischen Details nicht verstehen, um gute von schwachen Antworten zu unterscheiden. Drei Muster helfen:

• Gute Antworten sind konkret. „Jede Abfrage läuft über unser Berechtigungsmodul, und es gibt Tests, die prüfen, dass Nutzer A die Daten von B nicht sieht“ ist eine gute Antwort. „Das macht das Framework“ ist eine Hoffnung.
• Gute Antworten nennen einen Prozess. Wer Abhängigkeiten automatisch auf bekannte Lücken prüfen lässt, Updates regelmäßig einspielt und weiß, wer im Ernstfall entscheidet, hat einen Prozess. Wer sagt „Wir aktualisieren, wenn etwas ist“, hat keinen.
• Gute Antworten kennen ihre Grenzen. Ein Team, das sagt „Das haben wir nie geprüft“, ist ehrlich und damit ein guter Ausgangspunkt. Vorsicht ist geboten, wenn jede Frage mit „Das ist bei uns kein Thema“ beantwortet wird.

Achten Sie besonders auf übernommenen Code, etwa von einer Agentur oder aus einem Zukauf, und auf Code, der zu großen Teilen mit KI-Assistenten entstanden ist. In beiden Fällen kennt oft niemand im Team jede Stelle im Detail. Die zehn Fragen zeigen dann schnell, wo Wissen fehlt.

Und noch ein Hinweis: Die Fragen sind kein Misstrauensvotum gegen Ihr Team. Gute Entwickler freuen sich, wenn die Geschäftsführung Sicherheit ernst nimmt, denn dann bekommen sie Zeit und Budget dafür. Stellen Sie die Fragen deshalb offen, nicht als Prüfung. Halten Sie die Antworten schriftlich fest: Sie sind der Ausgangspunkt für jede spätere Prüfung und zeigen in einem Jahr, was sich verbessert hat.

Welche Prüfung welches Risiko findet

Keine einzelne Prüfung deckt alle zehn Risiken ab. Die Tabelle zeigt ehrlich, was welches unserer Pakete sieht. Manche Risiken werden erst in einem Code- oder Architektur-Review sichtbar.

Weitgehend: typische Muster dieser Kategorie werden geprüft. Teilweise: nur einzelne Aspekte sind sichtbar. Keine Prüfung findet jede Schwachstelle einer Kategorie.

Einige Erläuterungen dazu:

• Der Security-Check sieht nur, was jeder Browser sieht: Verschlüsselung, Security-Header, Cookies, offene Dateien und sichtbare Versionen. Das ist ein guter erster Blick, aber hinter dem Login endet er.
• Das App-Audit testet mit zwei Testzugängen, ob Nutzer A die Daten von Nutzer B sieht, ob Sessions sicher sind und ob Eingaben und Schnittstellen angreifbar sind.
• Das Code-Audit findet Ursachen, die von außen unsichtbar sind: Abhängigkeiten mit bekannten Lücken, Schlüssel im Code, fehlende Prüfungen in selten genutzten Pfaden.
• Unsicheres Design und Alarmierung lassen sich nur zum Teil im Code ablesen. Ob ein Ablauf missbrauchbar ist und ob nachts jemand auf einen Alarm reagiert, klärt ein Gespräch über Architektur und Betrieb. Dafür bieten wir für größere Organisationen ein Security-Architektur-Review an.

Das Full Audit kombiniert App- und Code-Audit, die Befunde können sich gegenseitig bestätigen, und ein Experte gibt jeden frei. Wie wir dabei vorgehen, zeigt unsere Methodik.

Wo ein Code-Audit endet und ein Penetrationstest beginnt, zeigt unser Vergleich Code-Audit oder Penetrationstest.

OWASP, NIS2, CRA und DSGVO

Kein Gesetz schreibt die OWASP Top 10 vor. Mehrere Regelwerke verlangen aber Sicherheit nach dem Stand der Technik, und dafür sind die Top 10 ein verbreiteter Maßstab:

• NIS2 verpflichtet betroffene Einrichtungen zu Risikomanagementmaßnahmen, ausdrücklich auch zur Sicherheit bei Entwicklung und Wartung von Systemen und zum Umgang mit Schwachstellen. In Deutschland gilt das seit dem 6. Dezember 2025 über § 30 BSIG; in Frankreich ist die Umsetzung (Stand November 2026) noch im Gesetzgebungsverfahren.
• Der Cyber Resilience Act (CRA) verlangt von Herstellern von Produkten mit digitalen Elementen ab dem 11. Dezember 2027, ohne bekannte ausnutzbare Schwachstellen auszuliefern und Schwachstellen über den gesamten Lebenszyklus zu behandeln. Die Meldepflichten gelten bereits seit dem 11. September 2026, mehr dazu in unserem Artikel zur Meldepflicht nach dem Cyber Resilience Act.
• Art. 32 DSGVO verlangt geeignete technische und organisatorische Maßnahmen und ein Verfahren zur regelmäßigen Überprüfung ihrer Wirksamkeit.

Ein Audit entlang der OWASP Top 10 ist kein Zertifikat und keine Konformitätsbewertung. Es dokumentiert aber, dass Sie Ihre Anwendung nach einem anerkannten Maßstab geprüft und die Befunde priorisiert haben. Danach fragen Kunden, Auditoren und Versicherer nach unserer Erfahrung immer häufiger.

Drei Schritte für diese Woche

1. Den Blick von außen holen. Lassen Sie Ihre wichtigste Website oder Web-App mit unserem kostenlosen Security-Check prüfen. Sie erhalten in der Regel werktags innerhalb von 2 Stunden eine Note von A bis F und die Befunde nach Schweregrad.
2. Drei Fragen stellen. Nehmen Sie die Fragen zu A01, A02 und A03 mit in das nächste Gespräch mit Ihrem Team oder Ihrer Agentur. Wenn die Antworten zögerlich ausfallen, wissen Sie, wo Sie anfangen.
3. Die Prüftiefe festlegen. Für Anwendungen mit Login empfehlen wir das App-Audit für 490 € netto, für eigenen oder übernommenen Code das Code-Audit für 890 € netto. Beides zusammen, mit Expertenprüfung jedes Befunds, ist das Full Audit für 1.690 € netto.

Alle Preise netto zuzüglich Umsatzsteuer. Unsere Angebote richten sich ausschließlich an Unternehmen.

Der erste Schritt kostet nichts

Der Security-Check ist kostenlos und passiv: Wir greifen nichts an und brauchen keinen Login. Er zeigt Ihnen, welche der zehn Risiken schon von außen sichtbar sind, und wir sagen Ihnen danach ehrlich, ob und welches Audit sich für Sie lohnt.

Was ein Audit kostet und wie Sie Angebote vergleichen, lesen Sie in Was kostet ein Code-Audit?

OWASP® ist eine eingetragene Marke der OWASP Foundation. Wir stehen in keiner Verbindung zur OWASP Foundation; sie empfiehlt oder zertifiziert unsere Leistungen nicht.

Dieser Artikel entstand mit Unterstützung automatisierter Recherche und KI. David Kreutzer hat ihn fachlich geprüft und am 4. November 2026 freigegeben.