OWASP Top 10 für Shopware- und NestJS-Projekte: Was davon wirklich in deinem Stack landet

Am 25. August 2026 veröffentlichte Shopware ein Sicherheitsrelease mit zehn Korrekturen. Eine davon, von den Forschern bei Sansec gefunden, erlaubte einem Angreifer ohne Kundenkonto, über die Store API SQL einzuschleusen und sich von dort bis zum Admin-Konto und zur Code-Ausführung durchzuarbeiten. Nötig war nur ein aktiver Sales-Channel-Key, und genau den liefert jede Headless-Storefront ihren Clients im Normalbetrieb aus (Sansec, 25.08.2026).

Hältst du dieses Release gegen die OWASP Top 10, bedient es mit dem Nachfolger vom 16. September sechs der zehn Kategorien. Die OWASP Top 10 sind das meistzitierte und am häufigsten falsch benutzte Dokument der Anwendungssicherheit: Ein Team hängt die zehn Punkte als Checkliste an die Wand, setzt zehn Häkchen und ist danach genauso angreifbar wie vorher. Die Liste ist ein Ranking von Risikokategorien über Millionen von Anwendungen, ein Bewusstseinsdokument, wie OWASP selbst sagt.

Die Frage für dein Projekt lautet deshalb: Welche dieser zehn Kategorien tauchen in deinem Stack auf, in welcher Form, an welcher Stelle im Code oder in der Konfiguration? Für Shopware und NestJS lässt sich das beantworten, weil beide reife, offene Systeme mit öffentlicher Advisory-Historie sind.

Was die OWASP Top 10 2025 sind, und was sie nicht sind

Die achte Auflage wurde am 6. November 2025 auf der OWASP Global AppSec in Washington als Release Candidate vorgestellt und im Januar 2026 finalisiert (OWASP Top 10:2025). Datenbasis sind über 2,8 Millionen getestete Anwendungen und 589 untersuchte Schwachstellentypen (CWEs). Acht der zehn Kategorien stammen aus diesen Daten, zwei aus einer Community-Umfrage, weil OWASP die Daten ausdrücklich für unvollständig hält.

„Incidence Rate“ bedeutet bei OWASP: Anteil der Anwendungen, in denen mindestens eine Schwachstelle der Kategorie gefunden wurde. Broken Access Control liegt im Schnitt bei 3,74 Prozent, in einzelnen Datensätzen bei 20,15 Prozent. Das klingt klein. Dahinter stehen 1,84 Millionen einzelne Fundstellen.

Drei Verschiebungen gegenüber 2021 prägen die Ausgabe. Software Supply Chain Failures ist neu auf Platz 3 und ersetzt „Vulnerable and Outdated Components“, erweitert um kompromittierte Pakete, manipulierte Builds und unsichere Updates. In der Community-Umfrage setzten exakt 50 Prozent der Befragten diese Kategorie auf Platz 1. Security Misconfiguration stieg von Platz 5 auf Platz 2.

Server-Side Request Forgery ging als eigene Kategorie in Broken Access Control auf. Neu auf Platz 10 steht „Mishandling of Exceptional Conditions“: Stacktraces in der Response, Ressourcen, die nach einer Exception nicht freigegeben werden, 24 CWEs, die vorher unter „schlechte Code-Qualität“ liefen.

Zwei Stacks, eine Angriffsfläche

Shopware 6 hat drei öffentliche Türen, Storefront, Store API und Admin API, plus ein Erweiterungssystem, in dem fremder Code läuft: Plugins mit vollem PHP-Zugriff und Apps mit Twig-basierten App Scripts in einer Sandbox. Ein NestJS-Backend definiert seine Angriffsfläche fast vollständig über das, was du deklarierst, Controller, DTOs, Guards, Pipes. Das Framework selbst bringt wenig Angriffsfläche mit, dafür bringt es npm mit.

Die Shopware-Releases 6.7.13.1 und 6.6.10.23 vom 25. August (zehn Fixes, neun davon auch in 6.6) sowie 6.7.14.1 und 6.6.10.25 vom 16. September (fünf weitere) sind eine bessere Landkarte der realen Angriffsfläche als jede abstrakte Liste, sechs Kategorien in zwei Releases (Release Notes 6.7.13.1, 6.7.14.1):

