OWASP Top 10 2025: Die aktualisierte Liste erklärt (A01-A10)

Was die OWASP Top 10 2025 sind und was sich geändert hat

Die OWASP Top 10 sind ein von der Community getragenes Awareness-Dokument, das die kritischsten Sicherheitsrisiken für Webanwendungen einordnet. Gepflegt vom Open Worldwide Application Security Project, werden sie etwa alle drei bis vier Jahre aus eingereichten Anwendungstestdaten und einer Praktikerumfrage aktualisiert. Jede Ausgabe spiegelt daher wider, wie Angreifer tatsächlich vorgehen, statt abstrakter Theorie.

Die Ausgabe 2025 belässt die fehlerhafte Zugriffskontrolle an der Spitze und behandelt weiterhin ganze Schwachstellenkategorien statt einzelner Fehler. Die wichtigsten Verschiebungen sind ein stärkerer Fokus auf unsichere Konfiguration über Cloud und CI/CD hinweg, die Aufwertung des Lieferkettenrisikos über verwundbare Komponenten hinaus und die ausdrückliche Beachtung falsch behandelter Fehler und Ausnahmen, die unbemerkt Daten preisgeben oder offen ausfallen.

Weil so viele Rahmenwerke und Aufsichtsbehörden darauf verweisen, sind die Top 10 zum De-facto-Mindeststandard geworden. Die Auditerwartungen von CERT-In in Indien, die Sicherheitsanforderungen von RBI und SEBI, die EU-Regime NIS2 und DORA sowie US-Sicherheitsfragebögen von Großunternehmen setzen voraus, dass Ihre Anwendungen gegen diese Kategorien getestet wurden. Betrachten Sie die Liste als Mindestumfang, nicht als Ziellinie.

A01: Fehlerhafte Zugriffskontrolle

Die Zugriffskontrolle regelt, was ein authentifizierter Nutzer tun darf. Sie ist fehlerhaft, wenn ein Nutzer außerhalb seiner Berechtigungen handeln kann: Datensätze anderer Kunden durch Ändern einer ID in der URL einsehen, zu einer Administratorrolle aufsteigen oder APIs erreichen, die gesperrt sein sollten. Sie ist über die letzten Ausgaben hinweg die häufigste und schädlichste Kategorie geblieben.

Gegenmaßnahme: standardmäßig verweigern und die Autorisierung bei jeder Anfrage serverseitig durchsetzen, dabei die Eigentümerschaft des konkret angefragten Objekts prüfen, statt vom Client gelieferten Identifikatoren oder versteckten Feldern zu vertrauen.

A02: Sicherheitsrelevante Fehlkonfiguration

Fehlkonfiguration umfasst unsichere Standardeinstellungen, aktiv belassene überflüssige Funktionen, ausführliche Fehlerseiten, fehlende Sicherheits-Header, offenen Cloud-Speicher sowie ungepatchte oder überprivilegierte Dienste. Die Ausgabe 2025 gewichtet sie stärker, weil die Ausbreitung von Cloud, Containern und CI/CD die Zahl der Stellen vervielfacht, an denen eine einzige schwache Einstellung Daten preisgeben kann.

Gegenmaßnahme: gehärtete, wiederholbare Konfigurationsbasislinien als Code aufbauen, ungenutzte Komponenten und Standardkonten entfernen und laufende Umgebungen kontinuierlich scannen, damit Abweichungen erkannt und nicht von einem Angreifer entdeckt werden.

A03: Fehler in der Software-Lieferkette

Diese Kategorie erweitert das frühere Risiko „verwundbare und veraltete Komponenten“ auf die gesamte Software-Lieferkette: Drittanbieterbibliotheken, Basis-Images, Build-Werkzeuge, Paketregister und die Pipelines, die alles zusammenfügen. Eine kompromittierte Abhängigkeit oder ein manipulierter Build-Schritt kann Schadcode in Ihre Anwendung bringen, bevor sie überhaupt in Produktion geht.

Gegenmaßnahme: eine Software-Stückliste (SBOM) pflegen, Abhängigkeiten fixieren und verifizieren und die Build-Pipeline selbst absichern, sodass nur geprüfte, integritätsgesicherte Artefakte in die Freigabe gelangen.

A04: Kryptografische Fehler

Kryptografische Fehler entstehen, wenn sensible Daten — Passwörter, Zahlungsdaten, Gesundheitsdaten, personenbezogene Daten nach DSGVO oder Indiens DPDP-Gesetz — bei der Übertragung oder Speicherung nicht angemessen geschützt sind. Typische Ursachen sind fehlende Verschlüsselung, schwache oder veraltete Algorithmen, fest im Code hinterlegte Schlüssel und mangelhaftes Schlüsselmanagement.

Gegenmaßnahme: Daten klassifizieren, überall starke Transportverschlüsselung durchsetzen, sensible Daten mit aktuellen Algorithmen im Ruhezustand verschlüsseln und Schlüssel in einem dedizierten Secret- oder Key-Management-Dienst verwalten statt in Code oder Konfigurationsdateien.

A05: Injection

Injection tritt auf, wenn nicht vertrauenswürdige Eingaben als Befehl oder Abfrage interpretiert werden und ein Angreifer so die Programmlogik verändern kann. SQL-Injection, NoSQL-Injection, Betriebssystem-Befehlsinjektion und Cross-Site-Scripting gehören hierher: Die Anwendung vermischt Daten und Anweisungen, statt sie zu trennen.

Gegenmaßnahme: parametrisierte Abfragen und sichere APIs verwenden, die Eingaben als Daten binden, Eingaben gegen strenge Positivlisten validieren und Ausgaben kontextgerecht kodieren, damit von Nutzern gelieferte Inhalte niemals ausgeführt werden können.

