WebMCP: Wie unser eigener KI-Zugang zum Einfallstor für Spam wurde

Am 17. August 2026 ging über unser Kontaktformular eine Spam-Nachricht ein. Das Formular ist durch einen Spamschutz abgesichert, der serverseitig geprüft wird. Die Nachricht war trotzdem da.

Die Ursache lag nicht im Formular. Sie lag in einer Schnittstelle, die wir selbst gebaut hatten, damit KI-Assistenten mit unserer Website arbeiten können. Dieser Beitrag beschreibt, wie das passieren konnte, warum es kein Einzelfall bleiben wird und was wir geändert haben.

Was WebMCP ist

Das Model Context Protocol für das Web, kurz WebMCP, ist ein Vorschlag, mit dem eine Website Werkzeuge anbietet, die ein KI-Assistent direkt aufrufen kann. Statt eine Seite zu lesen und Formularfelder zu erraten, ruft der Assistent eine benannte Funktion mit klar beschriebenen Parametern auf.

Der Entwurf wird in der Web Machine Learning Community Group des W3C entwickelt und liegt als Draft Community Group Report vor, also ausdrücklich noch nicht als Standard. Chrome bietet die Schnittstelle seit Version 149 in einem Origin Trial an, angemeldet werden die Werkzeuge über document.modelContext.

Für eine Agentur wie uns ist das reizvoll. Wer möchte, dass ein Assistent Leistungen korrekt wiedergibt statt sie zu erfinden, gibt ihm am besten einen sauberen Zugang zu den eigenen Daten. Genau deshalb hatten wir sieben Werkzeuge angemeldet. Sechs davon lasen nur. Eines legte eine Kontaktanfrage an.

Der Fehler steckte im siebten Werkzeug

Ein WebMCP-Werkzeug ist am Ende ein HTTP-Endpunkt. Bei uns lag er unter /api/agent/erstgespraech_anfragen und war geschützt durch drei Dinge: er verlangte POST, ein gültiges CSRF-Token und erlaubte höchstens drei Aufrufe pro Stunde und Sitzung.

Ein Captcha prüfte er nicht. Die Begründung stand sogar in unserer eigenen Dokumentation: Ein Assistent kann kein Captcha lösen, also wäre die Prüfung an dieser Stelle sinnlos. Das stimmt und ist trotzdem der Denkfehler.

Denn ein Angreifer braucht keinen Assistenten. Er braucht ein Skript. Und dieses Skript geht in zwei Schritten vor:

1. Eine beliebige Seite abrufen und das CSRF-Token aus dem HTML auslesen.
2. Mit diesem Token an den Endpunkt senden.

Wir haben das nach dem Vorfall selbst nachgestellt. Zwei Aufrufe mit einem gewöhnlichen Kommandozeilenwerkzeug, kein Browser, kein Assistent, keine Captcha-Prüfung. Der Datensatz wurde angelegt, die Benachrichtigungsmails gingen raus.

Warum das CSRF-Token hier nichts nützt

Das ist keine Schwäche der Umsetzung, sondern eine Verwechslung zweier Schutzziele. Ein CSRF-Token verhindert, dass eine fremde Website den Browser eines angemeldeten Menschen zu einer ungewollten Aktion verleitet. Es sagt nichts darüber aus, ob am anderen Ende ein Mensch sitzt.

Das CSRF Prevention Cheat Sheet der OWASP ist an dieser Stelle ungewöhnlich deutlich. Es rät ausdrücklich davon ab, ein Captcha als CSRF-Schutz einzusetzen, mit der Begründung, ein Captcha sei eigens dafür gemacht, gegen Bots zu schützen. Die Umkehrung gilt genauso: Das CSRF-Token ist eigens dafür gemacht, gegen gefälschte Anfragen zu schützen, und nicht gegen Automatisierung.

Auch die Ratenbegrenzung trug wenig bei. Sie hing an der Sitzung, und eine neue Sitzung kostet ein verworfenes Cookie.

Das Sicherheitsdenken zeigt in die andere Richtung

Man könnte annehmen, so etwas stünde in den Sicherheitshinweisen. Tut es aber kaum, und das hat einen Grund: Die gesamte Debatte um MCP dreht sich derzeit darum, den Assistenten und seinen Nutzer zu schützen, nicht die Website.

Die Sicherheitshinweise von Chrome für Agenten behandeln vor allem Prompt Injection, also bösartige Anweisungen, die eine Website in ihren Werkzeugbeschreibungen versteckt. Die Empfehlungen für sichere Werkzeuge drehen sich um Kennzeichnungen wie untrustedContentHint, um Längenbegrenzungen und darum, Werkzeuge nur vertrauenswürdigen Ursprüngen zugänglich zu machen. Eingabeprüfung, Zugriffsschutz oder Missbrauchsabwehr auf Seiten des Betreibers kommen dort nicht vor.

Ähnlich das Kapitel zu Sicherheitspraktiken der MCP-Spezifikation: Es ist ausführlich und gut, behandelt aber Confused-Deputy-Angriffe, Token-Durchreichung, Session Hijacking und SSRF. Alles Themen der Zugriffsverwaltung nach OAuth 2.1. Der Fall „öffentlich erreichbares Werkzeug, das etwas anlegt" kommt schlicht nicht vor.