A01 Broken Access Control: Die Kategorie, die du selbst baust

Broken Access Control steht seit 2021 auf Platz 1, und es ist die Kategorie, bei der dir weder Shopware noch NestJS die Arbeit abnehmen können. Das Framework weiß nicht, dass Kunde 4711 die Rechnung von Kunde 4712 nicht sehen darf.

In Shopware läuft Zugriffskontrolle über drei Mechanismen: die ACL der Administration, die Berechtigungen von Integrationen und Apps, und die Frage, welche Entity-Felder über die Store API überhaupt sichtbar sind. Alle drei waren in den letzten Releases betroffen.

Die Rechteausweitung über Rollen-Massenzuweisung bedeutet: Ein Admin-Nutzer, der Benutzer bearbeiten durfte, konnte über das Feld aclRoles im Update-Request zusätzliche Rollen vergeben, die über seine eigenen Rechte hinausgingen, weil das Feld nicht gegen seine Berechtigung geprüft wurde. Der Webhook-Fix bedeutet: Eine App, die nur Events abonnieren durfte, bekam Daten, für die sie keine Leseberechtigung hatte.

Für dein Projekt heißt das zweierlei. Jede Integration, die ein ERP, ein PIM oder ein Marketing-Tool an den Shop hängt, bekommt eine eigene Rolle mit genau den Rechten, die sie braucht. Und jeder Plugin-Controller, den du selbst schreibst, prüft seine Berechtigung explizit, weil die ACL nur greift, wo sie deklariert ist.

NestJS bringt Guards mit, aber ein Guard, den niemand an eine Route hängt, schützt nichts. Der häufigste Fehler ist der klassische IDOR: Die Route GET /orders/:id prüft, ob ein gültiger Token vorliegt, aber nicht, ob die Bestellung dem Token-Inhaber gehört.

@Get(':id')
@UseGuards(JwtAuthGuard)
async findOne(@Param('id') id: string, @CurrentUser() user: User) {
  const order = await this.orders.findOne({ where: { id } });
  if (!order || order.customerId !== user.id) {
    throw new NotFoundException(); // bewusst 404, nicht 403
  }
  return order;
}

Das NotFoundException ist kein Zufall: Ein 403 bestätigt dem Angreifer, dass die Bestellung existiert.

Der zweite NestJS-Klassiker ist Mass Assignment. Wer ein DTO ohne whitelist: true validiert, nimmt jedes Feld an, das der Client schickt, auch role: 'admin'. Die globale ValidationPipe mit whitelist und forbidNonWhitelisted ist die eine Zeile, die das abschaltet (NestJS-Dokumentation, Validation):

app.useGlobalPipes(new ValidationPipe({
  whitelist: true,
  forbidNonWhitelisted: true,
  transform: true,
}));

Dass SSRF seit 2025 in dieser Kategorie steckt, passt zu beiden Stacks. Shopware hat im August zwei SSRF-Lücken über DNS-Rebinding geschlossen, im Medien-Import und im App-System. In NestJS entsteht dieselbe Lücke, sobald ein Endpunkt eine URL vom Client entgegennimmt und per HttpService abruft: Bild-Proxy, Webhook-Tester, Link-Vorschau. Die Metadaten-Adresse des Cloud-Providers, 169.254.169.254, liegt dann eine Anfrage entfernt, mit den Zugangsdaten der Instanz.

A02 Security Misconfiguration: Der Sprung auf Platz 2 hat einen Grund

Dass Fehlkonfiguration von Platz 5 auf Platz 2 geklettert ist, überrascht keinen, der Deployments betreut. OWASP hat 16 CWEs in der Kategorie, in einzelnen Datensätzen waren 27,7 Prozent der Anwendungen betroffen. Die Kategorie entsteht in .env-Dateien, in Reverse-Proxy-Configs und in Defaults, die seit der Installation niemand angefasst hat.