A06: Unsicheres Design

Unsicheres Design ist ein Fehler der Architektur selbst, nicht der Implementierung. Selbst perfekt geschriebener Code kann eine Sicherheitsmaßnahme nicht ersetzen, die nie vorgesehen wurde, etwa eine fehlende Ratenbegrenzung in einem Überweisungsprozess oder ein Passwort-Zurücksetzen, das sich zur Kontoübernahme missbrauchen lässt.

Gegenmaßnahme: Bedrohungsmodellierung früh anwenden, Sicherheits- und Missbrauchsfallanforderungen gleichrangig zu funktionalen definieren und sichere Entwurfsmuster nutzen, damit die richtigen Maßnahmen von vornherein vorhanden sind statt später angeflanscht.

A07: Fehler bei der Authentifizierung

Authentifizierungsfehler erlauben Angreifern, Identitäten über schwachen Umgang mit Zugangsdaten zu kompromittieren: schwache oder geleakte Passwörter zulassen, fehlender Brute-Force-Schutz, vorhersagbare oder schlecht invalidierte Sitzungstoken und fehlende Mehr-Faktor-Authentifizierung. Die Folge sind Kontoübernahmen und Credential Stuffing im großen Stil.

Gegenmaßnahme: Mehr-Faktor-Authentifizierung erzwingen, Passwörter gegen bekannte Leak-Listen prüfen, Authentifizierungsendpunkte ratenbegrenzen und überwachen und Sitzungstoken serverseitig sicher erzeugen, rotieren und invalidieren.

A08: Integritätsfehler bei Software und Daten

Integritätsfehler entstehen, wenn Code oder kritischen Daten vertraut wird, ohne zu prüfen, ob sie manipuliert wurden: unsignierte automatische Updates, unsichere Deserialisierung nicht vertrauenswürdiger Objekte oder CI/CD-Schritte, die Artefakte ohne Integritätsprüfung beziehen. Wer eine vertrauenswürdige Quelle ersetzen kann, übernimmt die Kontrolle über die Anwendung.

Gegenmaßnahme: Integrität und Herkunft von Code, Updates und Daten mit digitalen Signaturen prüfen und nicht vertrauenswürdige Eingaben niemals ohne strenge Typkontrollen und Validierung deserialisieren.

A09: Fehler bei Protokollierung und Alarmierung

Diese Kategorie umfasst unzureichende Protokollierung, Überwachung und Alarmierung, der Grund, warum so viele Sicherheitsvorfälle monatelang unentdeckt bleiben. Werden fehlgeschlagene Anmeldungen, Verstöße gegen die Zugriffskontrolle und hochwertige Transaktionen nicht protokolliert und keine Alarme ausgelöst, bleibt ein laufender Angriff für Verteidiger unsichtbar.

Gegenmaßnahme: sicherheitsrelevante Ereignisse mit genug Kontext für Untersuchungen protokollieren, diese Protokolle zentralisieren und schützen und sie an Echtzeitalarmierung und einen Incident-Response-Prozess anbinden, eine Pflicht, die durch CERT-Ins Vorgabe zur 180-tägigen Protokollaufbewahrung in Indien verstärkt wird.

A10: Fehlerhafter Umgang mit Ausnahmesituationen

Die Ausgabe 2025 richtet den Blick ausdrücklich darauf, wie Anwendungen Fehler und Ausnahmesituationen behandeln. Schlechte Fehlerbehandlung kann Stack-Traces, interne Pfade und Konfigurationsdetails an Angreifer preisgeben oder die Logik offen ausfallen lassen, sodass Zugriff gewährt wird, wenn eine Prüfung fehlschlägt, statt ihn zu verweigern. Beides macht aus einem Randfall ein Sicherheitsereignis.

Gegenmaßnahme: sicher und geschlossen ausfallen, Nutzern generische Fehlermeldungen zurückgeben und die vollständigen Details serverseitig protokollieren sowie außergewöhnliche und unerwartete Eingaben bewusst testen, nicht nur den Normalfall.

Wie IntelligenceX unterstützt

Die OWASP Top 10 2025 sind eine Landkarte, wo zu suchen ist, doch Abdeckung zählt nur, wenn Ihre Anwendungen tatsächlich dagegen getestet werden. IntelligenceX bewertet jede Kategorie mit überwiegend manuellen Leistungen nach OWASP und liefert entwicklungsreife Empfehlungen zur Behebung, ein Vorgehen, das zu Kunden in Großbritannien, den USA, der EU und Indien passt.

Unsere Penetrationstests für Webanwendungen prüfen jede Top-10-Kategorie an Ihrer produktiven Anwendung, von fehlerhafter Zugriffskontrolle und Injection bis zu Protokollierungs- und Ausnahmefehlern, mit Proof-of-Concept-Nachweisen und einem kostenlosen Nachtest. Unsere sichere Code-Review untersucht den Quelltext selbst und findet kryptografische, Injection- und Integritätsfehler, die Blackbox-Tests übersehen können. Unsere Bedrohungsmodellierung geht A06 Unsicheres Design direkt an und deckt fehlende Maßnahmen auf, bevor sie überhaupt in Code gegossen werden.

Für Organisationen unter indischer Regulierung fügen sich diese Tests unmittelbar in die Sicherheitspflichten des DPDP-Gesetzes und die Erwartungen von CERT-In, RBI, SEBI und IRDAI ein. Zur Klarstellung des Umfangs: IntelligenceX berät, bewertet und bereitet vor und ist derzeit nicht CERT-In-zugelassen; wir stellen keine Zertifikate aus und unterzeichnen keine Aufsichtsaudits. Sprechen Sie mit unserem Team, um eine Bewertung Ihrer Anwendungen zu definieren.