Store API absichern: Headless-Shops sicher betreiben

Headless klingt nach Freiheit im Frontend - und verschiebt zugleich die gesamte Geschäftslogik hinter eine öffentlich erreichbare Schnittstelle. Genau diese Schnittstelle wird in der Praxis selten so gründlich geprüft wie eine klassische Storefront. Wer die Store API absichern will, muss deshalb dort ansetzen, wo Autorisierung, Feldrechte und Rate-Limits tatsächlich entschieden werden. Der Druck ist messbar: Broken Access Control führt die OWASP Top 10 2025 an, mit einer durchschnittlichen Incidence-Rate von 3,74 % und einem Spitzenwert von 20,15 % über rund 2,8 Millionen ausgewertete Anwendungen (OWASP Top 10 2025). In der API-spezifischen Liste betreffen drei von fünf der höchstbewerteten Risiken unmittelbar die Autorisierung (OWASP API Security Top 10). Dieser Leitfaden geht die typischen Fehlerbilder durch - von fremden Bestell-IDs über schreibbare Preisfelder bis zu fehlenden Limits - und endet mit einem Prüfplan für den Go-Live. Wenn Sie die Architekturfrage noch offen haben, lesen Sie zuvor den Überblick zu Headless Commerce mit Shopware.

Der blinde Fleck der Headless-Architektur

In einem klassischen Shop übernimmt die Storefront einen Teil der Schutzarbeit fast nebenbei: Serverseitig gerenderte Templates zeigen nur, was der Controller vorher freigegeben hat, Formulare tragen CSRF-Token, Sessions hängen am selben Origin. Entkoppeln Sie das Frontend, fällt diese stille Absicherung weg. Übrig bleibt eine HTTP-Schnittstelle, die jeder mit einem Terminal aufrufen kann - und die alle Entscheidungen darüber, wer was sehen und ändern darf, selbst treffen muss.

Die Datenlage der OWASP Foundation zeigt, wie weit verbreitet Lücken in genau dieser Entscheidungsschicht sind. Für die Top 10 2025 wurden Daten von 13 beitragenden Organisationen sowie rund 220.000 CVEs ausgewertet, aus denen 248 CWEs in zehn Kategorien einsortiert wurden (OWASP Top 10 2025). Allein auf A01 Broken Access Control entfallen 40 CWEs, 1.839.701 dokumentierte Vorkommen und 32.654 CVEs, bei einem durchschnittlich gewichteten Exploit-Wert von 7,04 (OWASP Top 10 2025). Die Kategorie ist damit nicht nur häufig, sondern auch vergleichsweise leicht ausnutzbar.

Parallel steigt die allgemeine Angriffsfläche. Das Bundesamt für Sicherheit in der Informationstechnik zählte im aktuellen Berichtszeitraum durchschnittlich 119 neue Schwachstellen pro Tag - ein Zuwachs von rund 24 % gegenüber dem Vorjahreszeitraum - sowie täglich rund 280.000 neue Schadprogramm-Varianten (BSI, Die Lage der IT-Sicherheit in Deutschland 2025). Eine öffentlich erreichbare Shop-API ist in diesem Umfeld kein Randthema, sondern ein dauerhaft beobachtetes Ziel.

Wichtig ist die Reihenfolge: Erst steht die Frage, welche Route überhaupt welche Daten herausgeben darf, danach die Frage, wie schnell sie das tut. Wer die modulare Shop-Architektur plant, sollte die Berechtigungslogik deshalb als eigenes Architekturthema behandeln - nicht als Detail einzelner Controller.

Object Level Authorization: fremde IDs, offene Daten

Das häufigste Fehlerbild trägt bei der OWASP Foundation die Nummer eins der API-Liste: API1:2023 Broken Object Level Authorization. Die Kurzfassung: APIs geben Endpunkte heraus, die Objekt-Identifier entgegennehmen, und prüfen anschließend zwar, ob jemand angemeldet ist - aber nicht, ob dieser Jemand zu genau diesem Objekt gehört (OWASP API Security Top 10). Authentifizierung beantwortet die Frage nach der Identität. Autorisierung beantwortet die Frage nach der Zugehörigkeit. Beide werden in Headless-Projekten regelmäßig verwechselt.

