Drei Methoden, die Sicherheit zu prüfen, logen. Die vierte konnte es nicht

In meinem Panel verteidigt sich jeder Zugangspunkt selbst. Es gibt keine übergeordnete Schicht, die Datenverkehr durchlässt oder blockiert — es gibt eine einzige Sitzungsprüfung, in jeder Datei einzeln wiederholt. Sie zu vergessen öffnet einen Zugangspunkt ohne jedes Symptom: der Code kompiliert, die Tests laufen durch, das Panel funktioniert.

Am 6. August 2026 zählte ich, wie viele dieser Zugangspunkte es wirklich gibt und welche davon ablehnen. Ergebnis: 266 HTTP-Handler in 188 Dateien. Interessant ist nicht die Zahl, sondern dass die ersten drei Zählmethoden die falsche Antwort lieferten.

Drei Methoden, drei Lügen

Suche nach Datei. Eine Datei kann vier Zugangspunkte und eine Sitzungsprüfung haben. Beim vorherigen Audit zählte diese Methode neun öffentliche Routen. Tatsächlich gab es sechzehn öffentliche Zugangspunkte in vierzehn Dateien — fünf dieser Dateien erwähnten die Sitzungsprüfung in einem Kommentar, also galten sie der Suche als geschützt. Das Ergebnis sah wie ein Ergebnis aus.

Suche nach einzelnem Zugangspunkt. Besser, aber der Schutz sitzt manchmal einen Aufruf weiter entfernt — der Zugangspunkt ruft eine Funktion auf, und die Prüfung sitzt darin. Diese Methode zeigte 21 Lücken, von denen keine einzige echt war.

Dateien statt Zugangspunkte zählen. Ein Fehler, den ich selbst in einem Dokument gemacht habe, das vor der ersten Methode warnte: Ich schrieb „acht öffentliche Seiten", tatsächlich sind es zehn Handler. Derselbe Fehler, in einem Satz, der davor warnt.

Eine Sonde statt Lesen

Erst der Live-Beschuss brachte Klarheit. Ich startete das System lokal, deaktivierte die Entwickler-Umgehung für die Anmeldung und sendete an jeden der 266 Zugangspunkte eine Anfrage — ohne Sitzungs-Cookie, ohne jeden Authentifizierungs-Header.

252 lehnten ab. 14 antworteten, jeder mit einem benannten Mechanismus, der ihn statt einer Sitzung bewacht: ein Kontaktformular mit einer Bremse für die Anzahl der Einsendungen, Daten, die per Definition öffentlich sind, Dokumente, die über einen Link geöffnet werden, in dem ein Token die Rolle eines Passworts übernimmt.

Und hier beginnt der eigentliche Teil.

Eine Prüfung, die nur Ablehnungen sieht, kann kaputt sein

Eine Sonde, die auf alles mit „abgelehnt" antwortet, sieht identisch aus, egal ob das System dicht ist oder sie selbst nicht funktioniert. Grün auf der ganzen Liste ist kein Beweis — es ist ein Mangel an Information.

Deshalb suchte ich den Beweis in ihren eigenen Ergebnissen: Ein Zugangspunkt lieferte vollständige Daten zurück, ein anderer lehnte die Anfrage wegen eines falsch ausgefüllten Formulars ab. Wäre die Sonde kaputt gewesen, hätten auch diese beiden eine Ablehnung gezeigt. Dass sie drei verschiedene Antworten unterscheidet, ist der Beweis, dass die Ablehnungen an den übrigen 252 Stellen etwas bedeuten.

Eine zweite Variante desselben Fehlers fing ich auf halbem Weg ab. Vier Routen sind nicht durch eine Sitzung geschützt, sondern durch ein Geheimnis — und der erste Durchgang schickte ihnen das Geheimnis am falschen Ort: einer im Adressparameter statt im Header, einer anderen im Anfragekörper statt im Parameter. Beide lehnten ab, und es sah nach korrektem Schutz aus. Eine Ablehnung wegen falsch gestellter Frage ist nicht von einer Ablehnung wegen Schutz zu unterscheiden. Erst der Nachweis, dass diese Routen mit dem korrekten Geheimnis durchlassen, schließt den Fall in beide Richtungen.

Nebenbei tauchte ein dritter zeitgesteuerter Automat auf, der auf keiner meiner Listen stand. Ich fand ihn nicht durch Lesen — er fand sich selbst, weil die Sonde alles abfragte.

Was ich nicht getan habe

Ich habe den vierzehn öffentlichen Zugangspunkten keine Sitzungsprüfung hinzugefügt. Das war die größte Versuchung des ganzen Tages: vierzehn ungeschützte Stellen sehen aus wie vierzehn Dinge zum Reparieren, und eine solche Änderung sieht in der Projekthistorie wie ein Sicherheitspatch aus. Es hätte das Produkt kaputtgemacht — über diese Zugangspunkte gehen echte Kunden, die kein Konto haben und keines haben werden.

Ich habe die Schwellenwerte der Bremse nicht angerührt, nicht einmal für die Dauer der Messung. Verlockend, weil eine 266-mal feuernde Sonde sie aufbrauchen kann. Stattdessen habe ich die Sonde so gebaut, dass ihr zweiter Durchgang die öffentlichen Routen auslässt. Eine Messung, die die gemessene Sache zu ihrer eigenen Bequemlichkeit lockert, misst etwas anderes als das Produkt.

Ich habe nicht geschrieben, dass die Sonde mehr beweist, als sie beweist. Sie setzt nicht existierende Kennungen ein, also würde eine nur für bestimmte Werte geschützte Route trotzdem geschützt aussehen. Die Zugangspunkte mit dem höchsten Risiko habe ich zusätzlich von Hand gelesen.

Drei Dinge, die ich daraus mitnehme

Eine Prüfung, die keine schlechte Nachricht liefern kann, ist keine Prüfung. Bevor du einem grünen Ergebnis vertraust, zeige, dass derselbe Mechanismus in der Lage ist, rot aufleuchten zu lassen.

Eine Ablehnung kann ein Symptom von Defekt sein, nicht von Schutz. Eine verschlossene Tür und eine Tür, an die man an der falschen Wand geklopft hat, sehen von außen gleich aus.

Ein leeres Ergebnis ist nur so viel wert wie die Methode, die es geliefert hat. Null Lücken ist nur dann eine gute Nachricht, wenn sich der Weg dorthin wiederholen lässt — deshalb liegt die Sonde als Skript im Repository und verweigert die Ausführung, solange die Anmelde-Umgehung aktiv ist.

Die Zahlen — 266 Zugangspunkte, 252 Ablehnungen, 14 bewusst öffentlich, 21 Fehlalarme der vorherigen Methode — stammen aus einer einzigen Messung am 6. August 2026, durchgeführt auf einer lokalen Kopie meines Systems mit einer Testdatenbank. Die Produktion habe ich nicht abgefragt.