Shopware-Apps prüfen: Rechte, Webhooks und Integrationen

Am 25. August 2026 hat Shopware die Version 6.7.13.1 veröffentlicht. Sie schließt neun Sicherheitslücken (Shopware-Release-Notes). Drei davon setzen nach den Beschreibungen der Advisories eine bösartige oder kompromittierte App im Shop voraus: den Ausbruch aus der Sandbox für App-Scripts, eine SQL-Einschleusung über eigene Entitäten und Anfragen ins interne Netz über Adressen, die eine App vorgibt (GitHub-Advisories, eigene Zählung). Das Update schließt diese Lücken. Welche Apps, Integrationen und Webhooks in einem Shop überhaupt Zugriff haben und wozu, beantwortet es nicht. Dieser Leitfaden zeigt, wie Sie das Inventar Ihres Shopware-Shops aufnehmen und auf das Nötige zurückschneiden: App-Rechte, Webhooks, App-Scripts, Integrationen ohne Besitzer und Erweiterungen, die nur deaktiviert statt entfernt wurden. Es geht dabei allein um Sicherheit; die Kompatibilität mit dem nächsten Upgrade behandelt der Beitrag zur Vorbereitung auf Shopware 6.8.

Was die Sicherheitsreleases 2026 über Apps zeigen

Die Release Notes zu 6.7.13.1 fassen die Runde knapp zusammen: elf behobene Fehler, davon neun Sicherheitslücken und zwei allgemeine Korrekturen (Shopware-Release-Notes). Liest man die Advisories, auf die die Liste der behobenen Fehler verweist, fällt ein Muster auf: Drei Beschreibungen nennen dieselbe Voraussetzung, eine bösartige oder kompromittierte App (GitHub-Advisories, eigene Zählung). Am 16. September 2026 folgte 6.7.14.1 als Sicherheitsrelease (Shopware-Release-Notes 6.7.14.1). Darin geschlossen wurde unter anderem eine Lücke, über die Webhooks Ereignisdaten jenseits der Rechte ihres Erstellers ausliefern konnten (GitHub-Advisory GHSA-r432-q883-wgvf).

Alle Lücken der Tabelle setzen einen Zugang voraus, den jemand im Shop vergeben hat: eine installierte App, ein Recht in einer Rolle oder eine Integration (GitHub-Advisories). Das Update schließt die konkrete Lücke; wie viele Zugänge es für die nächste gibt, bestimmt das eigene Inventar. Wie sich die Sicherheitsfixes des Jahres auf die Versionsreihen verteilten, beschreibt der Beitrag zu den Sicherheitsupdates für Shopware 6.5.

Wer im Shop mitarbeitet, ohne ein Benutzerkonto zu haben

Im Backend sehen Shopbetreiber vor allem Benutzerkonten. Daneben arbeiten Bestandteile, die kein Gesicht haben, aber Daten lesen, schreiben oder versenden. Wie Rollen für Personen geschnitten werden, beschreibt der Beitrag zu Rollen und Rechten im Shop-Backend. Hier geht es um die Erweiterungen selbst und ihre technischen Zugänge.

Für die Sicherheitsprüfung zählt der Unterschied zwischen App und Plugin mehr als für die Architektur: Eine App bekommt einen Zugang mit festgelegten Rechten, ein Plugin läuft als Code im Shop ohne eine solche Grenze. Wann welches Modell passt, beschreibt der Beitrag Shopware Apps oder Plugins. Bei Apps prüft man also Rechte, bei Plugins Herkunft, Pflege und Code; wie sich die Herkunft von Paketen absichern lässt, zeigt der Beitrag zu Supply-Chain-Angriffen auf den Shop-Stack.

Schritt 1: das Inventar an einer Stelle

Die Übersicht unter Erweiterungen > Meine Erweiterungen zeigt die installierten Erweiterungen und lässt sich auf aktive Einträge beschränken (Shopware-Dokumentation). Integrationen stehen an anderer Stelle, unter Einstellungen > System > Integrationen. Webhooks, die über die API angelegt wurden, gehören zu keiner Erweiterung und tauchen in der Erweiterungsliste nicht auf. Ein vollständiges Inventar entsteht deshalb am zuverlässigsten aus der Datenbank, gelesen auf einer aktuellen Kopie oder mit einem Konto, das nur lesen darf. Die Tabellen und Spalten der folgenden Abfragen entsprechen den Entitäten in Shopware 6.7.15.1 (Shopware-Quellcode).

