DDoS-Schutz für öffentliche Portale: ohne Datenlecks cachen

DDoS-Schutz für öffentliche Portale beginnt mit einer klaren Trennung: Welche Informationen darf jeder lesen, und welche Vorgänge und Daten gehören zu einer bestimmten Person? Liefern Sie nachweislich öffentliche Antworten ressourcenschonend über ein Content Delivery Network, kurz CDN, aus. Halten Sie vertrauliche Antworten und Zugangsdaten aus gemeinsam genutzten Caches heraus. Prüfen Sie anschließend, ob Bewerberinnen und Bewerber sowie Sicherheitsforscherinnen und Sicherheitsforscher ihre Einreichungen auch bei aktiven Schutzregeln abschließen können.

Eine erreichbare Karriereseite ist nur ein Teil eines funktionierenden Einstellungsprozesses. Kandidaten müssen noch einen privaten Link öffnen, eine Datei hochladen und eine zutreffende Eingangsbestätigung erhalten. Sicherheitsforscher müssen die Meldehinweise finden und eine vertrauliche Meldung einreichen können. Wer die erste Seite schützt, dabei aber die folgenden Schritte blockiert, schließt genau die Menschen aus, denen das Portal dienen soll.

Der folgende Prüfablauf richtet sich an kleine Entwicklungsteams. Er verbindet die Erkenntnisse aus einem kürzlich veröffentlichten Vorfallsbericht mit einer praktischen Übung für Ihre eigene Anwendung. Er ist weder eine Bescheinigung der Angriffsfestigkeit noch eine Zusage, dass eine bestimmte Hosting-Konfiguration verfügbar bleibt.

Was hat Read the Docs aus ungecachten Anfragen gelernt?

Auch scheinbar triviale Anfragen können knappe Anwendungskapazität beanspruchen. Beginnen Sie mit den Pfaden, deren Anfragen den Ursprungsserver erreichen, auf dem Ihre Anwendung läuft. Gehen Sie nicht davon aus, dass allein die beliebtesten Seiten die Last verursachen.

Read the Docs veröffentlichte seinen Vorfallsbericht am 8. September 2026. Der Angriff selbst fand Mitte bis Ende Juni statt und dauerte fast zehn Tage. Der Anbieter meldete eine Spitze von mehr als 5,5 Millionen Anfragen pro Minute, wechselnde Anfragesignaturen und gezielte Zugriffe auf ungecachte Antworten. Temporäre Weiterleitungen erreichten zunächst das Python-Backend; das Team verlagerte sie an die Netzwerkkante. Anfragen nach immer neuen, nicht vorhandenen Pfaden verursachten ebenfalls aufwendige Cache-Misses. Zur Abwehr setzte das Team gezielte Sicherheitsprüfungen ein, weil eine solche Prüfung für jeden Besucher Integrationen gestört hätte.

Diese Beobachtungen betreffen Read the Docs, nicht Kit oder Ihr Unternehmen. Für Ihr Team ist eine engere Frage hilfreich: Welche vermeintlich einfachen Anfragen verursachen noch Arbeit in Ihrer Anwendung?

Beginnen Sie mit einem fiktiven Portal

Stellen Sie sich für diese Übung ein kleines Softwareunternehmen mit einer öffentlichen Karriereseite und einem Programm zur Meldung von Schwachstellen vor. Interessierte können eine Stellenbeschreibung anonym lesen. Kandidatinnen und Kandidaten gelangen über einen privaten Link zu ihrer Bewerbung. Forscherinnen und Forscher können die Sicherheitsrichtlinie lesen und anschließend Angaben einreichen, die vertraulich bleiben müssen.

Geben Sie der Recruiting-Fachkraft, der Sicherheitsleitung und dem zuständigen Entwickler jeweils ein leeres Blatt. Bitten Sie alle, ihren Ablauf vom Einstieg bis zur Bestätigung aufzuzeichnen. Beziehen Sie alte Lesezeichen und Links aus bereits versendeten E-Mails ein. Das ist ein Vorschlag für einen Workshop, keine Schilderung eines Kundenvorfalls.

Markieren Sie nun, an welchen Stellen der Anwendungsserver benötigt wird. Eine Weiterleitung kann eine Datenbankabfrage erfordern. Eine Fehlerseite kann ein personalisiertes Layout ausgeben. Ein Formular kann ein Token enthalten. Solche Abhängigkeiten sollten Sie kennen, bevor im Notfall jemand eine weitreichende Cache-Änderung vornimmt.

