Broken Access Control: Der Anstieg um 40 % im Jahr 2025 bei der meist ausgenutzten Schwachstelle 🚧

Der Beständige Sicherheits-Champion

Im sich ständig weiterentwickelnden Bereich der Cybersicherheit hält eine Schwachstelle ihren festen Platz an der Spitze: broken access control. Als das Open Web Application Security Project (OWASP) im November seine Top 10 für 2025 veröffentlichte, war die Botschaft eindeutig—trotz jahrelanger Bewusstseinsbildung, Sicherheitsverbesserungen und zahlreicher Präventionsmaßnahmen bleibt broken access control das ernsthafteste Sicherheitsrisiko für Organisationen.

Die Statistiken zeichnen ein ernüchterndes Bild. Laut der neuesten Analyse von OWASP, die über 2,8 Millionen Anwendungen umfasst, dominiert broken access control weiterhin die Schwachstellenlandschaft, mit durchschnittlich 3,73 % der getesteten Anwendungen, die mindestens eine der 40 Common Weakness Enumerations (CWEs) in dieser Kategorie aufweisen. Noch alarmierender ist, dass 94 % der Anwendungen auf irgendeine Form von broken access control getestet wurden, was die allgegenwärtige Natur dieser Sicherheitsherausforderung verdeutlicht.

Der Dramatische Anstieg: Die Zahlen verstehen

Aktuelle Penetrationstests aus dem BreachLock Intelligence Report 2025 zeigen, dass broken access control einen erheblichen Anstieg erlebt hat, mit 32 % der Hochrisiko-Funde bei über 4.200 Penetrationstests im vergangenen Jahr. Dies stellt eine deutliche Steigerung gegenüber den Vorjahren dar und bestätigt broken access control als die häufigste und gleichzeitig kritischste Schwachstelle in modernen Anwendungen.

Besonders in bestimmten Branchen ist der Trend besorgniserregend. APIs in Technologie- und SaaS-Umgebungen verzeichneten einen erstaunlichen Anstieg um 400 % bei kritischen Schwachstellen, wobei schlechte Zugriffskontrollen, Logikfehler und unsichere Exposition die Hauptursachen sind. Finanzinstitute reagieren darauf, indem sie ihre Penetrationstests auf vierteljährliche oder kontinuierliche Prüfungen erhöhen, um mit den schnellen IT-Änderungen und sich entwickelnden Bedrohungen Schritt zu halten.

Warum ist broken access control so gefährlich?

Broken access control tritt auf, wenn eine Anwendung die Autorisierungsrichtlinien nicht richtig durchsetzt—also nicht überprüft, ob ein Nutzer berechtigt ist, eine bestimmte Aktion durchzuführen oder auf bestimmte Daten zuzugreifen. Im Gegensatz zur Authentifizierung (die bestätigt, wer Sie sind), bestimmt die Autorisierung, was Sie nach dem Login tun dürfen. Wenn diese Kontrollen versagen, können Angreifer die Schwachstelle ausnutzen, um Daten anzusehen, zu ändern oder zu löschen, auf die sie keinen Zugriff haben sollten.

Die Schwachstelle zeigt sich in mehreren gängigen Formen:

Vertikale Privilegieneskalation: Wenn ein normaler Nutzer Zugriff auf administrative Funktionen erhält, die ihm nicht zustehen. Zum Beispiel, wenn ein Standardnutzer durch Raten oder Entdecken der URL Zugriff auf das Admin-Panel erhält.

Horizontale Privilegieneskalation: Wenn Nutzer auf Ressourcen anderer Nutzer auf derselben Privilegienstufe zugreifen, z.B. durch Ändern eines ID-Parameters in der URL, um die Kontoinformationen eines anderen Kunden zu sehen.

Insecure Direct Object References (IDOR): Wenn Anwendungen Referenzen zu internen Objekten wie Dateien, Datenbankeinträgen oder Verzeichnissen ohne ordnungsgemäße Berechtigungsprüfungen offenlegen, was Angreifern erlaubt, diese Referenzen zu manipulieren.

