Was tun, wenn Sie eine Sicherheitslücke bei einem Anbieter entdecken

Eine Sicherheitslücke bei einem fremden Anbieter zu finden, ist meistens Zufall. Was danach passiert, ist keiner mehr.

Vor Kurzem bin ich bei einer Analyse für einen Kunden über eine offene Stelle bei einem Drittanbieter gestolpert: eine sogenannte IDOR-Lücke — Insecure Direct Object Reference. Über eine einfach hochgezählte ID in der URL ließen sich fremde Datensätze abrufen, ganz ohne Login-Umweg. Kein Passwort geknackt, kein Angriff im klassischen Sinn. Nur eine Zahl, die zeigte, dass niemand geprüft hatte, wem der Datensatz eigentlich gehört.

Genau in diesem Moment beginnt die eigentliche Aufgabe. Nicht die technische — die ist meistens in Minuten erledigt. Die schwierige Frage lautet: Was mache ich mit diesem Wissen, ohne selbst zum Problem zu werden?

Der Moment, in dem aus Neugier ein Risiko wird

Wer eine Lücke findet und weiterklickt, um zu sehen, wie weit sie trägt, verlässt einen Bereich, den das Gesetz genau kennt. Nach §202a StGB macht sich strafbar, wer sich unbefugt Zugang zu Daten verschafft, die nicht für ihn bestimmt und besonders gesichert sind. Die Reform von 2021 hat mit einer Art Whitehat-Klausel etwas Luft geschaffen für gutgläubige Sicherheitsforschung — verhältnismäßig, mit dem Ziel einer Meldung, ohne Bereicherungsabsicht. Verlässlich ist das trotzdem nur, wenn ich mich strikt daran halte, was zum Nachweis nötig ist, und keinen Schritt darüber hinaus.

Der Unterschied zwischen einem Fund und einem Vorfall entscheidet sich also nicht an der Technik, sondern an der Grenze, die ich mir selbst setze.

Was ich konkret tue, wenn ich eine Lücke finde

Aufhören, sobald der Nachweis steht. Ein einziger fremder Datensatz beweist die Lücke vollständig. Jeder weitere zeigt nur, dass ich weitergemacht habe, obwohl ich es nicht musste.

Dokumentieren, nicht sammeln. Ein Screenshot des betroffenen Endpunkts, die Uhrzeit, die genaue Schrittfolge — das reicht für eine nachvollziehbare Meldung. Eine Kopie fremder Daten auf der eigenen Festplatte ist kein Beweismittel, sondern selbst ein Problem.

Den richtigen Kanal suchen, nicht den lautesten. Zuerst eine security.txt unter /.well-known/security.txt, danach eine direkte Mail an den technischen Kontakt, notfalls das Impressum. Ein Forumsbeitrag oder ein Social-Media-Post ist zu diesem Zeitpunkt nie der richtige Ort — er nimmt dem Anbieter die Zeit, die er für eine saubere Behebung braucht.

Keine Forderung stellen. Ein Hinweis auf eine Lücke ist etwas anderes als ein Angebot, sie gegen Geld verschwinden zu lassen. Die Grenze zwischen einer Bug-Bounty-Anfrage und einer Erpressung ist schmaler, als sie sich anfühlt — im Zweifel formuliere ich die Meldung so, dass daran kein Zweifel aufkommen kann.

Wie eine Meldung aussieht, die ernst genommen wird

Eine gute Meldung beantwortet drei Fragen, bevor der Empfänger sie stellen muss: Was genau ist das Problem, wie lässt es sich mit minimalem Aufwand nachvollziehen, und welche Daten oder Systeme sind betroffen. Dazu ein realistischer Zeitrahmen für eine Antwort — in der Sicherheitsforschung haben sich 90 Tage bis zur öffentlichen Beschreibung als fairer Standard etabliert, mit der Möglichkeit einer Verlängerung, wenn der Anbieter erkennbar an einer Lösung arbeitet. Und das Angebot, die Behebung nach dem Fix noch einmal zu prüfen, bevor irgendwo darüber gesprochen wird.

Die andere Seite: wenn Sie selbst eine Meldung bekommen

Für Technikentscheider ist die spiegelbildliche Situation mindestens genauso wichtig. Wenn jemand Ihrem Unternehmen eine Sicherheitslücke meldet, entscheidet die erste Reaktion, ob daraus ein stiller Fix oder eine öffentliche Geschichte wird. Eine erreichbare security.txt kostet eine halbe Stunde und erspart dem Finder die Suche nach einem Ansprechpartner im Impressum. Eine schnelle, dankbare Antwort — auch wenn die eigentliche Behebung Tage dauert — verhindert, dass jemand aus Frust doch den lauteren Weg wählt. Und der Griff zum Anwalt, bevor überhaupt geprüft wurde, ob die Meldung berechtigt ist, hat schon öfter aus einem hilfreichen Hinweis einen Konflikt gemacht, der öffentlich schlechter aussieht als die ursprüngliche Lücke.

Was ich nicht verspreche

Responsible Disclosure ist kein Freibrief. Die Whitehat-Klausel schützt, wer sich nachweislich an die Grenzen hält — sie schützt nicht automatisch jeden, der im Nachhinein behauptet, es gut gemeint zu haben. Bei allem, was über eine einfache, offensichtliche Lücke hinausgeht, oder wenn ich unsicher bin, ob mein nächster Schritt noch als Nachweis zählt oder schon als Zugriff, hole ich mir vorher rechtlichen Rat — nicht hinterher.

Und nicht jeder Anbieter reagiert so, wie er sollte. Manche schweigen, manche drohen zuerst. Das ändert nichts daran, dass der saubere Weg der richtige bleibt — er sorgt nur dafür, dass ich am Ende die bessere Position habe, falls es doch unangenehm wird.

Wenn Sie unsicher sind, wie Sie reagieren sollen

Ob Sie selbst auf eine Lücke bei einem Anbieter gestoßen sind oder gerade eine Meldung zu Ihrem eigenen System auf dem Tisch liegen haben — beides sind Situationen, in denen die ersten Schritte über den Ausgang entscheiden. Wenn Sie unsicher sind, wie eine Meldung einzuordnen ist oder wie Sie intern reagieren sollten: Schreiben Sie mir.