OWASP Top 10 verständlich erklärt

Eine neue Web-Anwendung geht live, die fachlichen Tests sind bestanden und der Zeitplan drängt. Doch kurz nach dem Start stellt sich heraus, dass eingeloggte Nutzende Daten anderer Mandanten sehen können oder ein veraltetes Framework eine bekannte Schwachstelle enthält. Solche Probleme entstehen selten durch spektakuläre Einzelfehler. Häufig fehlen klare Sicherheitsanforderungen, wirksame Prüfungen und feste Verantwortlichkeiten. Die OWASP Top 10 helfen dir, diese Risiken systematisch einzuordnen.

Die OWASP Top 10 sind eine regelmäßig aktualisierte Übersicht der wichtigsten Risiken für Web-Anwendungen. OWASP steht für Open Worldwide Application Security Project, eine internationale Initiative für Anwendungssicherheit. Die Liste ist kein vollständiger Sicherheitsstandard und ersetzt weder Risikoanalysen noch Penetrationstests. Sie bietet aber einen sehr praxistauglichen Rahmen, um Entwicklung, Betrieb und Sicherheitsprüfungen auf die häufigsten Fehlerquellen auszurichten.

Was die OWASP Top 10 für dein Unternehmen leisten

Die verbreitete Fassung aus dem Jahr 2021 ordnet technische Schwachstellen und organisatorische Ursachen zusammen. Das ist wichtig: Viele Sicherheitsprobleme entstehen nicht nur durch fehlerhaften Code, sondern auch durch unklare Architekturentscheidungen, fehlende Updates oder unzureichende Überwachung.

Für IT-Verantwortliche sind die OWASP Top 10 besonders nützlich, weil sie gemeinsame Sprache schaffen. Entwickelnde, Administration, Fachbereiche und Management können anhand derselben Kategorien besprechen, welche Risiken bestehen und welche Maßnahmen Vorrang haben.

Dabei gilt: Nicht jedes Risiko hat für jede Anwendung dieselbe Bedeutung. Ein öffentliches Kundenportal, ein internes Verwaltungswerkzeug und eine Anwendung zur Verarbeitung sensibler Gesundheitsdaten brauchen unterschiedliche Schutzmaßnahmen. Berücksichtige deshalb Schutzbedarf, Datenarten, erreichbare Systeme und mögliche Folgen eines Vorfalls.

Die zehn Risiken im Überblick

OWASP-Risiko	Was dahintersteckt	Wichtige Schutzmaßnahme
A01 Broken Access Control	Berechtigungen werden unvollständig oder fehlerhaft geprüft.	Serverseitige Autorisierung und Least Privilege konsequent umsetzen.
A02 Cryptographic Failures	Sensible Daten sind unzureichend verschlüsselt oder falsch geschützt.	Aktuelle Verschlüsselung, sichere Schlüsselverwaltung und TLS nutzen.
A03 Injection	Eingaben werden als Befehle oder Abfragen fehlinterpretiert.	Parametrisierte Schnittstellen und strikte Eingabevalidierung verwenden.
A04 Insecure Design	Sicherheitsrisiken wurden schon bei Architektur und Prozessen übersehen.	Bedrohungsmodellierung und Sicherheitsanforderungen früh einplanen.
A05 Security Misconfiguration	Unsichere Standardwerte oder falsche Einstellungen öffnen Angriffsflächen.	Gehärtete Konfigurationen und regelmäßige Überprüfungen etablieren.
A06 Vulnerable and Outdated Components	Bibliotheken, Frameworks oder Systeme enthalten bekannte Schwachstellen.	Abhängigkeiten inventarisieren, bewerten und zeitnah aktualisieren.
A07 Identification and Authentication Failures	Anmeldung und Sitzungsverwaltung schützen Konten nicht ausreichend.	MFA, sichere Sitzungen und Schutz vor Kontoübernahmen einsetzen.
A08 Software and Data Integrity Failures	Updates, Daten oder Build-Prozesse können unbemerkt manipuliert werden.	Vertrauenswürdige Lieferketten und Integritätsprüfungen sicherstellen.
A09 Security Logging and Monitoring Failures	Sicherheitsrelevante Ereignisse werden nicht erkannt oder nicht bearbeitet.	Zentral protokollieren, alarmieren und Reaktionsprozesse üben.
A10 Server-Side Request Forgery	Serverseitige Funktionen greifen auf unerwünschte interne oder externe Ziele zu.	Ausgehende Verbindungen beschränken und Zieladressen validieren.

