Denial of Inventory: Der Warenkorb als Angriffsvektor

Ein Onlineshop kann technisch einwandfrei laufen – stabile Server, niedrige Latenz, keine Häufung von Fehlern und trotzdem keine Umsätze mehr erzielen, weil gefragte Artikel systemseitig als „nicht verfügbar" ausgewiesen werden, obwohl physisch Bestand vorhanden ist. Verantwortlich dafür kann eine Angriffsklasse sein, die sich nicht gegen die Infrastruktur richtet, sondern gegen die Geschäftslogik der Anwendung oder Online Shops. In der Praxis wird sie häufig pauschal als „DDoS auf Applikationsebene" bezeichnet. Diese Einordnung ist unpräzise und führt bei der Verteidigung in die falsche Richtung.

Einordnung und Terminologie

Der etablierte Fachbegriff stammt aus dem Projekt OWASP Automated Threats to Web Applications und lautet OAT-021 Denial of Inventory. OWASP definiert den Angriff als die Erschöpfung von Beständen, ohne dass der Kauf jemals abgeschlossen wird: Artikel werden ausgewählt und im Warenkorb gehalten, aber nie gekauft, bezahlt oder bestätigt mit der Folge, dass andere Nutzer diese nicht mehr erwerben können. Synonym gebräuchlich sind Bezeichnungen wie Inventory Hoarding, Stock Exhaustion, Hold-all Attack sowie, im Reservierungskontext, Seat Spinning.

Für eine korrekte Bewertung ist die Abgrenzung zu zwei verwandten Bedrohungen aus demselben Katalog entscheidend:

  • OAT-015 (Application) Denial of Service bezeichnet die gezielte Auslastung von Ressourcen mit dem Ziel, die Anwendung zu verlangsamen oder unverfügbar zu machen. Hier wird die technische Infrastruktur belastet. Dies entspricht dem, was umgangssprachlich als „Application-Layer-DDoS" gemeint ist.
  • OAT-005 Scalping beschreibt Bots, die begehrte Ware tatsächlich erwerben, um sie anschließend mit Aufschlag weiterzuverkaufen. Der Angreifer gelangt dabei in den Besitz des Produkts.

Denial of Inventory unterscheidet sich von beiden: Der Angreifer kauft nicht und verringert dennoch den verfügbaren Bestand. Es entsteht weder eine signifikante Server-Last noch eine abgeschlossene Transaktion, die als Spur dienen könnte. Das Lager erscheint im System als leer, während die Ware tatsächlich verfügbar wäre.

Funktionsweise

Der Angriff missbraucht eine verbreitete Designentscheidung vieler Shopsysteme: Der Bestand wird bereits beim Hinzufügen zum Warenkorb reserviert und nicht erst bei der Zahlung verbindlich gebunden. Diese Logik dient ursprünglich der Kundenfreundlichkeit, da sie verhindern soll, dass ein im Checkout befindlicher Artikel zwischenzeitlich vergriffen ist. Genau diese Reservierungsmechanik bildet jedoch die Angriffsfläche.

Ein typischer Ablauf gliedert sich in folgende Schritte:

  1. Automatisierte Clients greifen den add-to-cart-Endpoint hochparallel ab, häufig über hunderte oder tausende Sessions und Residential-Proxies, um nicht als einzelner Akteur erkennbar zu sein.
  2. Jede Session legt knappe oder besonders nachgefragte Artikel in den Warenkorb, nach Möglichkeit in maximaler Stückzahl.
  3. Der Checkout wird bewusst nicht ausgeführt. Stattdessen wird die Reservierung gehalten und – sofern der Warenkorb über ein Timeout verfügt – kurz vor dessen Ablauf erneuert.
  4. Aus Sicht des Bestandssystems gilt die Ware als gebunden. Legitime Kunden erhalten die Meldung „nicht verfügbar" und wechseln zu anderen Anbietern.

Liegt das Cart-Timeout beispielsweise bei 30 Minuten und erneuert der Client die Reservierung in kürzeren Intervallen, bleibt der Bestand dauerhaft blockiert, ohne dass eine auffällige Kaufaktivität entsteht.

Die Reservierungsvariante ist nicht auf physische Ware beschränkt. OWASP nennt ausdrücklich auch Hotelzimmer, Restauranttische, Flugsitze, Termin-Slots, Warteschlangenplätze und Kontingentzuteilungen. Überall, wo eine Ressource ohne vorherige Bezahlung gehalten werden kann, lässt sich die Verfügbarkeit gezielt sabotieren.

Gründe für die schwierige Erkennung

Klassische Schutzmechanismen greifen bei dieser Angriffsklasse nur eingeschränkt, was strukturelle Ursachen hat. Eine Web Application Firewall prüft auf bösartige Requests wie SQL-Injection, Cross-Site-Scripting oder Protokollanomalien. Ein Denial-of-Inventory-Bot sendet hingegen formal einwandfreie, RFC-konforme Anfragen. Das Hinzufügen eines Artikels zum Warenkorb entspricht exakt dem vorgesehenen Verhalten des Endpoints; es existiert kein Request-Merkmal, das blockiert werden könnte, ohne auch legitime Kunden zu betreffen.

Auch volumetrische, ratenbasierte Erkennung stößt an Grenzen. Wird die Last über eine ausreichend große Zahl von Sessions und IP-Adressen verteilt, bleibt jede einzelne Anfrage unterhalb der Schwellenwerte. Der Schaden entsteht nicht durch ein lautes Einzelsignal, sondern durch die Summe vieler unauffälliger Aktionen.