-- Apps mit Status, Version, Integration und Zahl der Webhooks und Scripts
SELECT a.name, a.active, a.version, a.author,
       i.admin AS integration_admin, i.last_usage_at,
       (SELECT COUNT(*) FROM webhook w WHERE w.app_id = a.id) AS webhooks,
       (SELECT COUNT(*) FROM script s WHERE s.app_id = a.id) AS scripts
FROM app a
JOIN integration i ON i.id = a.integration_id
ORDER BY a.active, a.name;

-- Plugins mit Status, Version und verfügbarer Aktualisierung
SELECT name, active, version, upgrade_version, installed_at
FROM plugin
ORDER BY active, name;

Das Ergebnis ist eine Liste mit einer Zeile je Bestandteil. Drei Angaben stehen in keiner Tabelle und müssen im Gespräch ergänzt werden: wofür der Bestandteil da ist, wer im Unternehmen oder bei einem Dienstleister für ihn zuständig ist und wann er zuletzt gebraucht wurde. Zeilen, für die niemand einen Zweck nennen kann, sind die eigentlichen Befunde der Prüfung.

• Bestandteil und Typ: App, Plugin, Integration oder Webhook ohne App
• Status: aktiv, deaktiviert oder deinstalliert, aber noch vorhanden
• Rechte: angeforderte Rechte der App, Rolle oder Administratorrecht der Integration
• Datenziel: Adressen, an die Webhooks und App-Aufrufe gehen
• Zuständigkeit: Person oder Dienstleister, möglichst mit Vertrag
• Letzte Nutzung: letzter Zugriff laut Datenbank oder Protokoll

Schritt 2: App-Rechte gegen den Zweck halten

Jede App, die über die API Daten lesen oder schreiben oder Webhooks empfangen will, muss die nötigen Rechte im Manifest anfordern. Ein Recht kombiniert eine Berechtigung, also Lesen, Anlegen, Ändern oder Löschen, mit einer Entität; seit 6.4.12.0 kann eine App zusätzlich Rechte außerhalb dieser vier anfordern (Shopware Developer Documentation). Bestätigt wird die Liste einmal, bei der Installation.

Die angeforderten Rechte muss der Benutzer bei der Installation der App akzeptieren. Danach sind die der App gewährten Rechte und ihr API-Zugang über die Zugangsdaten aus der Bestätigungsanfrage des Setups auf diese Rechte begrenzt.

Shopware Developer Documentation, App Registration & Backend Setup (eigene Übersetzung)

Der Haken liegt im Wort einmal: Wer eine App vor längerer Zeit installiert hat, hat einer Liste zugestimmt, die heute niemand mehr im Kopf hat. Zudem gelten Leserechte auch für die Daten in Webhooks; eine App braucht Leserechte für die Entitäten der abonnierten Ereignisse (Shopware Developer Documentation). Gemessen wird gegen den Zweck. Die DSGVO verlangt, dass personenbezogene Daten auf das für die Zwecke der Verarbeitung notwendige Maß beschränkt sind (DSGVO, Art. 5 Abs. 1 lit. c). Eine App für Produktbewertungen braucht Produktdaten, in der Regel aber keinen Schreibzugriff auf Kundenkonten. Eine Newsletter-Anbindung braucht Adressen und Einwilligungen, nicht zwingend Bestellungen.

-- Rechte je App aus der Rolle, die Shopware für die App angelegt hat
SELECT a.name, a.active, r.privileges
FROM app a
JOIN acl_role r ON r.id = a.acl_role_id
ORDER BY a.name;

• Schreiben und Löschen auf Kunden und Bestellungen, wo die App laut Zweck nur lesen müsste.
• Rechte auf Benutzer, Rollen, Integrationen oder Webhooks. Sie erlauben, weitere Zugänge anzulegen oder umzubauen. Die Lücken GHSA-r432-q883-wgvf und GHSA-4wpv-5fvv-c3xp setzten genau an solchen Rechten an (GitHub-Advisories).
• Rechte außerhalb von Lesen, Anlegen, Ändern und Löschen, etwa auf Systemfunktionen. Das Beispiel der Dokumentation ist system:cache:info (Shopware Developer Documentation).
• Rechte für Funktionen, die im Shop nicht genutzt werden. Bringt eine App mehrere Module mit und ist eines davon nicht im Einsatz, brauchen dessen Rechte eine Rückfrage beim Hersteller.

Die Rechte einer App legt ihr Manifest fest. Die Prüfung endet deshalb mit einer von drei Entscheidungen: Die App behält ihre Rechte, weil der Zweck sie trägt. Der Hersteller wird um eine Fassung mit engeren Rechten gebeten. Oder die App wird durch eine Lösung mit engerem Zugriff ersetzt, zum Beispiel durch eine eigene Anbindung über die Schnittstellen des Shops.