Forced Browsing: Wenn Nutzer Zugriffskontrollen umgehen, indem sie direkt URLs aufrufen, die eigentlich geschützt sein sollten, und so Sicherheitsüberprüfungen überspringen.

Fehlende Funktionsebene-Zugriffskontrolle: Wenn Anwendungen die Nutzerrechte für sensible Operationen, insbesondere bei API-Endpunkten für POST, PUT oder DELETE, nicht verifizieren.

Auswirkungen in der Praxis: Die Kosten des Versagens

Die Folgen von broken access control Schwachstellen gehen weit über theoretische Sicherheitsbedenken hinaus. Im September 2022 enthüllte Optus einen massiven Datenleck, bei dem persönliche Daten von etwa 10 Millionen aktuellen und ehemaligen Kunden offengelegt wurden. Spätere rechtliche Schritte zeigten, dass ein Programmierfehler in der Zugriffskontrolle eine API jahrelang anfällig für Missbrauch machte, sodass unautorisierte Anfragen auf Kundendaten zugreifen konnten.

Kürzlich, im Juni 2024, demonstrierten Sicherheitsexperten eine kritische Schwachstelle im Webportal von Kia, die es ihnen ermöglichte, die Funktionen des Connected-Car-Systems nur mit einem Nummernschild zu übernehmen. Durch Ausnutzung schwacher Eigentumsverifikation und Autorisierungsprüfungen konnten sie die Kontrolle vom legitimen Besitzer auf ihr eigenes Gerät übertragen, was Tracking, Entriegeln und sogar Fernstarten von Fahrzeugen ermöglichte. Dieser Vorfall zeigt, wie unzureichende serverseitige Autorisierung bei kritischen Aktionen reale physische Konsequenzen haben kann.

Das Problem des schnellen Entwicklungszyklus

Einer der Hauptfaktoren für den Anstieg der Schwachstellen bei broken access control ist die beschleunigte Softwareentwicklung. Organisationen stehen unter Druck, Funktionen schnell bereitzustellen, oft mit Priorität auf Geschwindigkeit statt Sicherheit. Diese “schnell und kaputt”-Mentalität, obwohl sie die Geschäftsagilität fördert, schafft erhebliche Sicherheitslücken.

Fehlkonfigurationen in der Sicherheit haben sich von Platz fünf im Jahr 2021 auf Platz zwei in der OWASP Top 10 2025 hochgearbeitet, was zeigt, wie hastig gebaute Systeme Schwachstellen einführen. Moderne Softwareentwicklung basiert zunehmend auf Konfigurationsdateien, Cloud-Berechtigungen und Infrastruktur-Templates, um das Verhalten der Anwendung zu steuern. Jedes falsch gesetzte Flag, zu breite Rollen oder unsichere Standardberechtigungen wird so zu einem potentiellen Angriffsvektor.

Das Problem verschärft sich durch die zunehmende Komplexität moderner Architekturen. Microservices, Multi-Tenancy, APIs und Maschinen-Identitäten erweitern die Angriffsfläche für Zugriffskontrollen exponentiell. Dennoch sind Governance-Frameworks nicht im gleichen Maße gewachsen. Organisationen haben oft Schwierigkeiten, konsistente Autorisierungsrichtlinien in verteilten Systemen umzusetzen, was Lücken schafft, die Angreifer leicht ausnutzen.

Zudem zeigen Studien, dass 67 % der Organisationen Nutzerrechte nur quartalsweise oder seltener überprüfen, was lange Zeiträume ohne Kontrolle bei inaktiven Konten oder übermäßigen Berechtigungen bedeutet. Dieses Fehlen kontinuierlicher Überwachung schafft Chancen für externe Angreifer und Insider.

Das KI-generierte Code-Problem

Ein weiterer alarmierender Faktor ist die rasche Verbreitung von KI-gestützten Code-Generatoren. Während diese Tools Produktivität und Effizienz steigern, bringen sie gleichzeitig beispiellose Sicherheitsrisiken mit sich, auf die viele Organisationen nicht vorbereitet sind.

Das Ausmaß des Problems

