Wenn Sie eine Website betreiben, auf der Tickets verkauft werden, limitierte Artikel angeboten werden oder Verkäufe mit hoher Nachfrage abgewickelt werden, wissen Sie bereits, was passiert, wenn zu viele Besucher gleichzeitig auf die Seite zugreifen.
Die Website bricht zusammen, echte Kunden erhalten Fehlerseiten, und Bots schnappen sich unbemerkt alles, was gerade im Angebot ist.
Ein virtueller Warteraum ist die Standardlösung: Bei Nachfragespitzen hält CrowdHandler die Besucher in einer geordneten Warteschlange und leitet sie in einem Tempo weiter, das Ihre Infrastruktur tatsächlich bewältigen kann – so bleibt die Website erreichbar und jeder hat eine faire Chance.
Das funktioniert gut, wenn sich der Warteraum vor Ihrer gesamten Website befindet. Das Problem ist, dass moderne Apps zunehmend nicht mehr auf diese Weise aufgebaut sind und viele von ihnen auf eine Weise geschützt sind, die zwar solide wirkt, es aber nicht ist.
Der Scanner, der nie piept
Du kennst das ja: die Sicherheitskontrolle. Der Türsteher tastet dich ab, ihr nickt euch zu, und schon darfst du durch. Eigentlich wurde gar nichts überprüft. So funktionieren die meisten Web-Apps: viel Aufhebens, aber kein echter Kontakt.
Warum bauen alle so?
Der moderne Stack lässt sich also klar in zwei Teile unterteilen.
- Es gibt ein Frontend, das in der Regel statisch oder serverseitig gerendert wird.
- Es gibt eine API, die etwas abseits steht, oft auf einer eigenen Domain und manchmal in einer völlig separaten Cloud.
Dies ist mittlerweile der Standard. Next.js, Nuxt, Remix, SvelteKit und Astro empfehlen dies allesamt. Headless-Commerce-Plattformen liefern es Ihnen bereits aufgeteilt: eine gehostete Storefront auf der einen Seite und eine öffentliche API auf der anderen – wobei die technische Umsetzung dem Nutzer überlassen bleibt.
Hosten Sie das Frontend auf Vercel, Netlify oder Cloudflare Pages, und schon haben Sie das Modell, auf das im Jahr 2026 fast jede E-Commerce- und Ticketing-Lösung setzt: ein schnelles, größtenteils statisches Frontend und eine API, die die eigentliche Arbeit an anderer Stelle erledigt.
Hervorragend für die Entwicklererfahrung. Hervorragend für die Seitengeschwindigkeit. Allerdings versagt hier das Sicherheitsmodell.
Warum das Frontend nur noch eine Hülle ist
Das Frontend ist federleicht. Es besteht aus Markup, Skripten und ein bisschen Styling, und man könnte die Hälfte des Internets darauf loslassen, ohne dass es mit der Wimper zuckt, denn es gibt dort fast nichts, was es überfordern könnte.
Jede teure, empfindliche und kritische Funktion läuft über die API. Wenn also Ihr Wartezimmer die statische Website umgibt, während Ihre API domänenübergreifende Aufrufe unter ihrer eigenen Adresse beantwortet, haben Sie den Teil geschützt, der ohnehin nie ausfallen würde, und den Teil, der tatsächlich ausfällt, völlig ungeschützt gelassen.
Kunden kommen durch den bewachten Eingang herein. Ärger schleicht sich durch eine Seitentür herein, die niemand im Blick hat.
Das begegnet uns ständig: SPAs und SPA-ähnliche Apps, die genau auf diese Weise aufgebaut sind. Viele Leute würden es ehrlich gesagt lieber nicht wissen, und solange noch nichts kaputt ist, hat es durchaus seine Logik, den Stein nicht umzudrehen.
Die Teams, die es lieber klar und deutlich sehen möchten, wollen einen Warteraum, der sich über beide Hälften erstreckt, und keinen Schutzschild, der nur die harmlose Hälfte schützt.
Dafür haben wir zwei bewährte Methoden.
Strategie 1: Leiten Sie die API über Ihre Hauptdomain weiter
Die beste Lösung – sofern das machbar ist – besteht darin, die API gar nicht mehr als separate Adresse zu behandeln. Leiten Sie deren Aufrufe über Ihre Hauptdomain weiter und setzen Sie eine Schutzschicht für das gesamte System ein, sei es CrowdHandler, Cloudflare oder was auch immer bereits im Einsatz ist.
Wenn Sie das tun, wird das schlanke Frontend endlich zum Sprachrohr des gesamten Systems. Ein DDoS-Versuch erhält einen Platz in der Warteschlange. Ein API-Aufruf, der den „Happy Path“ umgeht, erhält einen Platz in der Warteschlange. Der Angreifer wartet in der Schlange hinter Ihren echten Kunden, genau wie jeder andere auch. Wenn Ihre Architektur Spielraum für eine solche Anpassung bietet, sollten Sie diese Möglichkeit als Erstes in Betracht ziehen.
Strategie 2: Edge-Mitarbeiter vor den kritischen Endpunkten
Wenn es sich nicht biegen lässt, muss man chirurgisch vorgehen. Die Kantenbearbeiter haben vor dem API an den ein oder zwei Stellen, die die Last tragen, Einschnitte vorgenommen.
In einem Online-Shop ist das fast immer der Aufruf „In den Warenkorb“, und es lohnt sich, die Gründe dafür näher zu erläutern. Ohne diesen Schritt ist der Bezahlvorgang nicht möglich, daher ist er die naheliegende Schwelle. Allerdings birgt er auch eine Gefahr, denn jemand, der lediglich Artikel in den Warenkorb legen kann, kann echten Käufern das Einkaufserlebnis verderben, ohne jemals auch nur einen einzigen Artikel zu kaufen.
Das ist der klassische Trick der Ticket-Bots: Sie stopfen den Warenkorb voll, damit echte Käufer nicht mehr an die Artikel herankommen, und verkaufen dann den Zugang weiter oder geben die Artikel frei, um sie anschließend immer wieder neu zu ergattern – und das immer und immer wieder.
Der Worker bewältigt dies, indem er sich bei der CrowdHandler-API anmeldet und die Zugriffe anhand der Produkt-ID zählt, wobei er sie so behandelt, als wären sie auf der Seite gelandet, die normalerweise den Aufruf auslöst – in der Regel die Produktdetailseite. Haben Sie sich nicht ordnungsgemäß in die Warteschlange für diese Seite eingereiht? Dann findet der API-Aufruf für Sie nicht statt.
Die Platzierung des Workers genau an dieser Stelle hat einen stillen Vorteil. Er befindet sich direkt am eigentlichen Engpass – nämlich der API und nicht der statischen Website –, was bedeutet, dass unser Autotune die tatsächlich ausgelastete Ebene erfassen und Nutzer mit einer Rate durchlassen kann, die der Realität entspricht.
Wenn man nur die Host-Seite betrachtet, sieht man eine Komponente, die im Grunde nie ins Schwitzen gerät – das ist so, als würde man mit verbundenen Augen optimieren. Da diese Host-Seite zudem so wenig leistet, bleibt ihr Teil der Integration trivial: ein bisschen JavaScript, um die Personen bei Bedarf beiseite zu schieben, während die gesamte eigentliche Validierung und Steuerung unten auf der API-Ebene stattfindet.
Die Falle funktioniert nur, wenn jedes Teil hält.
Es gibt eine Regel, die man auf keinen Fall ignorieren darf, und genau diese wird oft übersehen: Beende die Sitzung sofort, sobald sich jemand abmeldet.
Sobald ein Besucher bezahlt hat, muss diese Sitzung beendet werden, damit sie nicht für eine zweite Runde wiederbelebt werden kann. Bleibt sie aktiv, stellt sich ein fähiger Bot genau einmal in die Warteschlange und führt dann die Transaktion endlos in einer Schleife durch. Setzt man diese Regel durch, nimmt man diese Möglichkeit weg und zwingt den Angreifer, sich jedes Mal wie ein gewöhnlicher Käufer im „Happy Path“ zu verhalten – durch die Warteschlange, über die Produktseite bis hin zum validierten Aufruf.
Die Falle fängt nur dann etwas ein, wenn jedes Teil fest sitzt. Ein einziges lockeres Teil, und das Ganze schnappt in der Leere zu.
Sie müssen Ihre App nicht neu schreiben.
Um den Umfang klar zu stellen: Es handelt sich hierbei nicht um eine Neuentwicklung. Es geht hauptsächlich darum, Edge-Worker zu laden und anzupassen, die wir bereits erstellen und pflegen, wobei Versionen für folgende Zwecke bereitstehen:
- AWS CloudFront
- Cloudflare
- Netlify
- Akamai
Sie sichern ein oder zwei Endpunkte ab, ohne Ihren Kerncode anzurühren. Wir haben dies bereits für eine Vielzahl von Kunden mit den unterschiedlichsten Technologie-Stacks diskret umgesetzt, und genau derselbe Mechanismus läuft auch hinter den Kulissen unserer Shopify-Integration.
Wenn das ein Gespräch wert ist
Wenn Ihnen im Hinterkopf immer wieder der Gedanke durch den Kopf geht, dass Ihre Infrastruktur etwas anfälliger ist, als Sie laut zugeben würden, sprechen Sie uns an. Selbst wenn Ihnen eine herkömmliche Warteschlange wie übertrieben erscheint: Auf diese Weise erhalten Sie eine elegante Ratenbegrenzung und DDoS-Schutz, die in genau die Teile Ihrer App integriert sind, die tatsächlich nachgeben – und nicht in die Teile, die nicht einmal mit der Wimper zucken.
Brauchst du etwas mehr Sicherheit? Melde dich kostenlos bei CrowdHandler an.