Konkret sieht das so aus: Ein Kundenkonto ruft seine Bestellhistorie ab. Der Endpunkt akzeptiert eine Bestell-ID, liest den Datensatz und liefert ihn aus. Solange die ID aus der eigenen Liste stammt, fällt nichts auf. Wird sie manuell ersetzt, entscheidet allein die serverseitige Prüfung darüber, ob fremde Rechnungsadressen, Positionen und Preise sichtbar werden.

# Der angemeldete Kunde ruft seine eigene Bestellung ab
GET /store-api/order?filter[id]=0f3a...eigene-id
sw-access-key: SWSCXXXXXXXXXXXX
sw-context-token: 9c2b...

# Dieselbe Route, fremde ID - die Antwort darf hier nicht 200 sein
GET /store-api/order?filter[id]=71bd...fremde-id
sw-access-key: SWSCXXXXXXXXXXXX
sw-context-token: 9c2b...

# Erwartetes Verhalten: 403 oder eine leere Ergebnismenge,
# entschieden anhand des Kontexts - nicht anhand der übergebenen ID

Drei Annahmen führen erfahrungsgemäß in dieses Muster. Erstens: Die ID ist eine UUID, die rät niemand. Unvorhersehbarkeit ist kein Zugriffsschutz, denn IDs tauchen in Weiterleitungen, Exporten, Logs, Support-Tickets und Browser-Historien auf. Zweitens: Das Frontend zeigt nur eigene Bestellungen an. Das Frontend ist Anzeigeschicht, keine Kontrollinstanz. Drittens: Der Endpunkt ist doch nur intern. Alles, was ein Browser aufrufen kann, ist öffentlich.

• Kontext statt Parameter: Die Zugehörigkeit wird aus dem authentifizierten Kontext abgeleitet, nicht aus einem Wert im Request. Die übergebene ID darf die Ergebnismenge nur einschränken, nicht erweitern.
• Zentrale Durchsetzung: Eine gemeinsame Prüfschicht statt Einzelprüfungen je Controller. Was an einer Stelle vergessen wird, fällt sonst erst im Vorfall auf.
• Objektarten einzeln betrachten: Bestellungen, Adressen, Wunschlisten, Dokumente, Retouren und Angebote haben jeweils eigene Zugehörigkeitsregeln - besonders in B2B-Szenarien mit mehreren Nutzern pro Firmenkonto.
• Negativtests automatisieren: Für jede lesende Route mindestens ein Test, der mit fremder ID einen Fehlerstatus erwartet. Diese Tests gehören in die Pipeline, nicht in ein einmaliges Audit.
• Least Privilege konsequent: Das Prinzip der minimalen Rechte lässt sich aus einem Zero-Trust-Ansatz für Online-Shops direkt auf Routenebene übertragen.

Property Level Authorization: Felder, die keine Route entgegennehmen darf

Die zweite Kategorie sitzt eine Ebene tiefer. API3:2023 Broken Object Property Level Authorization fasst zwei ältere Risiken zusammen - übermäßige Datenpreisgabe und Mass Assignment - und benennt die gemeinsame Ursache: fehlende oder unzureichende Autorisierungsprüfung auf Feldebene (OWASP API Security Top 10). Es geht also nicht mehr darum, welches Objekt jemand anfassen darf, sondern welche Eigenschaften davon.

Beim Lesen äußert sich das als Überlieferung: Die Route serialisiert die komplette Entität und überlässt dem Frontend die Auswahl. Interne Kalkulationsfelder, Lieferantenhinweise, Rohmargen oder Kundengruppen-Zuordnungen wandern so in eine Antwort, die jeder im Netzwerk-Tab mitliest. Beim Schreiben äußert es sich als Mass Assignment: Der Request-Body wird auf die Entität gemappt, und Felder, an die niemand gedacht hat, werden mitgeschrieben.