Für Zuständigkeitsfragen über diese Übung hinaus hilft unser Beitrag zu Self-Hosting und personeller Verantwortung. Konzentrieren Sie sich hier auf eingehende Anfragen und den Inhalt der jeweiligen Antwort.

Wie erkennen Sie, welche Portalantworten wirklich öffentlich sind?

Bewerten Sie die vollständige Antwort einschließlich ihrer Header und Varianten. Eine öffentlich wirkende Adresse beweist weder, dass alle Besucher denselben Inhalt erhalten, noch, dass ein gemeinsam genutzter Cache ihn gefahrlos wiederverwenden darf.

Der HTTP-Caching-Standard RFC 9111 unterscheidet drei leicht zu verwechselnde Direktiven. no-store untersagt Caches das Speichern der Antwort. private verhindert die Speicherung in einem gemeinsam genutzten Cache. no-cache erlaubt das Speichern, verlangt aber vor der Wiederverwendung eine Validierung. Auch ein Authorization-Header in der Anfrage bietet keinen absoluten Schutz: Explizite Antwortdirektiven können eine gemeinsame Wiederverwendung erlauben. Deshalb genügt es nicht, einen vertrauten Headernamen zu übernehmen.

Erfassen Sie die unterschiedlichen Antworten

Die folgende Tabelle ist als Arbeitsblatt für Ihre Prüfung gedacht. Sie unterstützt die technische Beurteilung und ist kein Compliance-Standard. Bestimmen Sie für jede Zeile eine Person, die die Nachweise zusammenträgt, und eine zweite, die das Ergebnis prüft.

Prüfen Sie konkrete Fälle mit Testkonten und fiktiven Daten. Vergleichen Sie zwei Mandanten, zwei Sprachen sowie angemeldete und anonyme Besucher, soweit diese Zustände vorkommen. Ergänzen Sie die tatsächlich unterstützten Zustände Ihres Produkts; betrachten Sie die Liste nicht als vollständig.

Achten Sie auch auf kleine Details einer Seite. Neben einer allgemeinen Stellenbeschreibung können der Name eines Kandidaten oder ein Formular-Token stehen. Dass der Haupttext öffentlich ist, macht die zusammengesetzte Antwort noch nicht gemeinsam nutzbar. Prüfen Sie, ob Sie öffentliche Daten von der privaten Oberfläche trennen sollten, statt die gesamte Seite als unbedenklich einzustufen.

Erhalten Sie Unterschiede, die den Inhalt verändern

Ein Cache-Schlüssel legt fest, welche Anfragen dieselbe Antwort anfordern. Cloudflares Dokumentation zu Cache-Schlüsseln beschreibt, wie das Ignorieren von Query-Strings Anfragen zusammenfassen kann, die sich in diesen Parametern unterscheiden. Diese Option verlangt eine Prüfung; sie ist keine Abkürzung, die Sie für das gesamte Portal einschalten sollten.

Notieren Sie in der Übung die Bedeutung jedes Schlüsselbestandteils. Der Host kann den Kunden bestimmen. Die Sprache kann die Anweisungen verändern. Ein Filter kann eine andere Stelle auswählen. Eine Zugangsberechtigung kann entscheiden, wer die Antwort sehen darf. Können Sie nicht begründen, warum ein Unterschied gefahrlos entfallen darf, erhalten Sie ihn bis zur Klärung.

Bewahren Sie bereinigte Nachweise des Vergleichs auf. Halten Sie fest, welche Routen und Zustände geprüft wurden und was noch unklar ist. Ein Screenshot allein belegt keine Cache-Regel. Nehmen Sie weder echte Kandidatenlinks noch vertrauliche Meldungsinhalte in das Prüfprotokoll auf.

Wie schützen Sie Weiterleitungen und Fehlerseiten?

Prüfen Sie Weiterleitungen und Fehlerantworten als eigenständige Ressourcen mit eigenen Anforderungen an Vertraulichkeit und Aktualität. Ein Statuscode beschreibt das Ergebnis. Er sagt nicht, ob die Antwort gemeinsam genutzt werden darf.

Beginnen Sie beim fiktiven Unternehmen mit einer alten Karriere-URL. Ist ihr Ziel fest und öffentlich, prüfen Sie, ob die Weiterleitung bereits vor dem Anwendungsserver erfolgen kann. Probieren Sie anschließend einen alten Kandidatenlink aus. Dessen Ziel könnte von der Authentifizierung oder dem Bewerbungsstatus abhängen. Er braucht daher eine eigene Entscheidung, selbst wenn beide Antworten denselben Weiterleitungsstatus verwenden.