Aktuelle Studien zeigen alarmierende Zahlen zu KI-generiertem Code. Untersuchungen belegen, dass zwischen 40 % und 62 % der KI-generierten Lösungen Designfehler oder bekannte Sicherheitslücken enthalten. Eine Studie von Veracode fand heraus, dass in 45 % aller Tests große Sprachmodelle (LLMs) Schwachstellen im OWASP Top 10 einführten.

Die Sicherheitsfehlerraten variieren je nach Programmiersprache: Java ist am risikoreichsten mit über 70 %, während Python, C# und JavaScript immer noch erhebliche Risiken mit Fehlerraten zwischen 38 % und 45 % aufweisen. Diese Werte sind keine Randfälle—sie zeigen fundamentale Schwächen in der Art, wie KI-Modelle Code generieren.

Warum KI bei Zugriffskontrollen versagt

KI-Codegeneratoren haben inhärente Begrenzungen, die sie besonders anfällig für broken access control Schwachstellen machen:

Training Data Inheritance: KI-Modelle lernen aus riesigen Repositories bestehender Codes, inklusive Open-Source-Projekten auf Plattformen wie GitHub und Stack Overflow. Leider enthält dieses Trainingsmaterial nicht nur guten Code, sondern auch unsichere Muster, veraltete APIs und schlecht implementierte Sicherheitskontrollen. Wenn solche fehlerhaften Muster häufig im Trainingsdatensatz vorkommen, reproduzieren die Modelle sie leicht.

Fehlendes Kontextverständnis: KI-Modelle verstehen nicht die spezifischen Risiken Ihrer Anwendung, internen Standards oder Bedrohungsszenarien. Sie können Ihre Geschäftslogik oder Deployment-Umgebung nicht erfassen. Ohne dieses Verständnis können sie nicht beurteilen, ob Nutzer A Zugriff auf Datensatz B haben sollte—eine Entscheidung, die tiefes Domänenwissen und spezifische Geschäftsanforderungen erfordert.

Optimierung für Funktionalität statt Sicherheit: Wenn Eingabeaufforderungen mehrdeutig sind, optimieren LLMs für den kürzesten Weg zu einer funktionierenden Lösung. Sie werden für die Lösung der Aufgabe belohnt, nicht für sichere Implementierung. Das führt oft zu Abkürzungen, die zwar funktionieren, aber ernsthafte Sicherheitslücken schaffen.

Fehlende Sicherheitskontrollen standardmäßig: KI-generierter Code lässt häufig Eingabevalidierung, Authentifizierungsprüfungen und Zugriffskontrollen weg, es sei denn, sie werden explizit angefordert. Eine typische Eingabeaufforderung wie “Verbinde dich mit einer Datenbank und zeige Nutzerdaten” führt oft zu Code, der die Authentifizierung umgeht und nicht prüft, ob der Anfragende Zugriff auf die Daten haben sollte.

Das “Vibe Coding”-Phänomen

Der Aufstieg dessen, was Brancheninsider “vibe coding” nennen—bei dem Entwickler stark auf KI vertrauen, um Code zu generieren, ohne explizit Sicherheitsanforderungen zu definieren—stellt einen fundamentalen Wandel in der Softwareentwicklung dar. Im Februar 2025 beschrieb der ehemalige OpenAI-Forscher Andrej Karpathy dies als Programmieren, bei dem Entwickler “voll auf die Vibes setzen, Exponentials umarmen und vergessen, dass der Code überhaupt existiert.”

Dieses Vorgehen ist problematisch, weil Entwickler keine Sicherheitsvorgaben spezifizieren müssen, um funktionierenden Code zu erhalten. Die Verantwortung für sichere Programmierung wird effektiv an LLMs übertragen, die nach Studien fast die Hälfte der Zeit falsche Entscheidungen treffen. Eine Veracode-Studie zu Cross-Site Scripting (CWE-80) und Log Injection (CWE-117) zeigte, dass LLMs bei 86 % bzw. 88 % der Fälle versagten, den Code gegen diese Bedrohungen abzusichern.

Das Vertrauensparadoxon