{
  "quantity": 2,
  "productId": "a17c...",

  "price": 0.01,
  "discountPercentage": 90,
  "customerGroupId": "b2b-sonderkonditionen",
  "taxFree": true,
  "orderState": "paid"
}

// Erlaubt sind hier ausschließlich quantity und productId.
// Alle weiteren Felder müssen serverseitig verworfen werden -
// über eine Positivliste, nicht über eine Sperrliste.

Der belastbare Ansatz ist in beide Richtungen derselbe: Positivlisten. Beim Lesen definiert ein explizites Ausgabeobjekt, welche Felder die Route verlässt - unabhängig davon, was das Datenmodell sonst noch enthält. Beim Schreiben definiert eine Zuweisungsliste, welche Felder überhaupt aus dem Request übernommen werden; alles andere wird verworfen, statt stillschweigend gespeichert. Sperrlisten scheitern regelmäßig daran, dass ein neues Feld im Datenmodell niemanden dazu zwingt, die Liste zu pflegen.

Unbegrenzter Ressourcenverbrauch: Rate-Limits gehören zur Fachlogik

API4:2023 Unrestricted Resource Consumption beschreibt Endpunkte, die ohne mengenmäßige Begrenzung arbeiten. Betroffen sind nicht nur Rechenzeit und Speicher, sondern auch alles, was pro Aufruf Geld kostet - E-Mails, SMS, externe Abfragen (OWASP API Security Top 10). Die Beispielszenarien der OWASP Foundation sind unangenehm konkret: ein Angreifer, der über ein ungeschütztes Passwort-Reset tausende kostenpflichtige SMS auslöst; 999 in einem einzigen Request gebündelte Upload-Mutationen, die eine Rate-Begrenzung pro Request wirkungslos machen; und eine Datei, die von 13 GB auf 18 GB wuchs und die monatliche Rechnung von 13 auf 8.000 US-Dollar trieb (OWASP API Security Top 10).

Im Shop-Kontext sind drei Endpunktgruppen besonders exponiert - und alle drei sind in einem Headless-Setup direkt aufrufbar, ohne den Umweg über eine gerenderte Seite.

Shopware bringt für diese Fälle einen konfigurierbaren Rate-Limiter mit. Ab Werk arbeiten login, guest_login und oauth mit einer gestaffelten Backoff-Strategie: 10 Versuche in 10 Sekunden, danach 15 in 30 Sekunden, danach 20 in 60 Sekunden, mit Rücksetzung nach 24 Stunden. Für reset_password, user_recovery, contact_form und newsletter_form gelten strengere Werte von 3 Versuchen in 30 Sekunden, 5 in 60 Sekunden und 10 in 90 Sekunden; app_shop_verify nutzt ein gleitendes Fenster von 60 Aufrufen pro 60 Minuten (Shopware Developer Documentation). Das Hinzufügen von Warenkorbpositionen läuft über cart_add_line_item und lässt sich in der Systemkonfiguration begrenzen.

Seit Shopware 6.7.10.0 kommen zwei zusätzliche Limiter hinzu, die den blinden Fleck klassischer IP-Limits schließen: login_user begrenzt pro E-Mail-Adresse unabhängig von der IP, login_client begrenzt pro IP unabhängig von der E-Mail-Adresse (Shopware Developer Documentation). Genau diese Kombination ist gegen verteilte Anmeldeversuche wirksam, bei denen jede einzelne IP unauffällig bleibt.