Und der Entwurf selbst? Er verlangt keine ausdrückliche Zustimmung vor der Ausführung eines Werkzeugs, keine Nutzerinteraktion als Voraussetzung, und er sieht keinen Weg vor, mit dem eine Website einen Aufruf durch einen Assistenten von einer gewöhnlichen Interaktion unterscheiden könnte.

Das ist ein strukturelles Problem, kein Programmierfehler

Wer eine Schnittstelle maschinenlesbar macht, macht sie für alle Maschinen lesbar. Ein Werkzeug, das ein Assistent bequem aufrufen kann, ist per Konstruktion auch für ein Skript bequem aufrufbar. Beschreibung, Parameter und Endpunkt stehen im Manifest, gut dokumentiert und maschinell auswertbar. Das ist der Sinn der Sache.

Formularspam ist dabei keine exotische Bedrohung. Die OWASP führt ihn im Katalog der automatisierten Bedrohungen unter OAT-017 Spamming, gemeinsam mit Kommentarspam, Bewertungsspam und maschinell erzeugten Inhalten. Wer einen schreibenden Endpunkt ohne Botabwehr veröffentlicht, bedient genau dieses Muster.

Was wir geändert haben

Wir haben das schreibende Werkzeug entfernt. Alle WebMCP-Werkzeuge auf dieser Seite sind seitdem rein lesend. An seiner Stelle steht ein Werkzeug, das die Kontaktwege zurückgibt, also Formularadresse, Telefonnummer und E-Mail, mit der ausdrücklichen Anweisung an den Assistenten, die Person dorthin zu verweisen, statt in ihrem Namen zu senden.

Das kostet Bequemlichkeit. Ein Assistent kann jetzt nicht mehr im Gespräch eine Anfrage für jemanden absenden. Dafür gibt es keinen Weg mehr, der am Spamschutz vorbeiführt, und das war uns wichtiger.

Woran Sie Ihre eigene Anbindung prüfen können

• Gibt es einen schreibenden Endpunkt? Alles, was einen Datensatz anlegt, eine Mail auslöst oder eine Bestellung erzeugt, gehört auf den Prüfstand.
• Was schützt ihn tatsächlich? POST-Zwang, CSRF-Token und Ratenbegrenzung sind zusammen kein Botschutz. Prüfen Sie es, indem Sie den Endpunkt selbst mit zwei Aufrufen von der Kommandozeile ansprechen.
• Hängt die Ratenbegrenzung an der Sitzung? Dann ist sie wirkungslos. Sie muss an etwas hängen, das nicht mit einem Cookie zurückgesetzt wird.
• Wird jeder Aufruf serverseitig geprüft? Alles, was nur im Browser passiert, etwa eine Rückfrage vor dem Absenden, ist eine Bequemlichkeit für ehrliche Nutzer, keine Sicherheitsmaßnahme.
• Ist der Ursprung des Aufrufs im Datensatz vermerkt? Bei uns stand im Feld für die Quelle der Name des Werkzeugs. Ohne diesen Eintrag hätten wir die Ursache nicht in einer halben Stunde gefunden.

Wie sich das Grundproblem lösen lässt

Die eigentliche Frage lautet: Wie erkennt eine Website, dass am anderen Ende ein legitimer Assistent arbeitet und kein Spamskript? Ein Captcha kann das nicht leisten, es prüft ja gerade auf Menschlichkeit.

Es gibt einen Ansatz, der in die richtige Richtung zeigt. Web Bot Auth ist ein Entwurf bei der IETF, mit dem sich ein Bot kryptografisch ausweist: Der Betreiber veröffentlicht einen öffentlichen Schlüssel an einer festen Stelle, der Bot signiert seine Anfragen nach RFC 9421, HTTP Message Signatures, und die Website prüft die Signatur. Cloudflare hat das im eigenen Netz produktiv geschaltet und verifiziert darüber bereits Agenten mehrerer Anbieter.

Damit ließe sich die Frage endlich richtig stellen: nicht „ist das ein Mensch", sondern „ist das ein Assistent, dessen Betreiber ich kenne und dem ich ein Kontingent einräume". Bis dahin gilt eine unbequeme Faustregel: Was etwas anlegt, gehört nicht in ein Werkzeug ohne Botabwehr.

Quellen

Alle Aussagen oben lassen sich hier nachlesen. Abgerufen am 18. August 2026.

Spezifikationen und Herstellerdokumentation

• W3C Web Machine Learning Community Group: WebMCP, Draft Community Group Report vom 17. August 2026
• WebMCP Explainer im Repository der Community Group
• Chrome for Developers: WebMCP
• Chrome for Developers: Join the WebMCP origin trial, Chrome 149
• Chrome for Developers: WebMCP tool security
• Chrome for Developers: Agent security considerations for WebMCP
• Model Context Protocol: Security Best Practices, Fassung 2025-11-25
• Model Context Protocol: Authorization, Fassung 2025-11-25

Sicherheitsgrundlagen

• OWASP: Cross-Site Request Forgery Prevention Cheat Sheet
• OWASP: Automated Threats to Web Applications
• OWASP: OAT-017 Spamming

Ausweis von Bots und Agenten

• IETF: Web Bot Auth Architecture, Internet-Draft
• RFC 9421: HTTP Message Signatures
• Cloudflare: Forget IPs, using cryptography to verify bot and agent traffic