Schritt 3: Webhooks und wohin die Daten gehen

Ein Webhook ist der Teil einer Erweiterung, der Daten aus dem Shop hinausträgt. Bei jedem abonnierten Ereignis sendet Shopware eine POST-Anfrage an die hinterlegte Adresse (Shopware Developer Documentation). Bei Schreibereignissen wie product.written enthält die Nutzlast keine vollständigen Datensätze, sondern im Kern die Kennung des geänderten Eintrags; andere Ereignisse tragen die Daten, die das Ereignis beschreiben (Shopware Developer Documentation). Welche Daten tatsächlich fließen, hängt also vom Ereignis ab.

Webhooks entstehen auf zwei Wegen. Apps deklarieren sie im Manifest. Daneben können Benutzer und Integrationen mit dem passenden Recht Webhooks über die API anlegen; genau dort setzte die Lücke GHSA-r432-q883-wgvf an (GitHub-Advisory). Für die Zeit bis zum Update empfahl Shopware im Advisory unter anderem, das Recht webhook:create auf vertrauenswürdige Administratoren und Integrationen zu beschränken, bestehende Webhook-Registrierungen zu prüfen und unerwartete Einträge zu entfernen. Diese Empfehlung taugt über das Update hinaus als Prüfschritt.

-- Alle Webhooks mit Ziel, Status, Fehlerzähler und Herkunft
SELECT w.name, w.event_name, w.url, w.active, w.error_count,
       COALESCE(a.name, '(ohne App)') AS origin
FROM webhook w
LEFT JOIN app a ON a.id = w.app_id
ORDER BY origin, w.event_name;

Drei Spalten tragen die Prüfung. Die Adresse zeigt, wer die Daten bekommt; jeder Host muss einem bekannten Dienstleister oder einem eigenen System zuzuordnen sein. Der Ereignisname zeigt, welche Daten fließen; Ereignisse zu Kunden, Bestellungen und Konten wiegen schwerer als solche zu Produkten. Und der Status zeigt, ob der Webhook überhaupt noch zustellt.

Zur Prüfung gehören auch die Zustellprotokolle. Shopware führt sie in der Tabelle webhook_event_log mit App, Ereignis, Zieladresse, Zustellstatus und Antwortcode (Shopware-Quellcode 6.7.15.1). Tauchen dort Zustellungen an eine Adresse auf, die niemand zuordnen kann, geht es um die Zugangsdaten: Das Advisory zur Webhook-Lücke empfahl bei verdächtiger Webhook-Aktivität, Zugangsdaten und Token zur Kontowiederherstellung zu erneuern (GitHub-Advisory GHSA-r432-q883-wgvf).

Eine Besonderheit betrifft Kopien des Shops. Wird die Datenbank für ein Testsystem dupliziert, gibt es zwei Installationen mit derselben Shop-ID, und Apps erhalten unter Umständen Webhooks aus beiden (Shopware Developer Documentation). Shopware erkennt das, wenn sich die Umgebungsvariable APP_URL ändert, und stellt die Kommunikation mit den Apps ein, bis jemand über das weitere Vorgehen entscheidet. Diese Schutzfunktion hängt daran, dass APP_URL in der Kopie tatsächlich angepasst ist. Wie ein Testsystem ohne echte Kundendaten entsteht, beschreibt der Beitrag zum Shopware-Staging.

Wer eigene Empfänger betreibt, etwa für eine App, die mit der Warenwirtschaft spricht, prüft auf der Empfängerseite die Signatur: Bei App-Webhooks trägt jede Anfrage einen HMAC nach SHA256 über den Anfragetext, gebildet mit dem Geheimnis aus der Registrierung (Shopware Developer Documentation). Wie eine belastbare Empfängerseite mit Wiederholungen und Idempotenz aussieht, zeigt der Beitrag zur Webhook-Architektur.

Schritt 4: App-Scripts und eigene Entitäten

Seit Shopware 6.4.8.0 können Apps Logik mitbringen, die nicht auf ihrem eigenen Server, sondern im Shop läuft (Shopware Developer Documentation). App-Scripts sind Twig-Dateien, die in einer Sandbox ausgeführt werden und je nach Hook auf die Daten des jeweiligen Ablaufs und auf vordefinierte Dienste zugreifen. Über eigene Endpunkte können Scripts außerdem auf Anfragen an die Admin-API, die Store-API oder die Storefront reagieren und haben dabei Lese- und Schreibzugriff auf die Datenschicht des Shops (Shopware Developer Documentation).