Gehen Sie mit Fehlerseiten ebenso sorgfältig um. Eine kurz zwischengespeicherte öffentliche 404-Antwort kann wiederholte Arbeit für dieselbe fehlende Ressource vermeiden. Gegen einen unbegrenzten Strom neuer, nicht vorhandener Pfade hilft das nicht, denn jeder Pfad kann einen neuen Cache-Miss auslösen. Auch eine Antwort, die eine private Ressource vor unberechtigten Besuchern verbirgt, braucht andere Regeln als eine tatsächlich öffentliche Fehlerseite.

Bestimmen Sie, wer für veraltete Informationen verantwortlich ist

Caching wirft eine Produktfrage auf: Wie lange darf die Antwort von gestern noch sichtbar sein? Legen Sie diese Toleranz für jede öffentliche Ressource fest, statt eine bequeme Gültigkeitsdauer für die gesamte Website zu wählen.

Lassen Sie die Recruiting-Fachkraft für eine Stellenanzeige beschreiben, welche Folgen es hat, wenn eine geschlossene Stelle noch als offen erscheint. Bei einer Sicherheitsrichtlinie sollte die Sicherheitsleitung benennen, welche Änderungen sofort veröffentlicht werden müssen. Eine neue Kontaktadresse kann eine andere Behandlung verlangen als eine rein sprachliche Korrektur. Das sind Entscheidungen für diese Prüfung, keine allgemeingültigen Empfehlungen zu Ablaufzeiten.

Cloudflares Dokumentation zur Cache-Steuerung erläutert das Zusammenspiel von Ursprungsheadern, konfigurierten Ausnahmen, Cookies und der Auslieferung veralteter Inhalte. Prüfen Sie die tatsächliche Antwort am produktiv eingesetzten CDN. Eine Headerdeklaration im Anwendungscode belegt noch nicht, was Besucher erhalten.

Üben Sie eine Statusänderung mit einer Teststelle. Rufen Sie sie über den öffentlichen Pfad auf, schließen Sie sie und prüfen Sie, wann sich die öffentliche Darstellung ändert. Versuchen Sie danach die betreffende Aktion von der früheren Seite aus. Die Anwendung sollte anhand des aktuellen Zustands entscheiden, ob sie den Vorgang annimmt. Eine zwischengespeicherte Beschreibung ist keine Berechtigung zum Fortfahren.

Halten Sie Meldeinformationen aktuell

Eine Melderichtlinie braucht eine eigene Aktualitätsprüfung. RFC 9116 definiert security.txt, einschließlich des Felds Expires und der Meldekontakte. Abgelaufene Informationen sollten nicht mehr verwendet werden. Als Kontakte sind etwa Webadressen, E-Mail-Adressen oder Telefonnummern möglich. Die Datei dient jedoch der Meldung von Schwachstellen, nicht als allgemeine Notfallhotline.

Prüfen Sie in der Übung jeden veröffentlichten Meldeweg mit harmlosen Testinhalten im Rahmen eines abgestimmten Testverfahrens. Stellen Sie fest, wer sie erhält und wie der Absender über das Ergebnis informiert wird. Eine schnell ladende Richtlinie hilft nur, wenn ihre Anweisungen zu einem gepflegten Kontaktweg führen.

Falls Sie diesen Prozess erst aufbauen, beginnen Sie mit dem Leitfaden für ein Vulnerability Disclosure Program. Trennen Sie öffentliche Hinweise von der vertraulichen Meldung, deren Einreichung sie ermöglichen.

Wie verhindern Sie, dass Sicherheitsprüfungen Einreichungen blockieren?

Stimmen Sie Schutzregeln auf die betroffenen Clients und Aktionen ab. Ein Browser, der eine Seite anzeigt, kann auf dieselbe Sicherheitsprüfung ganz anders reagieren als eine Integration, die eine strukturierte Anfrage sendet.

Cloudflares Dokumentation zu Challenge-Seiten erläutert, dass diese Seiten HTML zurückgeben. Ein Client, der JSON erwartet, erhält damit möglicherweise eine unbrauchbare Antwort. Eine vorab erteilte Browserfreigabe kann bei geeigneten Browserabläufen helfen, ist aber keine allgemeine Lösung für APIs oder Webhooks.

