Warum KI-Coding-Agenten immer wieder fehlerhafte Zugriffskontrollen schreiben

KI-Coding-Agenten erzeugen Autorisierungslogik, die kompiliert, die Prüfung besteht und die falsche Richtlinie durchsetzt. Fehlerhafte Zugriffskontrollen stehen an erster Stelle der OWASP Top 10:2025. Dort wiesen 100 % der getesteten Anwendungen eine Form davon auf, mit insgesamt 1.839.701 erfassten Vorkommen – die höchste Zahl aller Kategorien auf der Liste.

Ein Teil dieser Kategorie entzieht sich außerdem genau dem, wofür musterbasierte Scans nie ausgelegt waren. Lässt ein Agent eine Eigentumsprüfung aus, verstößt er gegen eine Regel der Anwendung und nicht gegen ein Muster in einer Signaturdatenbank. Es gibt also kein bekanntes schädliches Muster, mit dem ein Abgleich möglich wäre.

Was sind fehlerhafte Zugriffskontrollen?

Fehlerhafte Zugriffskontrollen liegen vor, wenn nicht durchgesetzt wird, was ein authentifizierter Benutzer tun oder sehen darf. Der Benutzer weist nach, wer er ist, und die Anwendung gibt ihm anschließend Daten oder Aktionen, die jemand anderem gehören. Zwei benannte Fälle machen den Großteil dessen aus, womit Teams konfrontiert sind.

1. BOLA: fehlerhafte Autorisierung auf Objektebene

Bei BOLA wird nicht überprüft, ob der Anfragende zum Zugriff auf genau das angeforderte Objekt berechtigt ist. BOLA steht an erster Stelle der OWASP API Security Top 10 und damit an der Spitze beider OWASP-Listen, die für moderne Anwendungen relevant sind.

2. IDOR: unsichere direkte Objektreferenz

IDOR beschreibt denselben Fehler aus Sicht des Angreifers. Die Anwendung legt eine interne Kennung wie eine Datensatz-ID offen. Wird ein anderer Wert eingesetzt, werden Daten eines anderen Kontos zurückgegeben. Ein einzelner Fehler ist in der Regel sowohl BOLA als auch IDOR.

OWASP setzte diese Kategorie 2021 an die Spitze seiner Liste, wo sie auch in der Ausgabe von 2025 geblieben ist. Es handelt sich um einfache Schwachstellen. Sie bleiben an der Spitze, weil sie leicht einzuführen, schwer automatisch zu erkennen und nach ihrer Entdeckung sofort wertvoll sind.

Warum liegen KI-Coding-Agenten bei der Autorisierung so oft falsch?

Die Softwareentwicklung wurde agentisch, die Sicherheit jedoch nicht. Application Security wurde rund um einen Scan entwickelt, der bekannte schädliche Muster abgleicht und die Ergebnisse an Personen weitergibt, die die Regeln des Produkts kennen. Schreibt ein Agent den Endpunkt, hält sich standardmäßig niemand im Prozess an diese Regeln, und der daraus entstehende Fehler weist kein abgleichbares Muster auf. Diese Lücke lässt sich nicht einfach mit einer weiteren Regel schließen.

Der Grund: Die Autorisierungsanforderung wurde nie genannt, und der Agent macht bei der ihm gestellten Aufgabe keinen Fehler. Angenommen, ein Entwickler bittet einen Coding-Agenten, einen Endpunkt hinzuzufügen, der eine Rechnung anhand ihrer ID zurückgibt. Der Agent erstellt eine Route, die prüft, ob der Aufrufer angemeldet ist, die Rechnung anhand der Kennung in der URL sucht, bei keinem Treffer einen 404-Fehler zurückgibt und den Datensatz an den Client sendet.

Jede dieser Entscheidungen ist für die beschriebene Aufgabe korrekt. Der Endpunkt authentifiziert den Aufrufer, behandelt den Fall eines fehlenden Datensatzes und ist bei der Prüfung klar verständlich. Gleichzeitig kann jeder authentifizierte Benutzer jede Rechnung im System lesen, indem er einen Wert in der URL ändert.

Die Korrektur besteht in einer zusätzlichen Bedingung bei der Suche: Die Rechnung muss sowohl anhand ihrer Kennung als auch anhand der Organisation gesucht werden, der der Aufrufer angehört. Am Endpunkt ändert sich sonst nichts.

Warum sich die Korrektur allein aus dem Code nicht ableiten lässt

Um zu wissen, dass die zweite Version richtig ist, braucht man drei Informationen, die im erzeugten Code nirgends auftauchen:

• Rechnungen gehören zu Organisationen.

• Der Zugriff eines Benutzers ist auf die Organisationen beschränkt, deren Mitglied er ist.

• Zugriffe zwischen Organisationen sind in diesem Produkt niemals legitim.