Besonders besorgniserregend ist das Vertrauensparadoxon bei KI-generiertem Code. Studien von Perry et al. (2023) fanden heraus, dass Entwickler, die KI-Assistenten nutzen, mehr unsicheren Code produzierten, aber glaubten, sie hätten sichereren Code geschrieben. Eine Snyk-Umfrage ergab, dass fast 80 % der Entwickler glaubten, KI-generierter Code sei sicherer—eine gefährliche Fehleinschätzung, die zu weniger Kontrolle und schnelleren Deployments vulnerabler Software führt.

Dieses falsche Vertrauen wird durch die “Black Box”-Natur der KI-Entscheidungsfindung verstärkt. Selbst die Entwickler, die KI-Tools bauen, haben möglicherweise keinen vollständigen Einblick, wie die Modelle entscheiden, welchen Code sie produzieren. Diese Undurchsichtigkeit macht KI-generierten Code schwer vorhersehbar und kann unbeabsichtigt Bugs oder Schwachstellen einführen, die herkömmliche Code-Reviews nicht erkennen.

Das Speed-gegen-Sicherheit-Dilemma

KI-Tools können Code viel schneller produzieren als menschliche Entwickler, was zunächst wie ein klarer Vorteil erscheint. Doch diese Geschwindigkeit schafft eine kritische Sicherheitsherausforderung: potenziell unsicherer Code kann viel schneller in Systeme integriert werden, als Sicherheitsteams gründliche Bewertungen durchführen können.

Die Entwicklungsgeschwindigkeit übertrifft jetzt die Sicherheitsüberprüfung, was bedeutet, dass Schwachstellen unweigerlich durchrutschen. Die schnelle Bereitstellung durch KI kann zu dem führen, was Sicherheitsexperten “Compliance Drift” nennen—wenn Teams Funktionen implementieren, ohne regulatorische Anforderungen oder Sicherheitsbest Practices zu berücksichtigen.

Der Effekt der Verstärkung: Feedback-Schleifen und technischer Schuldenberg

Die Lage wird durch Feedback-Schleifen im KI-Training noch verschärft. Neue KI-Modelle können zuvor generierten KI-Code in ihre Trainingsdaten aufnehmen. Enthält dieser Code Schwachstellen, können diese Fehler perpetuiert und durch nachfolgende Generationen von Modellen weiterverbreitet werden, was ein wachsendes Universum unsicherer Code-Muster schafft.

Dieses Phänomen trägt zum sogenannten “security debt” bei—der Ansammlung unbehandelter Schwachstellen, die im Laufe der Zeit immer schwerer und teurer zu beheben sind. Organisationen, die keine ordnungsgemäße Sicherheitsvalidierung KI-generierten Codes durchführen, riskieren, diese Schulden auf untragbare Höhen anwachsen zu lassen.

Branchenreaktion und aktueller Stand

Die Cybersicherheitsbranche ist nicht untätig angesichts dieser Herausforderungen. Der Finanzsektor, der die Schwere der Bedrohung erkannt hat, führt die Reaktion an: 40 % der Finanzunternehmen erhöhen die Penetrationstests auf vierteljährliche oder kontinuierliche Zyklen. Dies stellt einen Wandel von periodischer Bewertung zu kontinuierlicher Sicherheitsvalidierung dar.

Technologieführer entwickeln ebenfalls Lösungen gegen Schwachstellen in KI-generiertem Code. GitHub’s Copilot Autofix hat beispielsweise vielversprechende Ansätze gezeigt, um Schwachstellen schneller zu beheben, mit Entwicklern, die Probleme mehr als dreimal so schnell lösen wie bei manuellen Methoden. Die Behebungsraten haben sich von fast 50 % auf nahezu 100 % bei Nutzern dieser Tools verbessert.

Dennoch haben diese Verbesserungen den allgemeinen Trend nicht umkehren können. Die Erweiterung der OWASP Top 10 2025 um Server-Side Request Forgery (SSRF) im Bereich broken access control zeigt, dass Schwachstellen im Zugriffskontrollbereich heute ein breiteres Spektrum an Vertrauensverletzungen umfassen, als bisher angenommen.

Zukunftsausblick: Eine mehrschichtige Verteidigungsstrategie

Die Bewältigung der Krise bei broken access control erfordert einen ganzheitlichen, vielschichtigen Ansatz, der sowohl traditionelle Ursachen als auch aufkommende KI-bezogene Risiken berücksichtigt:

Implementierung von Policy-basiertem Zugriffskontrollsystem: Weg von ad-hoc Rollenprüfungen und verschachtelter if-else-Logik hin zu zentralisierten, politikgesteuerten Autorisierungssystemen. Diese skalieren besser bei komplexen Architekturen und bieten klarere Governance.

Zero Trust Architektur: Strikte Verifizierung bei jeder Zugriffsanfrage, unabhängig von der Quelle. Dazu gehören konsistente Zugriffskontrollen, Verschlüsselung und Überwachung in allen Umgebungen.

Absicherung KI-generierten Codes: Integration von Static Application Security Testing (SAST) und Software Composition Analysis (SCA) in den Entwicklungsprozess, um Schwachstellen in KI-generiertem Code automatisch zu erkennen. Sicherheits-Feedback in CI/CD-Pipelines implementieren.

Entwicklertraining verbessern: Entwicklungsteams über die spezifischen Sicherheitsrisiken bei KI-generiertem Code aufklären. KI-Coding-Assistenten wie “talented interns” behandeln, die erste Entwürfe liefern, die von Experten überprüft und verfeinert werden müssen.

Governance-Richtlinien etablieren: Klare Grenzen setzen, wann KI-Coding-Tools genutzt werden dürfen und wann nicht. Einsatz von KI bei sicherheitskritischen Komponenten möglicherweise verbieten, bei weniger risikoreichen Funktionen jedoch fördern.

Kontinuierliche Überwachung: Regelmäßige Zugriffskontroll-Reviews—idealerweise automatisiert und kontinuierlich—durchführen, um inaktive Konten und übermäßige Berechtigungen schnell zu erkennen und zu beheben.

Secure-by-Default Prinzipien: Systeme so konfigurieren, dass sie standardmäßig den Zugriff verweigern, und explizit Berechtigungen für jede Aktion erteilen. Gilt gleichermaßen für menschlich geschriebenen und KI-generierten Code.

Regelmäßige Sicherheitstests: Penetrationstests häufiger und umfassender durchführen, insbesondere bei API-Endpunkten und Zugriffskontrollmechanismen. Automatisierte Tools und manuelle Expertenbewertungen nutzen.

Der Weg nach vorne

Der Anstieg der Schwachstellen bei broken access control im Jahr 2025, verstärkt durch KI-generierten Code, markiert einen Wendepunkt in der Anwendungssicherheit. Organisationen stehen vor der Wahl: Sicherheitspraktiken an die Geschwindigkeit und Natur moderner Entwicklung anzupassen oder weiterhin Sicherheitsverschuldung anzuhäufen, die letztlich zu erheblichen Sicherheitsvorfällen führt.

Die Tatsache, dass broken access control in der OWASP Top 10 für mehrere Zyklen an der Spitze bleibt, zeigt, dass Bewusstsein allein nicht ausreicht. Organisationen müssen dieses Verständnis in konkrete Maßnahmen umsetzen—durch robuste technische Kontrollen, umfassende Governance-Frameworks und einen fundamentalen Wandel im Umgang mit Autorisierung in einer KI-unterstützten Entwicklungsumgebung.

Mit der Weiterentwicklung von KI und ihrer tieferen Integration in den Softwareentwicklungsprozess wird die Herausforderung vorerst zunehmen, bevor sie sich verbessert. Die Organisationen, die diesen Übergang erfolgreich meistern, werden jene sein, die Sicherheit nicht als Kostenfaktor, sondern als essenziellen Bestandteil ihrer Entwicklungsstrategie sehen—eine Strategie, die sich ebenso schnell weiterentwickeln muss wie die Technologien, die Risiken schaffen.

Der Anstieg um 40 % bei broken access control Schwachstellen ist nicht nur eine Statistik—es ist ein Aufruf zum Handeln für jede Organisation, die Software im Jahr 2025 und darüber hinaus entwickelt. Die Frage ist nicht, ob man reagieren sollte, sondern wie schnell und umfassend die notwendigen Änderungen umgesetzt werden können, um Ihre Anwendungen gegen diese anhaltende und wachsende Bedrohung zu sichern.