Der Shopware-Fall vom August ist das Lehrbuchbeispiel. Der Passwort-Reset der Administration baute den Link zum Zurücksetzen aus dem Host-Header des Requests. Wer diesen Header manipulieren konnte, ließ den Shop einen Reset-Link mit seiner eigenen Domain an den Admin schicken. Ein Klick, und das Token lag beim Angreifer. CVSS 9,3, behoben in 6.6.10.23 und 6.7.13.1 (GitHub Advisory GHSA-xj2c-8fw5-mr6m). Der von Shopware genannte Workaround: Trusted Hosts in Symfony konfigurieren, also dem Framework sagen, unter welchen Domains der Shop überhaupt antworten darf.

Trusted Hosts gab es die ganze Zeit. Im Shopware-Default sind sie nicht gesetzt, weil der Shop auch ohne sie funktioniert. Fehlkonfiguration ist fast immer eine Funktion, die läuft, und ein Schutz, der fehlt.

Die Shopware-Liste, die du in einer Stunde durchgehen kannst (Shopware Security Reference):

• APP_ENV=prod und APP_DEBUG=0 in Produktion, ein APP_SECRET, das nicht aus einer kopierten .env stammt.
• Trusted Hosts und Trusted Proxies gesetzt, damit Host- und X-Forwarded-*-Header nicht vom Client kommen.
• Die Content Security Policy über shopware.security.csp_templates an deine Drittskripte angepasst, nicht deaktiviert.
• shopware.media.enable_url_upload_feature nur an, wenn du den URL-Upload wirklich brauchst.

Das NestJS-Gegenstück: app.enableCors() ohne Origin-Liste, weil es im Frontend-Test gestört hat. Swagger unter /api/docs in Produktion erreichbar, mit jedem Endpunkt und jedem Schema. Kein helmet, also keine Security-Header. Und @nestjs/devtools-integration noch in den Dependencies, obwohl sie nur für die lokale Entwicklung gedacht ist.

Letzteres hatte Konsequenzen: CVE-2025-54782 erlaubte einer beliebigen Webseite, über einen CSRF-Request an den laufenden lokalen Devtools-Server Code auf dem Rechner des Entwicklers auszuführen, CVSS 9,4 (GitHub Advisory GHSA-85cg-cmq5-qjm7). Betroffen war die Entwicklungsmaschine, auf der üblicherweise auch die Deploy-Keys liegen.

app.use(helmet());
app.enableCors({ origin: ['https://shop.example.de'], credentials: true });
if (process.env.NODE_ENV !== 'production') {
  SwaggerModule.setup('api/docs', app, document);
}

A03 Software Supply Chain: Was du installierst, hat niemand mehr geprüft

OWASP hat die Kategorie neu zugeschnitten, weil „veraltete Komponenten“ das Problem nicht mehr beschreibt. Seit September 2025 hat die npm-Welt das mehrfach erlebt. Der Shai-Hulud-Wurm kompromittierte in mehreren Wellen Hunderte Pakete, stahl Entwickler-Tokens über Install-Skripte und nutzte diese Tokens, um sich in weitere Pakete zu kopieren. Microsoft veröffentlichte am 9. Dezember 2025 eine eigene Handreichung zur zweiten Welle (Microsoft Security Blog).

Am 4. August 2026 folgte die Variante CHAINDROP mit über 400 betroffenen Paketen, darunter keyv mit mehr als 600 Millionen Downloads im Monat (Elastic Security Labs). keyv steckt in cache-manager, und cache-manager steckt hinter dem CacheModule, das in vielen NestJS-Projekten in der app.module.ts registriert ist. Ob du betroffen warst, zeigt ein npm ls keyv im Projektordner in zwei Minuten.

npm 12, erschienen am 8. Juli 2026, führt Install-Skripte von Abhängigkeiten nicht mehr aus, es sei denn, du erlaubst sie explizit pro Paket; Git- und Tarball-Abhängigkeiten sind standardmäßig gesperrt, Zugriffstokens mit Zwei-Faktor-Bypass abgekündigt (InfoQ, August 2026). Die Begründung: Diese drei Vektoren steckten laut JFrog in rund 53 Prozent der beobachteten bösartigen npm-Angriffe des vergangenen Jahres.