• Grenzen fachlich herleiten: Wie viele Anmeldeversuche, Suchanfragen oder Warenkorb-Änderungen sind für echte Kundschaft in einer Minute plausibel? Der Wert ergibt sich aus dem Geschäft, nicht aus einem Standardwert.
• Antwortgröße begrenzen: Maximale limit-Werte und eine Obergrenze für verschachtelte Associations verhindern, dass ein einzelner Aufruf den halben Katalog erzeugt.
• Batch-Aufrufe mitzählen: Wer nur Requests zählt, übersieht gebündelte Operationen. Gezählt werden sollte die Zahl der Operationen, nicht die Zahl der HTTP-Anfragen.
• Sauber antworten: Ein 429 Too Many Requests mit Retry-After ist für legitime Clients verwertbar - ein Timeout ist es nicht.
• Hintergrundlast begrenzen: Endpunkte, die Nachrichten in die Queue schreiben, brauchen eigene Limits. Wie sich Worker unter Last verhalten, beschreibt der Beitrag zu Message Queue und Worker im Produktivbetrieb.

Access-Key-Hygiene: was im Client stehen darf und was nicht

Der Store-Access-Key, der bei Shopware als Header sw-access-key mitgeschickt wird, steht im Frontend-Code oder im Build-Artefakt - und ist damit per Definition öffentlich. Er identifiziert den Verkaufskanal, gegen den ein Aufruf läuft. Er belegt nicht, wer aufruft, und er räumt keine Rechte ein. Wer ihn wie ein Geheimnis behandelt, baut Schutz auf einem Wert auf, den jeder Besucher mit geöffneter Entwicklerkonsole abliest.

Die eigentliche Nutzeridentität hängt am Kontext-Token, das über Anmeldung entsteht und pro Anfrage mitgeführt wird. Alle Zugehörigkeitsprüfungen aus den vorangegangenen Abschnitten müssen an diesem Kontext hängen - nicht am Access-Key. Und was für den Store-Access-Key gilt, gilt in verschärfter Form für Zugangsdaten der Admin-API: Client-ID und Secret gehören ausschließlich in serverseitige Umgebungen. Ein Frontend, das Admin-Endpunkte direkt aufruft, verlagert Administrationsrechte in den Browser.

Ein Schlüssel im Browser ist ein Name, kein Schloss. Alles, was er öffnen kann, muss auch ohne ihn sicher sein.

XICTRON Entwicklungsteam

CORS, Origin-Prüfung und WAF-Regeln statt Wildcard

A02:2025 Security Misconfiguration steht in der aktuellen OWASP-Liste auf Platz zwei: 16 zugeordnete CWEs, eine durchschnittliche Incidence-Rate von 3,00 % bei einem Spitzenwert von 27,70 %, 719.084 Vorkommen und ein durchschnittlich gewichteter Exploit-Wert von 7,96 (OWASP Top 10 2025). Zur Kategorie gehört unter anderem CWE-942, eine zu freizügige Cross-Domain-Richtlinie gegenüber nicht vertrauenswürdigen Domains (OWASP Top 10 2025) - im Alltag also die Wildcard-Freigabe, die einmal für einen Test gesetzt und danach vergessen wurde.

Dabei lohnt eine Klarstellung: CORS ist eine Browser-Regel, kein Zugriffsschutz. Ein Skript außerhalb des Browsers ignoriert sie vollständig. Eine großzügige CORS-Konfiguration macht eine ohnehin unsichere Route also nicht unsicherer - sie macht sie nur bequemer angreifbar aus fremden Webseiten heraus. Umgekehrt ersetzt eine strenge CORS-Konfiguration keine einzige der Autorisierungsprüfungen aus den vorherigen Abschnitten.

Vor der Anwendung gehört eine Filterebene, die Muster erkennt, bevor sie PHP erreichen. Eine Web Application Firewall ist dabei kein Ersatz für korrekte Autorisierung, sondern eine zusätzliche Schicht: Sie blockt bekannte Angriffssignaturen, begrenzt Anfragegrößen und fängt einen Teil des automatisierten Verkehrs ab. Wo diese Ebene sitzt - im Reverse Proxy, an der Edge oder in beiden - hängt vom Betriebskonzept ab und gehört in die Planung von Hosting und Wartung.