Hinzu kommt ein häufig unterschätzter Reputationsschaden. Wiederholt angezeigte Nichtverfügbarkeit untergräbt das Vertrauen der Kunden und kann sich negativ auf die Markenbindung auswirken, da Engpässe als Unfähigkeit oder als Absicht des Händlers interpretiert werden.

Praxisrelevanz und Beispiele

Die Bedrohung ist gut dokumentiert. Wiederkehrende Beispiele sind die Spielekonsole PlayStation 5, deren Bestände seit dem Marktstart Ende 2020 regelmäßig binnen kurzer Zeit ausverkauft sind, sowie Grafikkarten: Beim Launch der NVIDIA RTX 5090 und 5080 Anfang 2025 war der Bestand bei Händlern wie Best Buy und Newegg sowie im NVIDIA-Store innerhalb weniger Minuten vergriffen. Ebenfalls betroffen sind limitierte Sneaker-Releases sowie saisonal nachgefragtes Spielzeug, in dessen Kontext sich der Begriff „Grinch Bots" für Hoarding-Bots im Weihnachtsgeschäft etabliert hat.

Zur Größenordnung liegen Anbieterzahlen vor, die methodisch variieren, in der Tendenz aber konsistent sind: Cloudflare berichtete, innerhalb eines Jahres über 300 Milliarden Bot-Versuche an „Add-to-Cart"-Endpoints erkannt zu haben, wobei es sich dabei nur um die erfolgreicheren Versuche handelte. Radware schätzt, dass an Spitzentagen wie Black Friday bis zu 97 Prozent des Traffics auf Login-Seiten von Händlern automatisiert sein können. Diese Werte sind als Schätzungen einzuordnen, belegen jedoch den erheblichen Anteil automatisierten Traffics an kritischen Verkaufstagen.

Die rechtliche Lage bietet derzeit nur begrenzten Schutz. In den USA existiert seit 2016 der BOTS Act gegen Ticket-Scalping; der weiter gefasste Stopping Grinch Bots Act wurde mehrfach (2018 und 2021) eingebracht, bislang aber nicht verabschiedet. Eine Verteidigung allein auf gesetzlicher Grundlage ist daher nicht tragfähig; die Maßnahmen müssen technischer und organisatorischer Natur sein.

Gegenmaßnahmen

Gegen Denial of Inventory existieren wirksame Maßnahmen. Sie liegen überwiegend in der Anwendung selbst und nicht in der Netzwerk-Perimeter-Schicht.

Reservierungslogik anpassen. Der wirksamste Hebel besteht darin, Bestand erst bei der Zahlungsautorisierung verbindlich zu binden und nicht bereits beim Hinzufügen zum Warenkorb. Der Status „im Warenkorb" sollte eine unverbindliche Vormerkung darstellen. Ist eine vollständige Umstellung nicht möglich, sollten zumindest kurze, fest definierte Reservierungs-Timeouts gesetzt und das automatische Verlängern unterbunden werden.

Endpoint-spezifisches Rate Limiting. Begrenzungen sollten gezielt auf den add-to-cart-Endpoint und Reservierungsaktionen angewendet werden – differenziert nach Account, Session und IP-Reputation – und durch Stückzahllimits pro Kunde ergänzt werden.

Bot Management ergänzend zur WAF. Verhaltensanalyse, Geräte-Fingerprinting (zur Erkennung von Automatisierungs-Frameworks wie Puppeteer, Selenium oder Headless Chrome) und IP-Intelligence erkennen Automatisierung auch dort, wo der einzelne Request legitim erscheint. Damit wird die Lücke geschlossen, die eine WAF strukturell offenlässt.

Aussagekräftige Metriken überwachen. Der relevanteste Indikator ist nicht die Server-Last, sondern das Verhältnis von Add-to-Cart-Aktionen zu abgeschlossenen Käufen. Ein deutlicher Anstieg der Warenkorb-Aktivität bei gleichzeitig einbrechender Conversion-Rate ist ein starkes Warnsignal.

Waiting Rooms und Queues bei Releases. Bei geplanten Veröffentlichungen knapper Ware reduziert eine vorgeschaltete, fair getaktete Warteschlange die Echtzeit-Race-Condition, von der automatisierte Clients profitieren.

Organisatorische Flankierung. AGB-Klauseln, die Bot-gestützte Bestellungen untersagen und eine Stornierung bei Verdacht ermöglichen, schaffen eine rechtliche Handhabe. Verfahren wie reCAPTCHA erhöhen zudem den Aufwand für Angreifer, stellen für sich genommen jedoch keinen vollständigen Schutz dar.

Fazit

Denial of Inventory verdeutlicht, dass Sicherheit nicht an der Firewall endet. Der Angriff nutzt keine Schwachstelle im klassischen Sinne, sondern missbraucht eine aus Kundenfreundlichkeit eingeführte Funktion. Für Betreiber von E-Commerce-Anwendungen ist die Konsequenz eindeutig: Nicht jede Verfügbarkeitsstörung ist auf einen Lieferengpass zurückzuführen. Eine fundierte Bewertung erfordert die Unterscheidung zwischen tatsächlichem Bestandsmangel, infrastrukturellem Denial of Service und gezielter Bestandsblockade durch automatisierte Clients.

Quellen