Für dein NestJS-Projekt, in der Reihenfolge der Wirkung:

• Lockfile committen und in CI mit npm ci installieren, nie mit npm install.
• Install-Skripte in CI mit --ignore-scripts ausschalten, solange du nicht auf npm 12 bist.
• Neue Versionen erst mit einigen Tagen Karenz übernehmen; kompromittierte Versionen werden meist innerhalb von Stunden zurückgezogen.
• Ein SBOM erzeugen, damit du bei der nächsten Welle in Minuten weißt, ob du betroffen bist.

# CI: deterministisch, ohne Install-Skripte
npm ci --ignore-scripts
npm audit --audit-level=high

Composer hat keine Install-Skripte in der npm-Form, und Shopware-Plugins kommen überwiegend aus dem Shopware Store mit Review. Die Supply-Chain-Fläche im Shopware-Stack sind die Erweiterungen selbst. Der Sandbox-Escape vom August zeigt das Risiko: Eine installierte App konnte aus ihren App Scripts heraus beliebige PHP-Funktionen und OS-Befehle mit den Rechten des Webservers ausführen, CVSS 9,6 (GHSA-6qhw-38wm-7g7h).

Bereits im März 2026 ließ sich über eine erneute App-Registrierung der Kommunikationskanal zwischen Shop und App umlenken: Wer das App-Secret kannte, konnte den Verkehr auf einen eigenen Server leiten und so an die API-Zugangsdaten des Shops kommen, CVE-2026-31889, CVSS 8,9 (GitHub Advisory CVE-2026-31889). Jede App, jedes Plugin ist Code, dem du die Rechte deines Shops gibst.

A05 Injection: Gelöst, bis jemand am Framework vorbeischreibt

// verwundbar
qb.where(`order.customerEmail = '${email}'`);
// sicher
qb.where('order.customerEmail = :email', { email });

Injection passiert heute dort, wo jemand das Framework umgeht. Beide Zeilen oben stehen in NestJS-Projekten, oft im selben Repository. TypeORM, Prisma und MikroORM parametrisieren alles, was du über ihre API schickst. Sie parametrisieren nicht, was du in einen Template-String hineinschreibst. Injection ist von Platz 3 auf Platz 5 gefallen, weil ORMs, Prepared Statements und auto-escapende Template-Engines das Problem in der Breite entschärft haben. Trotzdem stehen 62.445 CVEs hinter der Kategorie, mehr als hinter jeder anderen.

In Shopware ist das die Data Abstraction Layer. Wer Criteria und Repositories benutzt, bekommt parametrisierte Queries geschenkt. Wer in einem Plugin $connection->executeQuery("... WHERE id = '" . $id . "'") schreibt, hat 2015 zurückgeholt. Die drei SQL-Injections aus August und September lagen an Stellen, an denen dynamische Namen in SQL wanderten: Feldnamen aus App-Manifesten für Custom Entities, Aggregationsnamen in der Store API, Range-Aggregationen in der Store API (GHSA-p37c-pm9p-7vm5).

Namen, nicht Werte. Prepared Statements schützen Werte. Für Identifier, also Tabellen-, Spalten- und Aggregationsnamen, brauchst du eine Allowlist.

Dazu kommt Twig. Shopware rendert Storefront und App Scripts mit Twig, und Twig escaped standardmäßig. Aber |raw existiert, und Template-Injection ist eine eigene Klasse: CVE-2026-23498 erlaubte über eine Lücke in der Filter-Validierung von map() das Ausführen von PHP-Code aus Templates heraus (GitLab Advisory Database). Wer eigene Twig-Filter oder -Funktionen in Plugins registriert, erweitert genau diese Angriffsfläche.

KI-generierter Code ändert daran nichts zum Guten. Ein Coding-Assistent schreibt die String-Verkettung in der Query genauso bereitwillig wie die parametrisierte Variante, je nachdem, was im Kontext steht, und die Dependency, die er vorschlägt, hat er nicht auf ihr Veröffentlichungsdatum geprüft. Wir haben das in Vibe Coding vs. guter Code ausführlicher beschrieben.