• Erlaubte Herkünfte explizit gepflegt, keine Wildcard in der Produktion
• Debug-, Profiler- und Entwicklungsrouten in der Produktion deaktiviert
• Fehlerausgaben ohne interne Pfade, Versionsnummern oder Stacktraces
• Sicherheits-Header gesetzt und regelmäßig gegen den Ist-Zustand geprüft
• API-Versionen und veröffentlichte Endpunkte inventarisiert - laut OWASP ein eigenes Risiko (API9:2023 Improper Inventory Management)
• Abgekündigte Endpunkte tatsächlich abgeschaltet, nicht nur aus der Dokumentation entfernt

Erkennen statt hoffen: Logging, Alarmierung und Incident-Ablauf

Die OWASP Foundation hat ihre Logging-Kategorie für 2025 umbenannt und geschärft: A09:2025 Security Logging and Alerting Failures betont, dass Aufzeichnung ohne Alarmierung wertlos bleibt. Ohne Protokollierung und Überwachung lassen sich Angriffe nicht erkennen, und ohne Alarmierung ist eine schnelle Reaktion kaum möglich (OWASP Top 10 2025). Die Kennzahlen der Kategorie: 5 zugeordnete CWEs, durchschnittliche Incidence-Rate 3,91 %, Spitzenwert 11,33 %, 260.288 Vorkommen und ein durchschnittlich gewichteter Exploit-Wert von 7,19 (OWASP Top 10 2025).

In der Praxis scheitert Erkennung selten am fehlenden Log, sondern an fehlender Auswertung. Ein Headless-Setup erzeugt Zugriffsdaten an mehreren Stellen - Reverse Proxy, Frontend-Server, Anwendung, Datenbank. Wer diese Spuren nicht zusammenführt, sieht ein verteiltes Angriffsmuster nur als drei unauffällige Einzelbilder.

• Fehlgeschlagene Autorisierung: Jede 403-Antwort mit Route, Objektart und Kontext-Kennung - Häufungen auf einer Route sind das deutlichste Früherkennungssignal für Object-Level-Sondierung.
• Anmeldeverhalten: Verhältnis von Erfolg zu Misserfolg je Zeitfenster, verteilt über IP-Bereiche und Nutzerkonten. Ein Einbruch dieser Quote deutet auf automatisierte Versuche hin.
• Rate-Limit-Treffer: Jede 429-Antwort mit Endpunkt und Auslöser. Ein sprunghafter Anstieg zeigt Scraping oder Bot-Last, bevor die Antwortzeiten steigen.
• Verworfene Felder: Wenn eine Positivliste ein Feld verwirft, ist das ein Ereignis - meist ein Integrationsfehler, gelegentlich ein Versuch.
• Antwortvolumen je Konto: Ungewöhnlich große oder ungewöhnlich viele Antworten pro Kontext deuten auf systematischen Abzug hin.
• Ohne personenbezogene Inhalte: Protokolliert werden Metadaten und Kennungen, keine Klartextdaten. Aufbewahrungsfristen und Löschkonzept gehören zur Logging-Konfiguration dazu.

Zur Alarmierung gehören Schwellen, die jemand tatsächlich beantwortet. Ein Alarm, der täglich ohne Folge auslöst, wird binnen weniger Wochen ignoriert. Sinnvoll sind wenige, klar zugeordnete Signale mit definierter Reaktionszeit - und ein dokumentierter Ablauf für den Fall, dass eines davon zutrifft.

1. Eingrenzen: Betroffene Route, Zeitraum und Kontexte bestimmen, Rohdaten sichern, bevor Rotationen sie überschreiben.
2. Begrenzen: Betroffenen Endpunkt drosseln oder vorübergehend abschalten, Schlüssel und Tokens der betroffenen Kanäle wechseln.
3. Bewerten: Prüfen, welche Datensätze tatsächlich ausgeliefert wurden - die Antwortgrößen im Log sind hier oft aussagekräftiger als die Anfragezahl.
4. Melden: Meldepflichten nach Datenschutz-Grundverordnung und - je nach Betroffenheit - weiteren Regelwerken innerhalb der jeweiligen Fristen prüfen und dokumentieren.
5. Schließen: Ursächliche Prüfung ergänzen, Regressionstest schreiben, Fix ausrollen.
6. Nacharbeiten: Erkennungslücke beheben - wenn der Vorfall nicht durch eigene Alarmierung auffiel, ist das ein eigener Befund.