Listen Sie für den vorgeschlagenen Test die Anfragen auf, die nach dem Öffnen der Seite erfolgen. Berücksichtigen Sie Einreichung, Upload, Authentifizierung und alle von Ihrer Integration verwendeten Callbacks. Notieren Sie zu jeder Anfrage das erwartete Antwortformat. Testen Sie den Ablauf anschließend in einer geeigneten Testumgebung mit der tatsächlich vorgesehenen Schutzregel.

Hören Sie nicht auf, sobald die erste Sicherheitsprüfung im Browser bestanden ist. Senden Sie das Formular ab, folgen Sie dem nächsten Link und prüfen Sie das gespeicherte Ergebnis. Schlägt ein Upload fehl, untersuchen Sie zuerst das Antwortformat, bevor Sie die Datei als Ursache vermuten. Schlägt ein Callback fehl, prüfen Sie ihn als eigenständigen Client. Ein erfolgreicher Browserablauf deckt ihn nicht automatisch ab.

Prüfen Sie Fehlalarme gemeinsam mit den Betroffenen

Fragen Sie Recruiting und Sicherheitsleitung, was ein zu Unrecht blockierter Nutzer sehen würde. Kann er erkennen, ob etwas eingegangen ist? Ist der nächste Schritt verständlich? Bleibt bei einem erneuten Versuch unklar, ob bereits eine Einreichung vorliegt?

Untersuchen Sie diese Zustände mit Testeinreichungen, ohne unerwartete Arbeit in produktiven Warteschlangen zu erzeugen. Vereinbaren Sie einen für Ihre Organisation geeigneten alternativen Kontaktweg. Vertrauliche Angaben gehören nicht auf öffentliche Statusseiten. Eine Ausweichseite darf keinen erfolgreichen Eingang melden, wenn der zugrunde liegende Vorgang nicht angenommen wurde.

Anfragelimits verdienen dieselbe Sorgfalt. Cloudflare dokumentiert NAT-geeignete Optionen zur Begrenzung von Anfragen mit Einschränkungen rund um Cookies; der Funktionsumfang hängt zudem vom Tarif ab. Die Hinweise zur Anfragerate erläutern, dass Zähler nicht global über alle Rechenzentren hinweg gemeinsam geführt werden. Eine Regel am CDN ist daher kein strikt durchgesetztes globales Transaktionslimit.

Wählen Sie für diese Prüfung keinen Zahlenwert, nur weil ein anderes Unternehmen ihn verwendet. Beobachten Sie Ihren regulären Ablauf und klären Sie, was eine wiederholte Aktion bedeutet. Viele Seitenaufrufe kurz hintereinander, ein großer Upload und wiederholte Formulareinreichungen haben unterschiedliche Folgen. Dokumentieren Sie den Zweck der Regel und welche Beobachtungen eine Änderung rechtfertigen würden.

Wie testen Sie den vollständigen Ablauf für Kandidaten und Forscher?

Prüfen Sie Erfolg, Ablehnung und Fehlerbehebung über den tatsächlich eingesetzten Schutzmechanismus. Verfügbarkeit bedeutet, dass eine berechtigte Person ihre Aufgabe abschließen und das Ergebnis verstehen kann. Eine erfolgreiche Antwort auf die Startseitenabfrage eines Monitors reicht dafür nicht.

Führen Sie die folgende Übung vor einer weitreichenden Änderung an Cache- oder Zugriffsregeln durch. Nutzen Sie synthetische Daten, vereinbarte Zuständigkeiten und klare Kriterien für ein Zurücksetzen der Änderung. Es ist eine Funktionsprüfung, kein Ersatz für einen gesondert geplanten Lasttest.

1. Lesen Sie die öffentlichen Informationen. Öffnen Sie die Stelle oder Richtlinie über den tatsächlichen Einstiegspfad. Prüfen Sie Kunde, Sprache, aktuellen Status und Kontaktdaten. Wiederholen Sie den Aufruf über einen alten öffentlichen Link, sofern vorhanden.
2. Beginnen Sie den privaten Ablauf. Verwenden Sie getrennte Testidentitäten. Prüfen Sie, dass jede Person nur ihre eigenen Informationen sieht und eine anonyme Anfrage keine Antwort eines vorherigen Besuchers erhält.
3. Schließen Sie den Vorgang ab. Reichen Sie die Testbewerbung oder Testmeldung ein und laden Sie gegebenenfalls eine harmlose Datei hoch. Prüfen Sie den angenommenen Datensatz in der zuständigen internen Oberfläche.
4. Lösen Sie einen gewöhnlichen Fehler aus. Verwenden Sie eine ungültige Feldeingabe oder einen abgelaufenen Testlink. Prüfen Sie, dass die Erklärung hilfreich ist und keine Informationen einer anderen Person offenlegt.
5. Ändern Sie den öffentlichen Zustand. Schließen Sie die Teststelle oder überarbeiten Sie die Testrichtlinie. Prüfen Sie die Aktualität und wiederholen Sie die betreffende Aktion von einer älteren Seite aus.
6. Untersuchen Sie jeden Client. Prüfen Sie Browseranfragen und Integrationen getrennt. Erfassen Sie Inhaltstypen, das Verhalten bei Sicherheitsprüfungen und die Möglichkeiten des Clients zur Fehlerbehebung.