Kurz gesagt: Injection ist in beiden Stacks ein Code-Review-Thema geworden. Suche nach String-Verkettung in der Nähe von SQL, Twig und Shell.

A07, A09, A10: Die drei, die im Betrieb entscheiden

@nestjs/throttler ist nicht installiert, bis du es installierst (NestJS Rate Limiting). Shopware dagegen bringt für Login, Gast-Login, Passwort-Reset, Admin-Recovery, Kontaktformular, Newsletter und Warenkorb seit 6.4.6 Rate Limiter mit. Konfigurierbar sind sie unter shopware.api.rate_limiter, mit Backoff-Staffeln wie 10 Versuche in 10 Sekunden, dann 15 in 30, dann 20 in 60 (Shopware Rate Limiter). Der August-Fix für den Gast-Dokumenten-Download war eine Route, die diesen Schutz nicht hatte. Eigene Routen bekommen diesen Schutz nur, wenn du ihn selbst konfigurierst.

Beim JWT-Handling in NestJS gilt: Signaturalgorithmus explizit setzen, Access Tokens kurz halten, Refresh Tokens serverseitig widerrufbar machen. Ein JWT mit sieben Tagen Laufzeit und ohne Revocation ist ein Passwort, das du nicht ändern kannst.

Logging ohne Alarmierung ist die stillste Kategorie. Shopware schreibt Login-Fehlschläge und API-Fehler in Logs, ein Audit-Log für Admin-Aktionen hat der Core nicht. NestJS loggt, was du ihm konfigurierst. Beides ist wertlos, wenn niemand hinsieht.

Der Host-Header-Angriff vom August hinterlässt im Access-Log eine einzige Spur, einen Reset-Request mit fremdem Host-Header, sofern dein Log-Format den Host überhaupt mitschreibt, und die fällt nur auf, wenn jemand danach sucht. Dasselbe gilt für das Dutzend 401er pro Minute, das einem Credential-Stuffing auf der Store API vorausgeht.

Eine Alarmierung auf drei Signale, Login-Fehlschläge pro Minute, 5xx-Rate und neue Admin-Nutzer, deckt den größten Teil der realen Angriffe ab. Wie sich das mit Bordmitteln aufsetzen lässt, steht in Alarmierung mit n8n einrichten.

Die neue Kategorie A10 ist in NestJS konkret: Ein Exception-Filter, der in Produktion error.stack in die Response schreibt, verrät Dateipfade, Versionen und Query-Fragmente. Der Standard-Filter von NestJS tut das nicht, ein selbstgeschriebener oft doch.

Und ein catch, der einen Fehler loggt und weitermacht, lässt in einer mehrstufigen Bestellung den Zustand halb geschrieben zurück, die Transaktion offen, die Datenbankverbindung belegt. OWASP nennt diese Beispiele in der Kategoriebeschreibung (A10:2025). Wie ein Backend geschnitten sein sollte, damit solche Zustände gar nicht erst entstehen, steht in unserem Leitfaden zur Enterprise-Backend-Architektur.

Patchen ist Architektur, nicht Wartung

Alles bisher Gesagte setzt voraus, dass dein Stack auf einem Stand ist, den der Hersteller noch absichert.

Shopware liefert Sicherheitsfixes auf zwei Wegen: als Patch-Release für die aktuellen Minor-Versionen und als Security Plugin, das bekannte Fixes in ältere Versionen zurückportiert. 6.6 und 6.7 erhalten Sicherheitsupdates bis zum 28. Februar 2028, 6.5 bis zum 28. Februar 2027 (endoflife.date: Shopware). Wer auf 6.5 oder darunter steht, bekommt die Fixes vom August nur über das Plugin, und Shopware nennt das Plugin selbst den schlechteren Weg, weil Patches über eine Erweiterung Seiteneffekte haben können (Shopware Release Policy).