In einem anderen Produkt könnte die dritte Aussage falsch sein, denn manche Plattformen erlauben Prüfern, Wiederverkäufern oder übergeordneten Konten absichtlich den Zugriff über Mandantengrenzen hinweg. Die Regel ist eine Produkteigenschaft, keine Eigenschaft der Programmiersprache oder des Frameworks. Sie steckt im Datenmodell, in einer Entscheidung von vor zwei Jahren und in den Köpfen der Entwickler, die sie getroffen haben.

Worauf Prüfer stattdessen achten sollten

Ein menschlicher Entwickler im Team erkennt den Fehler meist aus einem Grund: Er kennt das Produkt. Ein Agent, der sich auf die Eingabeaufforderung und die umgebende Datei stützt, hat keinen Zugriff auf das Wissen, das diese Prüfung erforderlich macht.

Zwei Details sollten bei der Prüfung berücksichtigt werden. Das erste ist der Antwortcode. Wird die Eigentumsbedingung in die Suche aufgenommen, liefert eine Anfrage nach der Rechnung einer anderen Organisation denselben 404-Fehler wie eine Anfrage nach einer nicht vorhandenen Rechnung. Genau dieses Verhalten ist erwünscht, denn ein 403-Fehler würde bestätigen, dass der Datensatz existiert, und einem Angreifer ermöglichen, gültige Kennungen systematisch zu ermitteln. Das zweite Detail ist die zurückgegebene Antwort. Wird der gespeicherte Datensatz unverändert zurückgegeben, werden alle seine Felder gesendet. Daher enthält derselbe Handler neben dem Autorisierungsfehler oft auch ein Problem mit der Offenlegung von Daten.

Können SAST-Tools fehlerhafte Zugriffskontrollen finden?

Bei Schwachstellenklassen mit einem erkennbaren Muster ist die Erkennung weitgehend gelöst. Die Ausnahme ist die Autorisierung – genau hier ist KI-generierter Code am schwächsten. Statische Analyse verfolgt beschreibbare Muster, aber Autorisierung auf Objektebene weist keines auf.

Als Gegenbeispiel dient eine Injection: Eine Injection-Schwachstelle hat ein beschreibbares Muster: Nicht vertrauenswürdige Eingaben erreichen einen gefährlichen Verarbeitungspunkt, ohne bereinigt zu werden. Aus diesem Muster wird eine Regel, und eine Engine verfolgt die Daten von der Quelle bis zum Ziel und meldet jeden passenden Pfad.

Was statische Analyse bei fehlerhaften Zugriffskontrollen abdeckt

Fehlerhafte Zugriffskontrollen bilden die größte Kategorie in den OWASP Top 10, aber nicht alle davon lassen sich nur schwer scannen. A01:2025 ordnet der Kategorie 40 CWEs zu. Mehrere davon weisen genau das nachverfolgbare Muster auf, das sich mit statischer Analyse gut erkennen lässt, darunter Path Traversal, Open Redirects und serverseitige Request Forgery. Moderne semantische Engines gehen über den Abgleich von Signaturen hinaus, indem sie Datenflüsse und Codeabsichten modellieren. Wenn eine Codebasis einer einheitlichen Konvention folgt, können sie außerdem erkennen, dass einer Route strukturell ein Autorisierungs-Decorator oder eine Middleware fehlt.

Wo die Grenzen der Abdeckung liegen

Der Teil, der sich der Analyse entzieht, ist enger gefasst. Es geht um Autorisierung auf Objektebene, erfasst als CWE-639 (Autorisierungsumgehung durch benutzergesteuerten Schlüssel), CWE-862 (fehlende Autorisierung) und CWE-863 (fehlerhafte Autorisierung). Hier wird nichts Gefährliches aufgerufen, kein nicht vertrauenswürdiger Wert gelangt an eine unzulässige Stelle, und jede Zeile entspricht den üblichen Konventionen. Der Fehler besteht darin, dass ein Vergleich fehlt, den nur die eigenen Regeln der Anwendung erfordern.

Um den Fehler zu melden, müsste eine Engine wissen, welche Felder in diesem Schema die Eigentümerschaft darstellen, welche Aufrufer zugelassen sind und wo die Grenze zwischen den Mandanten liegt. Dabei geht es nicht um die Qualität der Regel. Es handelt sich um Informationen, die in der untersuchten Datei nicht enthalten sind.

Deterministische Engines und Reasoning gehören zusammen und stehen nicht in Konkurrenz. Für die Klassen, die sie abdecken, liefern Engines jedes Mal dasselbe Ergebnis. So kann ein Team eine Pipeline anhand dieser Ergebnisse absichern. Autorisierung auf Objektebene liegt außerhalb dessen, was sich mit einer Regel beschreiben lässt. Um sie zu behandeln, braucht es daher ein anderes Instrument.

Wie findet man Fehler, für die es kein Muster gibt?

Fehler ohne erkennbares Muster lassen sich finden, indem man anhand eines Anwendungsmodells Schlussfolgerungen zieht, statt nur die gerade vorliegende Datei zu analysieren.