Berücksichtigen Sie Menschen, die ohne Maus navigieren. Unsere Checkliste für tastaturbedienbare Kandidatenportale behandelt diesen Teil des Ablaufs. Eine während eines Vorfalls ergänzte Sicherheitsprüfung oder Fehlerbehebungsseite braucht dieselbe Aufmerksamkeit wie das ursprüngliche Formular.

Legen Sie fest, wann die Änderung freigegeben werden darf

Vereinbaren Sie vor dem Test, welche Nachweise für eine Freigabe nötig sind. Für das fiktive Team bieten sich folgende Kriterien an: Öffentliche Informationen bleiben korrekt, private Antworten bleiben voneinander getrennt, vorgesehene Einreichungen gelingen und abgelehnte Vorgänge erhalten eine zutreffende Rückmeldung. Weisen Sie jedem Fehler eine verantwortliche Person zu, statt alle Ergebnisse in einer Verfügbarkeitsquote zusammenzufassen.

Halten Sie knapp fest, welche Regel geändert wurde, welche Zustände geprüft wurden, was Sie beobachtet haben und wie sich die Änderung zurücksetzen lässt. Vergleichen Sie das Verhalten des CDN mit dem der Anwendung, soweit Sie beides einsehen können. Benennen Sie verbleibende Lücken genau: Ein ungeprüfter Callback ist etwas anderes als eine fehlgeschlagene Bewerbung.

Wiederholen Sie die betroffenen Prüfungen, wenn Sie die Regel oder den Ablauf ändern. Es bringt wenig, immer wieder eine unveränderte Startseite zu testen, während ein neuer Upload-Pfad ungeprüft bleibt. Richten Sie den Prüfumfang nach dem Umfang der Änderung aus.

Wo trennt Kit öffentliche Informationen von vertraulichen Vorgängen?

Ein Produkt kann sowohl öffentliche Informationen als auch vertrauliche Abläufe enthalten, die unterschiedlich behandelt werden müssen. Prüfen Sie vor einer Cache-Entscheidung die tatsächliche Antwort, auch wenn im Namen des Controllers oder der Route „public“ steht.

Im am 10. September geprüften Kit-Quellcode deklariert die JSON-Antwort für eine Stelle, die Bewerbungen annimmt, eine öffentliche Cache-Gültigkeit von fünf Minuten. Die security.txt-Antwort eines aktiven Sicherheitsprogramms deklariert eine öffentliche Gültigkeit von einer Stunde. Das sind eng begrenzte Anwendungsdeklarationen, keine Messungen des produktiven CDN-Verhaltens oder der Verfügbarkeit von Einreichungen.

Der Kandidatenablauf ist anders. Ein Magic-Link-Token ermittelt die Kandidatin oder den Kandidaten samt Bewerbungen, Interviews, Angeboten und zugehörigem Zustand. Auch der HTML-Pfad einer öffentlichen Stellenanzeige kann eine Zugangsberechtigung für einen Kandidaten aus der Sitzung auslesen. Deshalb lässt sich nicht jede anonym erreichbare Seite als austauschbarer öffentlicher Inhalt behandeln.

Kit enthält außerdem Anfragelimits für Einreichungen in der Anwendungs-Middleware. Das ist eine Schutzebene im Anfragepfad, kein Beleg dafür, dass vorgelagerter Datenverkehr keine Ressourcen erschöpfen kann. Dieser Beitrag enthält weder eine Prüfung produktiver Antworten noch einen Lasttest oder eine DDoS-Garantie. Auch Referrer- und Indexierungsschutz belegen nicht, dass eine Antwort Cache-Control: no-store sendet.

Erfassen Sie die unterschiedlichen Antworten Ihres eigenen Portals mit derselben Sorgfalt. Liefern Sie nachweislich öffentliche Informationen ressourcenschonend aus, geben Sie privaten Abläufen eigene Regeln und prüfen Sie die Bestätigung, auf die ein Mensch sich verlassen muss.