A01 bis A03: Berechtigungen, Daten und Eingaben schützen

Broken Access Control ist besonders kritisch, weil eine Anwendung zwar eine Anmeldung verlangen kann, aber dennoch unzureichend prüft, ob eine Person tatsächlich auf eine konkrete Funktion oder ein konkretes Objekt zugreifen darf. Berechtigungen müssen bei jeder sensiblen Aktion auf dem Server geprüft werden. Verlasse dich nicht auf ausgeblendete Menüpunkte oder Prüfungen im Browser. Definiere Rollen nachvollziehbar und vergib nur die Rechte, die für die jeweilige Aufgabe erforderlich sind. Das Prinzip heißt Least Privilege.

Cryptographic Failures betreffen Daten während der Übertragung und Speicherung. Häufige Ursachen sind unverschlüsselte Verbindungen, schwache oder veraltete Verfahren, falsch abgelegte Schlüssel oder unnötig lange gespeicherte personenbezogene Daten. Erzwinge TLS für alle sensiblen Verbindungen, schütze Backups ebenso wie Produktivdaten und trenne Schlüssel von den Daten, die sie schützen. Wichtig ist außerdem Datenminimierung: Was nicht erhoben oder gespeichert wird, kann auch nicht verloren gehen.

Injection beschreibt Fehler bei der Verarbeitung von Eingaben. Wenn Anwendungen Nutzereingaben ungeprüft in Abfragen, Suchfunktionen oder Systemaufrufe übernehmen, können unerwünschte Auswirkungen entstehen. Die Abwehr beginnt mit sicheren Programmierschnittstellen, insbesondere parameterisierten Datenbankabfragen. Ergänzend brauchst du serverseitige Eingabevalidierung, kontextbezogene Ausgabekodierung und restriktive Berechtigungen für Anwendungskonten. Ein Datenbankkonto einer Web-Anwendung sollte beispielsweise nur die Rechte besitzen, die diese Anwendung wirklich benötigt.

A04 bis A06: Sicherheit in Architektur, Betrieb und Lieferkette

Insecure Design bedeutet nicht zwingend, dass ein einzelner Fehler im Code vorliegt. Oft fehlt ein Sicherheitskonzept für kritische Geschäftsprozesse. Beispiele sind unklare Freigabeprozesse, fehlende Begrenzungen für sensible Aktionen oder nicht berücksichtigte Missbrauchsszenarien. Führe deshalb schon in der Planungsphase Bedrohungsmodellierung durch: Welche Werte sollen geschützt werden, wer könnte sie gefährden und welche Kontrollen verhindern oder begrenzen Schäden?

Security Misconfiguration entsteht im Betrieb erstaunlich oft. Aktivierte Testfunktionen, Standardkennwörter, zu ausführliche Fehlermeldungen, öffentlich erreichbare Verwaltungsoberflächen oder fehlende Sicherheitsheader sind typische Fälle. Nutze dokumentierte Baselines für Server, Container, Cloud-Dienste und Web-Server. Konfigurationen sollten versioniert, automatisiert ausgerollt und regelmäßig gegen Sollvorgaben geprüft werden. Besonders wichtig ist die Trennung von Entwicklung, Test und Produktion.

Vulnerable and Outdated Components betreffen Fremdkomponenten und eigene Plattformen gleichermaßen. Moderne Anwendungen bestehen aus Frameworks, Bibliotheken, Containern, Betriebssystempaketen und Cloud-Diensten. Ohne vollständige Übersicht erkennst du nicht, welche Komponente wo eingesetzt wird. Pflege deshalb ein Inventar der Abhängigkeiten, beobachte Sicherheitsmeldungen der Hersteller und priorisiere Aktualisierungen anhand von Kritikalität, Erreichbarkeit und tatsächlicher Nutzung. Der CVSS-Wert kann bei der Bewertung helfen, reicht allein aber nicht aus.

A07 bis A10: Identitäten, Integrität, Erkennung und Netzgrenzen

Identification and Authentication Failures gefährden Benutzerkonten. Schwache Kennwortvorgaben, fehlende Mehrfaktor-Authentifizierung, unzureichende Sitzungsverwaltung oder fehlende Begrenzungen bei wiederholten Anmeldeversuchen erhöhen das Risiko von Kontoübernahmen. Setze MFA insbesondere für administrative Konten und externe Zugänge ein. Verwende sichere Sitzungskennungen, beende Sitzungen nach angemessener Inaktivität und ermögliche keine Rücksetzung von Kennwörtern ohne belastbare Identitätsprüfung.