Um den Fehler bei der Rechnung zu finden, braucht man vier Informationen: Was ruft diesen Endpunkt auf? Zu wem gehört das abgerufene Objekt? Welche Benutzer sind zum Zugriff berechtigt? Wo liegt die Vertrauensgrenze zwischen den Mandanten? Diese Informationen lassen sich aus der Codebasis, dem Schema und dem laufenden Produktionssystem gewinnen, müssen aber zu einem Modell zusammengeführt werden, das sich analysieren lässt. Snyk bezeichnet dieses zusammengeführte Modell als Anwendungskontext-Graph: Architektur, Datenflüsse, Datenklassifizierungen, Vertrauensgrenzen und die Realität in der Produktionsumgebung, einmal erstellt und bei Codeänderungen aktualisiert. Sobald er vorliegt, wird die fehlende Eigentumsprüfung sichtbar, weil die Analyse die vom Endpunkt durchgesetzten Regeln mit den Anforderungen der Anwendung abgleichen kann.

Drei Bedingungen machen das Ergebnis vertrauenswürdig.

1. Das Reasoning muss auf diesem Modell beruhen. Ohne dieses Modell erzeugt fortgeschrittenes Reasoning plausible Ergebnisse zu einer Codebasis, die es sich teilweise ausgedacht hat, und verbraucht bei der blinden Suche unnötig Tokens.

2. Die Ergebnisse müssen von etwas bestätigt werden, das sie nicht selbst hervorgebracht hat. Ein Agent, der eine Schwachstelle findet, kann nicht mit der Validierung seiner eigenen Korrektur betraut werden. Und ein System, das seine eigene Ausgabe bewertet, übernimmt alle Versäumnisse seiner Analyse.

3. Die Korrektur muss nachgewiesen, nicht nur vorgeschlagen werden. Die Korrektur in einer Zeile muss anhand der Regeln der Anwendung validiert werden und nachweislich auch bei Codeänderungen Bestand haben. Wird ein Befund nie in eine gemergte Korrektur überführt, bleibt der Endpunkt genauso anfällig wie zuvor.

Reasoning über die zusammengeführte Anwendung, ergänzt durch parallel laufende deterministische Engines – in diese Richtung entwickelt Snyk Evo Agentic AppSec, das im August erstmals vorgestellt wurde. Laufzeittests bestätigen anschließend, worauf ein Angreifer zugreifen kann. Genau hier kommt Evo Continuous Offensive Security heute zum Einsatz.

Was sollte Ihr Team jetzt tun?

Fünf Schritte, für die Sie zunächst keine neuen Tools brauchen.

1. Erfassen Sie die Endpunkte, die eine Objektkennung aus der Anfrage entgegennehmen. Jede Route, die eine ID, einen Dateinamen oder einen Schlüssel aus einer URL oder dem Anfragetext übernimmt, ist ein möglicher Kandidat. Diese Liste ist meist kürzer, als Teams erwarten, und länger, als ihnen lieb ist.

2. Halten Sie die Eigentumsregeln schriftlich fest. Erfassen Sie für jeden Ressourcentyp, wem er gehört und wer ihn lesen oder ändern darf. Autorisierungsfehler überstehen Prüfungen, weil diese Informationen nirgendwo festgehalten wurden, wo Prüfer oder Analysten sie nachschlagen können.

3. Nehmen Sie die Autorisierung als festen Prüfpunkt in Pull Requests auf, die von Agenten erstellt wurden. Nicht als allgemeine Aufforderung, sorgfältig zu prüfen, sondern als konkrete Frage: Überprüft dieser Endpunkt, ob der Aufrufer zum Zugriff auf das Objekt berechtigt ist, und anhand welchen Felds?

4. Ergänzen Sie für jeden Ressourcentyp einen mandantenübergreifenden Test. Die Empfehlungen von OWASP zur Prävention sind eindeutig: Entwickler und QA-Teams sollten funktionale Zugriffskontrollen in ihre Unit- und Integrationstests aufnehmen. Ein Test pro Ressource, der sicherstellt, dass eine gültige Sitzung aus einem Mandanten beim Zugriff auf das Objekt eines anderen Mandanten einen 404-Fehler erhält, macht aus der in Schritt zwei dokumentierten Regel eine dauerhaft durchgesetzte Regel.

5. Führen Sie regelmäßig eine eingehende Analyse der gesamten Codebasis durch. Der Kontrollpunkt besteht inzwischen aus drei Teilen: Echtzeitprüfungen innerhalb der Feedbackschleife des Agenten, schnelle deterministische Scans bei jeder Änderung in CI und eine eingehende kontextbezogene Analyse der gesamten Codebasis. Fehler bei der Autorisierung auf Objektebene treten im dritten Teil zutage.

Welche Ihrer Endpunkte würden heute bei diesem mandantenübergreifenden Test durchfallen? Beginnen Sie mit der Bestandsaufnahme aus Schritt eins. Erfahren Sie mehr darüber, wie Snyk die agentische Anwendungssicherheit weiterentwickelt: Ein erster Einblick in Evo Agentic AppSec.