Die Sandbox ist die Grenze, auf die sich dieses Modell verlässt. Die Lücke GHSA-6qhw-38wm-7g7h hat gezeigt, was passiert, wenn sie nicht hält: Eine bösartige oder kompromittierte App konnte beliebige PHP-Funktionen und Systembefehle mit den Rechten des Webserver-Prozesses ausführen, mit möglichem Zugriff auf Konfiguration und Zugangsdaten (GitHub-Advisory). Bei eigenen Entitäten lag die Grenze in der Prüfung der Bezeichner; eine präparierte Definition konnte beliebiges SQL mit den Rechten der Datenbankverbindung ausführen (GitHub-Advisory GHSA-xrcf-c96g-q5hr).

-- Scripts je App und Hook
SELECT a.name AS app, s.hook, s.name, s.active
FROM script s
JOIN app a ON a.id = s.app_id
ORDER BY a.name, s.hook;

-- Eigene Entitäten und die App, die sie definiert
SELECT c.name, a.name AS app
FROM custom_entity c
JOIN app a ON a.id = c.app_id
ORDER BY a.name;

Für das Inventar folgt daraus eine Unterscheidung, die in der Erweiterungsliste nicht sichtbar ist: Apps, die nur über ihren eigenen Server und die API arbeiten, und Apps, die Code oder Definitionen in den Shop bringen. Bei der zweiten Gruppe zählt die Herkunft mehr. Die Advisories sagen dasselbe: Apps nur aus vertrauenswürdigen Quellen installieren und aktualisieren und installierte Apps prüfen, insbesondere solche mit eigenen Entitäten (GitHub-Advisory GHSA-xrcf-c96g-q5hr). Scripts mit Endpunkten in der Store-API richten sich an Frontends und sind damit von außen erreichbar; wie sich diese Schnittstelle absichern lässt, beschreibt der Beitrag Store API absichern.

Schritt 5: Integrationen ohne Besitzer

Integrationen sind die API-Zugänge des Shops. Unter Einstellungen > System > Integrationen lässt sich für jede eigene Anwendung ein eigener Zugang anlegen, mit den Berechtigungen des Administrators oder mit einer Rolle; der Sicherheitsschlüssel wird nur beim Anlegen angezeigt (Shopware-Dokumentation). Auch jede App ist mit einer Integration verknüpft, Apps mit eigenem Server erhalten deren Zugangsdaten bei der Registrierung (Shopware Developer Documentation).

Verwaist sind Integrationen, deren Anlass vorbei ist: der Zugang für eine Migration, die Anbindung einer Warenwirtschaft, die inzwischen ersetzt wurde, ein Testzugang einer früheren Agentur. Sie fallen nicht auf, weil sie nichts tun, und sie bleiben ein Risiko, weil ihr Schlüssel noch gilt. Die OWASP beschreibt diese Lage als unzureichende Bestandsführung: Fehlen Inventar und Plan zum Stilllegen, laufen Systeme ungepflegt weiter, und Daten können über Dritte abfließen, mit denen es keinen Grund mehr gibt, Daten zu teilen (OWASP API Security Top 10 2023).

-- Integrationen ohne App, mit Adminrecht und letzter Nutzung
SELECT i.label, i.admin, i.last_usage_at, i.created_at
FROM integration i
LEFT JOIN app a ON a.integration_id = i.id
WHERE a.id IS NULL AND i.deleted_at IS NULL
ORDER BY i.last_usage_at;

Shopware speichert zu jeder Integration den Zeitpunkt der letzten Nutzung (Shopware-Quellcode 6.7.15.1). Eine Integration, die lange nicht genutzt wurde und für die niemand einen Zweck nennen kann, wird gelöscht. Eine Integration mit Administratorrecht, deren Anwendung nur Bestände und Bestellstatus abgleicht, bekommt stattdessen eine Rolle mit genau diesen Rechten. Und wo unklar ist, wer den Schlüssel kennt, hilft das Neugenerieren: Es erneuert Zugangs-ID und Sicherheitsschlüssel zugleich (Shopware-Dokumentation). Die Anwendung, die weiterarbeiten soll, bekommt die neuen Daten, alle anderen verlieren den Zugang.

Integrationen betreffen auch Abläufe, die nicht nach Technik aussehen. Wer etwa Kundenlisten automatisch an eine Werbeplattform übergibt, wie im Beitrag zu Neu- und Stammkunden in Google Ads beschrieben, betreibt einen Datenfluss mit personenbezogenen Daten, der mit Zweck und Zuständigkeit ins Inventar gehört.

Schritt 6: Deaktiviert ist nicht entfernt