Node.js ist strenger. Node 20 hat am 30. April 2026 das Ende seines Supports erreicht, Node 22 bekommt Sicherheitsfixes bis April 2027, Node 24 ist die aktuelle LTS, Node 26 folgt Ende Oktober 2026 (endoflife.date: Node.js). Ein NestJS-Backend auf Node 20 läuft seit dem 30. April ohne Sicherheitsupdates der Runtime. OWASP führt das nirgends, weil es trivial ist. In Incident-Berichten taucht es trotzdem regelmäßig auf.

Die praktische Konsequenz ist ein festes Patch-Fenster. Shopware veröffentlicht Sicherheitsreleases nach Bedarf, ohne festen Rhythmus und ohne Vorankündigung. Wer ein Staging mit automatisierten Smoke-Tests hat, bringt ein Security-Release in 48 Stunden live. Wer keines hat, wartet auf das nächste Projektbudget, während die Advisories mit Versionsnummern öffentlich auf GitHub liegen. Angreifer lesen sie am Tag der Veröffentlichung.

Was in deinem Stack wirklich landet

Vier Kategorien musst du aktiv bearbeiten: Access Control, weil nur du weißt, wer was sehen darf. Misconfiguration, weil Defaults nicht für Produktion gemacht sind. Supply Chain, weil Pakete zwischen Maintainer und npm install manipuliert werden. Injection, weil es an den Rändern des Frameworks weiterlebt. Die übrigen sechs deckst du mit Disziplin im Betrieb ab: ein Patch-Fenster von Tagen, Rate Limits auf allem, was authentifiziert, eine Alarmierung, die jemand liest, und Fehlerbehandlung, die nichts verrät.

Ob dein Stack dort steht, beantworten vier Fragen, für die du keinen Pentest brauchst:

1. Welche Integration hat heute noch Admin-Rechte, obwohl sie nur Bestellungen lesen muss?
2. Sind APP_ENV, Trusted Hosts und CORS-Origins in Produktion explizit gesetzt, oder laufen sie auf Defaults?
3. Liegt das Lockfile im Repo, und läuft die CI mit npm ci --ignore-scripts?
4. Wie viele Tage lagen zwischen dem 25. August 2026 und deinem Shopware-Update?

Wer bei einer der Fragen zögert, hat seine Prioritätenliste. Und wer dafür einen zweiten Blick will, der Shopware-Shop und Backend zusammen betrachtet, findet diese Arbeit bei uns als Shopware-Agentur und im Bereich Enterprise-Software.

Häufige Fragen zu OWASP Top 10, Shopware und NestJS

Ist die OWASP Top 10 2025 schon final? Ja. Die Liste wurde am 6. November 2025 als Release Candidate veröffentlicht und im Januar 2026 finalisiert. Eine „OWASP Top 10 2026“ gibt es nicht; die nächste Ausgabe folgt im üblichen Rhythmus von etwa vier Jahren.

Welche OWASP-Kategorie betrifft Shopware am stärksten? Nach den Sicherheitsreleases von August und September 2026: Broken Access Control (Rechteausweitung, Webhook-ACL, SSRF), Injection (drei SQL-Injections, Twig) und Supply Chain (App-Sandbox-Escape, App-Registrierung). Der Passwort-Reset über den Host-Header fällt unter Security Misconfiguration.

Ist NestJS von Haus aus sicher? NestJS bringt die Werkzeuge mit, aber kaum Defaults: Guards, ValidationPipe, Throttler und Helmet schützen erst, wenn du sie einsetzt. Das größte Risiko liegt in den npm-Abhängigkeiten.

Reicht das Shopware Security Plugin statt eines Updates? Es schließt bekannte Lücken in älteren Versionen, aber Shopware empfiehlt das Update, weil Patches über ein Plugin Seiteneffekte haben können. 6.6 und 6.7 bekommen Sicherheitsupdates bis Februar 2028, 6.5 bis Februar 2027.

Was ist der schnellste Schutz gegen npm-Supply-Chain-Angriffe? npm ci --ignore-scripts in der CI, ein committetes Lockfile, einige Tage Karenz vor dem Übernehmen neuer Versionen und Zwei-Faktor-Authentifizierung ohne Bypass-Tokens auf allen npm-Konten. Seit npm 12 sind Install-Skripte standardmäßig aus.