Software and Data Integrity Failures richten den Blick auf Build- und Auslieferungsprozesse. Wenn Softwarepakete, Updates oder Konfigurationen aus nicht vertrauenswürdigen Quellen stammen oder Änderungen nicht nachvollziehbar sind, kann die Integrität der Anwendung leiden. Sichere deine CI/CD-Umgebung besonders sorgfältig, beschränke Schreibrechte, prüfe Herkunft und Integrität von Komponenten und dokumentiere Freigaben. Produktionszugriffe sollten nicht über persönliche Einzelentscheidungen erfolgen, sondern über kontrollierte Prozesse.

Security Logging and Monitoring Failures verhindern die rechtzeitige Reaktion. Ein Sicherheitsvorfall wird oft nicht daran erkannt, dass ein Logeintrag existiert, sondern daran, dass ihn jemand bewertet und handeln kann. Protokolliere Anmeldungen, Rechteänderungen, administrative Aktionen, sicherheitsrelevante Fehler und ungewöhnliche Zugriffsversuche datenschutzgerecht. Führe relevante Daten zentral in einem SIEM zusammen, definiere Alarmregeln und übe, wer bei einem Alarm welche Schritte übernimmt.

Server-Side Request Forgery, kurz SSRF, betrifft Funktionen, bei denen ein Server selbst Verbindungen zu anderen Zielen aufbaut, etwa beim Abruf externer Inhalte. Ohne Einschränkungen kann eine solche Funktion möglicherweise interne Dienste erreichen, die von außen nicht zugänglich sein sollen. Begrenze ausgehende Netzwerkverbindungen, validiere erlaubte Zieladressen strikt und verhindere Zugriffe auf interne Verwaltungs- und Metadatendienste. Netzwerksegmentierung und klare Proxy-Regeln ergänzen diese Maßnahmen.

So verankerst du die OWASP Top 10 im Alltag

Die Liste entfaltet ihren Nutzen erst, wenn sie Teil deiner Arbeitsabläufe wird. Eine jährliche Präsentation reicht nicht aus. Verknüpfe die Risiken mit konkreten Anforderungen, Prüfungen und Verantwortlichkeiten.

Eine praxistaugliche Checkliste:

• Definiere Sicherheitsanforderungen bereits vor der Umsetzung neuer Funktionen.
• Prüfe Architekturentscheidungen bei Anwendungen mit hohem Schutzbedarf gemeinsam mit Entwicklung und Betrieb.
• Etabliere Code-Reviews mit Schwerpunkt auf Berechtigungen, Eingabevalidierung, Fehlerbehandlung und Sitzungsmanagement.
• Pflege ein aktuelles Verzeichnis verwendeter Komponenten und Verantwortlichkeiten.
• Führe regelmäßige Schwachstellenscans und qualifizierte Penetrationstests durch.
• Teste Wiederherstellung, Alarmierung und Incident-Response-Prozesse unter realistischen Bedingungen.
• Sensibilisiere Mitarbeitende für Social Engineering, sichere Passwörter und den Umgang mit verdächtigen Anfragen.
• Dokumentiere Risiken, Entscheidungen und akzeptierte Restrisiken nachvollziehbar.

Ein Penetrationstest ist besonders wertvoll, wenn er klar beauftragt ist und auf die tatsächlichen Risiken der Anwendung ausgerichtet wird. Sicherheitstests dürfen ausschließlich mit ausdrücklicher schriftlicher Beauftragung, definiertem Scope und abgestimmten Regeln erfolgen. Ohne Auftrag können Tests rechtswidrig sein. Diese Einordnung ersetzt keine Rechtsberatung.

Wenn du Know-how für sichere Web-Anwendungen, Prüfmethoden und Schutzmaßnahmen aufbauen möchtest, findest du passende IT-Security-Seminare und Termine bei uns auf cmt.de.

Fazit: Die Liste ist ein Startpunkt, kein Häkchen

Die OWASP Top 10 sind kein Katalog, den du einmal abhaken kannst. Sie helfen dir vielmehr, wiederkehrende Ursachen von Sicherheitsvorfällen früh zu erkennen: unklare Berechtigungen, unsichere Datenverarbeitung, fehlende Updates, schwache Prozesse und mangelnde Überwachung. Wenn du diese Themen kontinuierlich in Architektur, Entwicklung und Betrieb integrierst, wird Web-Sicherheit planbar und überprüfbar.