Elena Calvillo öffnet an einem Dienstagmorgen das Datenbank-Dashboard von DraftKit und filtert die Tabelle collab_requests. Sechs Einträge stammen von Adressen mit .ru-Endung, vier haben im Nachrichtenfeld nur Platzhaltertext, einer trägt als Substack-URL „test123“. Später nennt die Entwicklerin das den Moment, in dem aus einem theoretischen Risiko ein Haufen Datenmüll wurde.
Ausgelöst hat die Prüfung keine Monitoring-Warnung, sondern eine Nachricht. Rund drei Wochen nach dem Start der öffentlichen Buchungsseiten meldete sich eine Creatorin, die zwei unbearbeitete Anfragen in ihrem Collabs-Tab nicht einordnen konnte: unbekannte Namen, Newsletter-URLs, die ins Leere führten. DraftKit vergibt an jede Person, die dort eine Seite betreibt, eine öffentliche Buchungsseite unter draftkit.app/[username] — ohne Login, für jeden erreichbar, mit einem Formular für Kollaborationsanfragen, dessen Eingaben direkt in der Warteschlange der Creatorin landen. Das ist das Produkt. Genauso ist es das Problem, sobald niemand prüft, wer das Formular ausfüllt.
Was die Datenbankzeilen über den Eindringling zeigen
Der deutlichste Hinweis steckte nicht in den Absenderadressen, sondern in einem Schritt, der fehlte. Das Formular enthält eine KI-Prüfung namens SMART Match, die eingereichte Angaben gegen das Creator-Profil abgleicht. Dieser Schritt läuft im Browser und braucht JavaScript. Keine der auffälligen Zeilen hatte ihn durchlaufen. Der Bot hatte also nicht das Formular benutzt, sondern direkt die Schnittstelle angesprochen, die einen Datensatz annimmt und einfügt — vorbei an allem, was im Frontend passiert.
Beim Nachprüfen zeigte sich, dass der Vorfall kein Einzelfall war. Zwei weitere aktive Buchungsseiten hatten bei einer Stichprobe je ein bis zwei verdächtige Übermittlungen. Das Muster wiederholte sich: bestimmte Länderendungen, Platzhaltertexte im Nachrichtenfeld, erfundene URLs. Für die betroffenen Creator sieht das aus wie ein volles Postfach mit Anfragen, die niemand gestellt hat. Für das Produkt wie ein offenes Notizbuch vor der Tür, in das jeder hineinschreiben darf — nur landen die Einträge auf dem Tisch der Creatorin.
Warum KI-Builder öffentliche Booking-Formulare ohne Schutz ausliefern
Lovable und vergleichbare Werkzeuge erzeugen eine React-Komponente, die sauber absendet, das E-Mail-Format prüft und eine Zeile in die Datenbank schreibt. Was sie nicht erzeugen, ist der Schritt, der bestätigt, dass die Übermittlung aus einem echten Browser kommt und nicht aus einem Skript. Die Entwicklerin ordnet das nicht als Fehler des Builders ein, sondern als Frage nach dem Bedrohungsmodell: Welche Route ist öffentlich, welche nimmt Nutzereingaben entgegen, und was passiert, wenn diese Eingaben automatisiert kommen?
Diese Frage stellt sich während der Entwicklung selten, weil alle Tests bestanden werden. Dein Formular validiert korrekt, die Zeile erscheint in der Tabelle, der Happy Path funktioniert. Der erste Bot-Eintrag trifft dann meist rund 72 Stunden nach dem Livegang ein, sobald die Domain indexiert ist und die ersten Crawler die Seite gefunden haben. Cloudflare veröffentlichte 2025 Radar-Daten, nach denen Bots die Mehrheit des HTML-Verkehrs in ihrem Netz ausmachen; der Anteil ist seither jedes Quartal gewachsen. Wer eine öffentliche Formularseite betreibt, ist Teil dieser Statistik, ob er will oder nicht.
Cloudflare Turnstile in ein Formular einbauen: wenig Reibung, kein Klickrätsel
Als Gegenmaßnahme nennt die Entwicklerin Cloudflare Turnstile, weil es sich in ein bestehendes Produkt einfügen lässt, ohne die Nutzererfahrung umzubauen. Der Dienst ist bis eine Million Anfragen pro Monat kostenlos, für echte Besucher unsichtbar und braucht nur zwei Dinge: ein Skript-Tag auf der Seite und ein verstecktes Feld im Formular, das einen Token transportiert. Es gibt keine Bilderrätsel und keine Klickstrecken, an denen legitime Anfragen hängen bleiben.
Die Analogie vom Notizbuch lässt sich weiterspinnen. Das Buch bleibt draußen liegen, aber jetzt steht jemand daneben, der kurz hinsieht, wer den Stift in die Hand nimmt. Wer nur vorbeigeht, merkt nichts. Wer in Sekunden zwanzig Einträge in derselben Handschrift produziert, fällt auf. Genau diese Unterscheidung ist der Zweck: nicht Besucher ausfiltern, sondern automatisierte Massenübermittlungen.
Serverseitige Verifizierung für Formular-Übermittlungen
Der Token allein genügt nicht, und daran scheitern viele erste Umsetzungen. Ein Bot kann eine Zeichenfolge erzeugen, die wie ein gültiger Token aussieht; eine Prüfung im Browser lässt sich damit täuschen. Die Verifizierung muss dort stattfinden, wo die Daten wirklich ankommen: in der Edge Function, die die Einfügung vorbereitet, gegen den Endpunkt siteverify von Cloudflare. Erst wenn Cloudflare bestätigt, dass der Token echt und für diese Anfrage ausgestellt wurde, darf die Zeile geschrieben werden.
Die Reihenfolge zählt. Wird zuerst eingefügt und danach geprüft, steht der Spam bereits in der Warteschlange. Wird nur im Client geprüft, hängt die Sicherheit an Code, den der Angreifer kontrolliert. Die Prüfung gehört also zwischen Formularübermittlung und Datenbankzugriff, nicht daneben.
Trigger als zweite Schicht gegen Spam-Anfragen im Collab-Postfach
Selbst eine korrekt verifizierte Edge Function ist nicht die letzte Instanz. Wer den Umweg über die Funktion kennt, kann versuchen, direkt gegen die API zu schreiben. Deshalb empfiehlt die Entwicklerin eine Validierung auf Datenbankebene, umgesetzt als Trigger, der unabhängig vom Eingangsweg greift. In DraftKit prüft eine Funktion namens validate_requester_substack_url() jede Zeile und weist Einträge zurück, deren URL keinem Publikationsprofil entspricht. Das ist die letzte Barriere, bevor etwas im Postfach einer Creatorin landet.
Diese Schicht ist unspektakulär und wird deshalb gern übersehen. Sie fängt Fälle ab, in denen die Anwendungsschicht umgangen wird, und kostet nichts außer einem Stück Schema-Definition. Wer schon erlebt hat, wie ein einzelner offener Insert-Pfad die eigene Tabelle gefüllt hat, plant sie von Anfang an ein.
Fehlversuche protokollieren und öffentliche Endpunkte vor dem Launch auditieren
Wenn eine Turnstile-Verifizierung fehlschlägt, ist das eine Information, kein Rauschen. Die Empfehlung lautet, jeden Fehlversuch in eine Tabelle wie analytics_events zu schreiben, zusammen mit IP, Zeitstempel und der betroffenen Buchungsseite. Im Alltag siehst du davon nichts. Sobald aber eine Kampagne gezielt eine bestimmte Creatorin angreift, lässt sich aus diesen Zeilen ablesen, wann es begonnen hat und wie breit der Angriff läuft.
Vor jedem Release hilft außerdem ein kurzer Endpunkt-Audit. Du listest jede Route auf, die ohne Authentifizierung erreichbar ist, und stellst für jede eine Frage: Nimmt sie Nutzereingaben entgegen, die in der Datenbank landen? Wenn ja, gehört Bot-Schutz davor, bevor die Domain live geht. Die Liste ist in wenigen Minuten erstellt und beantwortet genau die Frage, die im Betrieb sonst erst ein Spam-Eintrag beantwortet.
Der Vergleich, den die Entwicklerin anstellt, ist nüchtern: Der Aufwand für den nachträglichen Einbau ist derselbe wie vor dem Launch. Was sich unterscheidet, ist der Zeitpunkt, zu dem die Lücke sichtbar wird. Vor dem Launch kostet Turnstile etwa dreißig Minuten Arbeit und bleibt für Nutzer unsichtbar. Nach dem Launch kommt die unangenehmere Aufgabe hinzu, einer Creatorin zu erklären, warum fremde Anfragen in ihrem Postfach liegen. Vertrauen lässt sich mit einem Trigger nicht nachträglich einbauen.
Für alle, die gerade mit Lovable oder einem ähnlichen Builder ein Produkt mit öffentlichem Buchungsformular ausliefern: Prüft den Weg vom Formular bis zur Zeile in der Datenbank, nicht nur das Formular. Der sichtbare Teil ist fertig, sobald er sich bedienen lässt. Der unsichtbare entscheidet, wer ihn bedienen darf. Wer seinen Bestand an öffentlichen Endpunkten vor dem nächsten Feature durchsehen lassen will, kann sich an hello@elenacalvillo.com wenden; die Entwicklerin nennt das den ersten Schritt bei einem Produktaudit.
Quelle: promptledproduct.substack.com