Der Prüfplan vor dem Go-Live

Die einzelnen Maßnahmen wirken nur, wenn sie vor der Freigabe systematisch abgehakt werden - und nach jedem größeren Release erneut. Die folgende Liste lässt sich als Abnahmekriterium in ein Projekt übernehmen und deckt die in diesem Artikel benannten OWASP-Kategorien ab.

• Vollständiges Inventar aller erreichbaren Endpunkte, inklusive eigener Routen aus Erweiterungen
• Je lesender Route ein Negativtest mit fremder Objekt-ID, der einen Fehlerstatus erwartet
• Je schreibender Route eine Positivliste erlaubter Felder, dokumentiert und getestet
• Antwortobjekte explizit definiert - keine automatische Serialisierung ganzer Entitäten
• Rate-Limits für Anmeldung, Passwort-Reset, Kontaktformular, Suche und Warenkorb gesetzt und gemessen
• Getrennte Limits pro Konto und pro Herkunft, damit verteilte Versuche auffallen
• Store-Access-Keys je Umgebung getrennt, Admin-Zugangsdaten ausschließlich serverseitig
• Rotationsablauf für Schlüssel dokumentiert und einmal geprobt
• CORS ohne Wildcard, Sicherheits-Header gesetzt, Debug-Routen deaktiviert
• Protokollierung von 403-, 429- und Feldverwurf-Ereignissen aktiv, mit definierten Alarmschwellen
• Cache-Regeln geprüft: keine personalisierte Antwort in einem geteilten Cache
• Incident-Ablauf schriftlich hinterlegt, Verantwortlichkeiten und Reaktionszeiten benannt

Für viele Betreiber ist dieser Prüfplan zugleich Vorarbeit für regulatorische Anforderungen. Der Cyber Resilience Act und seine Pflichten für Online-Shops verlangt unter anderem nachvollziehbare Schwachstellenbehandlung - eine dokumentierte Prüfkette und ein gelebter Meldeweg zahlen direkt darauf ein. Wo mehrere Systeme über Schnittstellen angebunden sind, gilt die gleiche Sorgfalt für jede weitere Verbindung: Jede zusätzliche Integration ist ein zusätzlicher Pfad in die Geschäftslogik.

Sicherheit als Teil der Headless-Architektur

Headless verlagert Verantwortung. Was die Storefront früher implizit erledigt hat, muss in einem entkoppelten Setup explizit entschieden und geprüft werden - Route für Route, Feld für Feld. Das ist kein Argument gegen die Architektur, sondern eine Konsequenz aus ihr: Dieselbe Entkopplung, die schnelle Frontends und flexible Kanäle ermöglicht, macht die Berechtigungslogik zum tragenden Bauteil.

Der wirtschaftliche Hebel ist dabei greifbar. Ein einzelner Object-Level-Fehler kann eine Datenschutzmeldung, Vertrauensverlust und operative Ausnahmezustände auslösen; ein fehlendes Rate-Limit kostet Rechenzeit, verzerrt Kennzahlen und liefert das eigene Sortiment an den Wettbewerb. Beides lässt sich mit vergleichsweise kurzen Maßnahmen deutlich verringern - vorausgesetzt, jemand sieht sich die Endpunkte tatsächlich an.

Genau das übernehmen wir: XICTRON prüft Store-API-Endpunkte, die Berechtigungslogik hinter jeder Route und die gesetzten Rate-Limits, ordnet Befunde den OWASP-Kategorien zu und härtet bestehende Headless-Setups nach - ohne das Frontend neu zu bauen. Ob das im Rahmen laufender E-Commerce-Projekte, einer eigenständigen Beratung oder begleitend zur Shopware-Entwicklung geschieht, richtet sich nach Ihrem Setup.