Welche Endpunkte Shopware ab Werk gegen Missbrauch schützt
Fünfzehn Ratenbegrenzungsregeln in 6.7, neun in 6.6. Drei Fehlversuche beim Passwort-Zurücksetzen reichen — und zwei der neuen Regeln gelten einer Schnittstelle, die es ab Werk nicht gibt.
Ratenbegrenzung ist einer der Bereiche, in denen man erst nachsieht, wenn etwas nicht funktioniert — meistens eine Automatisierung, die sporadisch abbricht. Deshalb hier zuerst die Liste, und dann die Stelle, an der es in Projekten klemmt.
Was der Kern schützt
| 6.6.10.6 | 6.7.13.1 | |
|---|---|---|
| Regeln im Kern | 9 | 15 |
| davon ab Werk aktiv | 9 | 15 |
Die neun aus 6.6 gibt es in 6.7 unverändert. Dazu kommen sechs neue.
Die Stufen
Zwei Muster, und der Unterschied zwischen ihnen ist die eigentliche Aussage.
Anmeldung, Gastanmeldung, OAuth, Benachrichtigungen — time_backoff, drei
Stufen:
| Stufe | Versuche | Zeitfenster |
|---|---|---|
| 1 | 10 | 10 Sekunden |
| 2 | 15 | 30 Sekunden |
| 3 | 20 | 60 Sekunden |
Rücksetzfrist: 24 Stunden.
Passwort zurücksetzen, Benutzerwiederherstellung, Kontaktformular, Newsletterformular — dieselbe Mechanik, deutlich strenger:
| Stufe | Versuche | Zeitfenster |
|---|---|---|
| 1 | 3 | 30 Sekunden |
| 2 | 5 | 60 Sekunden |
| 3 | 10 | 90 Sekunden |
Drei Versuche in dreißig Sekunden. Das ist der Wert, der in Projekten am häufigsten für Verwirrung sorgt — ein Kunde, der es zweimal falsch eintippt und dann noch einmal, sitzt fest.
Neu in 6.7
| Regel | was sie schützt |
|---|---|
import_export_file_download | Download erzeugter Import-/Exportdateien |
revocation_request_form | das Widerrufsformular |
newsletter_unsubscribe_form | die Newsletter-Abmeldung |
app_shop_verify | Shop-Verifizierung für Apps, sliding_window, 60 |
mcp_admin_api | 300 je Minute, 1.000 je zehn Minuten |
mcp_store_api | 120 je Minute, 600 je zehn Minuten |
Die letzten beiden verdienen einen zweiten Blick. Sie schützen den
MCP-Server — die Schnittstelle für KI-Agenten, die 6.7 im Kern mitbringt und
die ab Werk mit 404 antwortet. Der Kern begrenzt also eine Schnittstelle, die
erst eingeschaltet werden muss.
Die Kommentare im Quelltext sagen, warum die Werte auseinanderliegen: Die Admin-Variante gilt als vertrauenswürdige Automatisierung und wird je OAuth-Token gezählt. Die Store-Variante ist kundenseitig, und ihr Zählschlüssel — der Kontext-Token — lässt sich billig erneuern. Deshalb die schärfere Grenze.
Die Stelle, an der es in Projekten klemmt
Der häufigste Fall ist kein Angriff, sondern eine eigene Integration.
Ein Dienst, der sich alle paar Minuten über die Storefront-Anmeldung einloggt, statt einen OAuth-Token zu verwenden, läuft in eine Regel, die für Menschen gedacht ist. Bei zehn Versuchen in zehn Sekunden fällt das nicht auf. Bei einem Neustart, der mehrere Prozesse gleichzeitig hochfährt, sehr wohl — und die Rücksetzfrist von vierundzwanzig Stunden macht daraus kein kurzes Problem.
Das Symptom ist charakteristisch: Die Integration läuft wochenlang, bricht dann ohne erkennbaren Anlass ab und funktioniert am nächsten Tag wieder.
Die Lösung ist nicht, das Limit hochzusetzen. Sie ist, den richtigen Weg zu nehmen: ein Integrationsbenutzer mit OAuth-Token, der Token wiederverwendet statt bei jedem Aufruf neu geholt. Ein Token gilt lange genug, dass die Anmeldung selten stattfindet.
Der eine Wert, der anders funktioniert
cart_add_line_item nutzt nicht time_backoff, sondern system_config:
policy: 'system_config'
reset: '1 hours'
limits:
- domain: 'core.cart.lineItemAddLimit'
interval: '60 seconds'
Die Zahl steht also nicht im Kern, sondern in der Systemkonfiguration des Shops und ist über die Administration einstellbar. Wer einen Shop mit Schnellbestellung oder Bestellvorlagen betreibt — Kunden, die legitim zwanzig Positionen in einer Minute hinzufügen —, sollte diesen Wert kennen, bevor ein Kunde ihn findet.
Grenzen dieser Messung
Gelesen wurde die Konfiguration des Kerns, nicht das Verhalten unter Last. Dass eine Regel mit drei Stufen konfiguriert ist, sagt nichts darüber, wie sie sich hinter einem Reverse Proxy verhält, der alle Anfragen unter einer IP bündelt.
Nicht betrachtet wurden Begrenzungen außerhalb von Shopware — Webserver, WAF, CDN. In der Praxis greift oft zuerst eine davon, und dann sieht man von den hier beschriebenen Regeln gar nichts.
Die Zahlen gelten für 6.6.10.6 und 6.7.13.1. Eine Erweiterung kann eigene Regeln mitbringen; die hier genannten sind ausschließlich die des Kerns.
Häufige Fragen
- Sind die Rate Limits ab Werk aktiv?
- Ja, alle. In 6.6 sind es neun Regeln, in 6.7 fünfzehn, und jede trägt enabled: true. Es ist keine Einstellung, die man erst einschaltet.
- Was bedeutet time_backoff?
- Gestaffelte Sperren: Nach der ersten Schwelle wird kurz gesperrt, nach der zweiten länger, nach der dritten noch länger. Ein Angreifer wird ausgebremst, ein Mensch mit Tippfehler kaum.
- Betrifft das auch die Admin-API?
- Den OAuth-Endpunkt ja — mit denselben drei Stufen wie die Anmeldung. Die eigentlichen Datenendpunkte der Admin-API haben ab Werk keine eigene Ratenbegrenzung.
- Kann ich die Werte ändern?
- Ja, über die Konfiguration. Sinnvoll ist das vor allem beim Warenkorb-Limit, das an einer Systemkonfiguration hängt statt an festen Zahlen.