Deaktivieren ist bequem, weil es nichts kaputt macht: Anders als beim Deinstallieren gehen beim Deaktivieren die Einstellungen einer App nicht verloren, und eine deinstallierte App bleibt in der Übersicht stehen, bis sie entfernt wird (Shopware-Dokumentation). Für die Sicherheitsprüfung heißt das: Code und Einstellungen liegen weiter im Shop, unter Umständen auch Zugangsdaten zu Fremddiensten aus der Konfiguration. Wer das Recht zur Erweiterungsverwaltung hat, schaltet den alten Stand mit einem Klick wieder ein.

Dazu kommt, dass deaktivierte Erweiterungen leicht aus der Pflege fallen: Wer nur pflegt, was läuft, lässt die abgeschalteten Einträge unbemerkt altern. Ein Beispiel ist die frühere Zahlungs-App nach einem Anbieterwechsel; wie sich Zahlungsabläufe vor und nach einem Wechsel testen lassen, zeigt der Beitrag zu fehlgeschlagenen Zahlungen. Die Frage ist hier allein, ob die Erweiterung noch gebraucht wird.

Rechtlicher Rahmen: Datenminimierung und regelmäßige Überprüfung

Die Prüfung ist nicht nur Technik. Die DSGVO verlangt von Verantwortlichen unter anderem ein Verfahren, mit dem die Wirksamkeit der technischen und organisatorischen Maßnahmen regelmäßig überprüft wird (DSGVO, Art. 32 Abs. 1 lit. d). Ein datiertes Inventar der Zugänge mit Befund und Entscheidung ist ein naheliegender Baustein für diesen Nachweis.

ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen zur Gewährleistung der Sicherheit der Verarbeitung.

Datenschutz-Grundverordnung, Art. 32 Abs. 1 lit. d

Übermittelt eine App personenbezogene Daten an den Server ihres Herstellers, damit dieser sie im Auftrag des Shops verarbeitet, ist der Hersteller in der Regel Auftragsverarbeiter. Dann darf der Shop nur mit Auftragsverarbeitern arbeiten, die hinreichend Gewähr für geeignete technische und organisatorische Maßnahmen bieten (DSGVO, Art. 28 Abs. 1). Für das Inventar bedeutet das eine weitere Spalte: Gibt es für diese App einen Vertrag zur Auftragsverarbeitung? Ob das im Einzelfall so ist, klärt der Datenschutzbeauftragte oder die Rechtsberatung, nicht die Technik.

Prüfrhythmus: wann das Inventar fällig ist

Ein Inventar veraltet mit jeder Installation. Sinnvoll ist ein fester Termin und dazu Anlässe, die eine Prüfung außer der Reihe auslösen.

1. Nach jedem Sicherheitsrelease, das Apps, Webhooks oder Rechte betrifft. Die Release Notes nennen die Advisories mit Kurztitel; Stichworte wie App, Webhook, ACL oder Integration sind der Auslöser (Shopware-Release-Notes).
2. Beim Wechsel eines Dienstleisters oder einer angebundenen Software. Der alte Zugang wird gelöscht, sobald der neue läuft, und nicht irgendwann danach.
3. Vor dem Kopieren des Shops für Test oder Abnahme, damit die Kopie keine Webhooks an Produktivsysteme schickt.
4. Wenn eine Person mit Administratorrechten ausscheidet, weil sie Integrationen und Webhooks angelegt haben kann.
5. Als fester Termin, in der Regel einmal im Quartal, auch wenn keiner der Anlässe eingetreten ist.

So unterstützen wir beim Erweiterungs-Inventar

Wir nehmen das Inventar Ihres Shops aus Datenbank und Administration auf und gleichen es mit Ihnen gegen die tatsächlichen Abläufe ab. Für jede Zeile entsteht ein Vorschlag: behalten, beim Hersteller nachfragen, durch eine engere Anbindung ersetzen oder entfernen. Umgesetzt wird zuerst in einer Testumgebung. Im Rahmen der Shopware-Wartung wiederholen wir die Prüfung nach Vereinbarung in festen Abständen und nach Sicherheitsreleases.

Jeder Zugang braucht einen Zweck und einen Besitzer

Die Sicherheitsreleases des Jahres 2026 haben gezeigt, dass Lücken im App-System, bei Webhooks und bei Rollen keine Randfälle sind. Updates bleiben die erste Antwort. Die zweite ist ein Shop, in dem jede App, jede Integration und jeder Webhook einen Zweck und eine zuständige Person hat und alles andere entfernt ist. Wer das einmal aufgenommen hat, braucht für jede weitere Runde nur noch den Vergleich mit dem letzten Stand.