Kein Scanner findet alles: Broken Access Control, Geschäftslogik und die Grenze der automatischen Analyse
Warum die Risikoklasse auf Platz eins der OWASP Top 10:2025 zugleich die ist, die ein Scanner am schlechtesten sieht, wo genau die Grenze der Mustersuche liegt, und welche Prüfung das übernimmt, was kein Muster hat: der Penetrationstest als Gegenstück zum laufenden Scan.
Was ein Scanner sieht
Ein Code-Scanner arbeitet mit Mustern und bekannten Listen. Ein Passwort im Quelltext hat eine erkennbare Form. Eine Bibliothek mit bekannter Lücke steht in einer Datenbank. Eine Eingabe, die ohne Prüfung in eine Datenbankabfrage wandert, folgt einem wiedererkennbaren Aufbau. Ein Aufruf, der Systembefehle mit Nutzereingaben zusammensetzt, ebenso. Für diese Klassen ist ein Scan bei jedem Commit das richtige Werkzeug, weil er sie findet, sobald sie entstehen, und weil er sie, richtig eingeordnet, datiert belegt.
Auch fehlende Zugriffskontrollen gehören dazu, aber nur in einer engen Form: Ein Endpunkt, der ohne jede Berechtigungsprüfung erreichbar ist, fällt auf. Das ist der Teil von Broken Access Control, den Muster erfassen. Es ist nicht der Teil, der in der Praxis am meisten Schaden anrichtet.
Warum Platz eins der Top 10 zum Teil unsichtbar bleibt
Broken Access Control steht in der Ausgabe 2025 der OWASP Top 10 auf Platz eins. Die Klasse umfasst weit mehr als einen ungeschützten Endpunkt. Sie umfasst den Fall, dass eine Prüfung vorhanden ist und trotzdem falsch: Der Nutzer wird geprüft, aber nicht, ob der angefragte Datensatz ihm gehört. Der Mitarbeiter darf Rechnungen sehen, aber nur die seines Standorts, und die Software fragt nicht nach dem Standort. Der Kunde darf seinen Vertrag ändern, aber nicht den Preis, und das Feld ist im Formular ausgeblendet statt serverseitig gesperrt.
Für jeden dieser Fälle existiert Code, der eine Zugriffskontrolle durchführt. Der Scanner sieht die Prüfung und ist zufrieden. Ob die Prüfung die richtige Frage stellt, steht in keinem Muster, sondern im Geschäftsmodell. Das ist der Grund, warum wir auf unserer Seite zur Code-Sicherheit schreiben, dass Geschäftslogik-Fehler sich der automatischen Analyse entziehen, und warum wir das nicht als Kleingedrucktes behandeln.
Die zweite Grenze: Design
Neben der Geschäftslogik gibt es eine zweite Fehlerklasse ohne Muster: Entscheidungen, die vor dem Code getroffen wurden. Ob eine Komponente überhaupt direkt aus dem Netz erreichbar sein darf. Ob zwei Dienste denselben Datenbanknutzer teilen sollten. Ob ein Token, das für eine Stunde gedacht war, in Wirklichkeit nie abläuft, weil niemand es so spezifiziert hat. Der Quelltext ist in all diesen Fällen fehlerfrei im Sinne des Scanners. Der Fehler liegt in dem, was der Quelltext umsetzt.
Dazu kommt das, was jeder Scanner umgekehrt tut: Er meldet auch Funde, die im konkreten Fall nicht ausnutzbar sind. Ein Mensch, der jeden Fund einordnet, hält diese Falschmeldungen aus dem Bericht. Er macht den Scanner aber nicht sehend für das, was kein Muster hat.
Was der Penetrationstest übernimmt
Ein Penetrationstest setzt außen an. Er nimmt das laufende System als Ganzes, samt Netz, Konfiguration, Berechtigungen und Menschen, und versucht, es zu überwinden. Ein Tester, der als Nutzer A angemeldet ist und die Rechnungen von Nutzer B sehen will, probiert es einfach. Er braucht kein Muster, er braucht die fachliche Frage. Genau deshalb findet ein guter Test die Fehler, an denen der Scan vorbeisieht, und genau deshalb findet er sie nur am Testtag.
Den Test selbst vergeben wir nicht an uns. Aus gutem Grund: Wer den Scan betreibt, sollte nicht auch derjenige sein, der bescheinigt, dass nichts durchgerutscht ist. Unsere Rolle liegt davor und danach: die Frage klären, ob ein Test jetzt überhaupt das richtige Mittel ist, die Kriterien liefern, mit denen man Anbieter vergleicht, und die Befunde aus dem Bericht in erledigte Maßnahmen verwandeln. Mehr dazu auf unserer Seite zum Penetrationstest und im Beitrag Penetrationstest oder Schwachstellen-Scan.
Wie beides zusammenspielt
Die Arbeitsteilung ist einfach, wenn man sie einmal ausgesprochen hat. Der Scan hält die Fehlerklassen mit Muster laufend aus dem Code und dokumentiert das mit Datum: Secrets, verwundbare Abhängigkeiten, unsichere Muster, ungeschützte Endpunkte. Der Test prüft periodisch, ob die Kontrollen, die es gibt, die richtige Frage stellen, und ob das Design hält. Wer nur testet, hat zwischen zwei Terminen ein Jahr ohne Prüfung. Wer nur scannt, hat Platz eins der Top 10 nur zur Hälfte im Blick.
Für den Nachweis heißt das: Ein Auditor, der einen Pentest sehen will, akzeptiert keinen Scan-Bericht als Ersatz. Und ein Auditor, der Schwachstellenmanagement bei Entwicklung und Wartung nach § 30 BSIG sehen will, akzeptiert keinen Jahrestest als Beleg für den Prozess dazwischen.
Häufig gestellte Fragen
Findet der CAVRIX-Scan Broken Access Control?
Den Teil mit Muster, ja: Endpunkte ohne jede Berechtigungsprüfung und bekannte unsichere Aufbauten. Den Teil ohne Muster, also ob eine vorhandene Prüfung fachlich die richtige Frage stellt, findet kein Scanner. Dafür ist der Penetrationstest das Werkzeug.
Warum steht diese Grenze so deutlich bei Euch?
Weil ein Nachweis, der so tut, als decke der Scan alles ab, im Audit oder nach einem Vorfall falsch wäre. Wir schreiben lieber vorher, was der Scan nicht kann, als hinterher zu erklären, warum etwas durchgerutscht ist.
Bietet CAVRIX Penetrationstests an?
Nein. Wir sagen Dir, ob Du einen brauchst, worauf bei der Auswahl zu achten ist, und übernehmen, was nach dem Bericht kommt. Der laufende Scan ist unser Teil, der Test der eines spezialisierten Anbieters.