Blaze Blog /

Amazon SP-API: Pentest-Anforderungen für Entwickler

Leitfäden
Oct 8, 2026
8Min. Lesezeit
Editorial-Collage aus Versandetikett, Serverinfrastruktur und manueller Sicherheitsprüfung.
Loading the Elevenlabs Text to Speech AudioNative Player...

Anforderungen geprüft: 8. Oktober 2026

Amazon verlangt mindestens alle 365 Tage einen Penetrationstest im Rahmen der zusätzlichen Anforderungen für personenbezogene Daten (PII) seiner Data Protection Policy. Entwickler, deren Integrationen PII verarbeiten, müssen die relevante Anwendung und die unterstützenden Systeme testen lassen und die gefundenen Schwachstellen beheben.

Wenn Sie eine Sicherheitsprüfung für die Amazon Selling Partner API (SP-API) vorbereiten, klären Sie zuerst Datenzugriff, Testumfang und Einreichungsfrist. Dieser Leitfaden erklärt die Anforderungen und welche Nachweise Sie vorbereiten sollten.

Verlangt Amazon SP-API einen Penetrationstest?

Die DPP unterscheidet allgemeine Sicherheitsanforderungen von zusätzlichen PII-Anforderungen. Die jährliche Pentest-Pflicht steht in Abschnitt 2.7.2 der zusätzlichen Anforderungen. Allgemeine Sicherheitsmaßnahmen gelten auch für Integrationen ohne PII.

Prüfen Sie, welche Daten Ihre Anwendung abruft und verarbeitet, welche eingeschränkten Rollen sie verwendet oder beantragt und welche Vorgaben Ihr Amazon-Prüfvorgang enthält. Entscheiden Sie die Anwendbarkeit anhand der tatsächlichen Datenverarbeitung: Ein Bestandsdashboard und eine Versandsoftware können unterschiedliche Daten nutzen.

Auch die Token-Nutzung braucht Kontext. In der Orders API v2026-01-01 ermöglichen genehmigte Rollen PII-Zugriff ohne Erstellung eines Restricted Data Token (RDT). Eine Integration kann daher personenbezogene Daten verarbeiten, ohne einen RDT zu verwenden.

Ein Pentest liefert einen Teil der Nachweise für die Prüfung. Amazons Registrierungsleitfaden für öffentliche Entwickler beschreibt eine umfassendere Bewertung eingeschränkter Rollen, einschließlich Architektur, Datenflüssen und PII-Schutz. Ihr Bericht sollte diese Bewertung zusammen mit Richtlinien, Diagrammen und Betriebsnachweisen unterstützen.

Testhäufigkeit und Fristen zur Behebung

Für Integrationen, die den zusätzlichen PII-Anforderungen unterliegen, legt die aktuelle Richtlinie Folgendes fest:

AktivitätMindestanforderungDPP-Abschnitt
PenetrationstestMindestens alle 365 Tage2.7.2
SchwachstellenscanMindestens alle 30 Tage2.7.1
Scans nach wesentlichen ÄnderungenNach wesentlichen Änderungen an Netzwerk, Anwendung oder Infrastruktur2.7.1
Schwachstellenscan des CodesVor jedem Software-Release2.7.1
Behebung kritischer SchwachstellenInnerhalb von 7 Tagen nach Entdeckung2.7.3
Behebung von Schwachstellen mit hohem RisikoInnerhalb von 30 Tagen nach Entdeckung2.7.3

Diese Vorgaben stammen aus den DPP-Abschnitten 2.7.1 bis 2.7.3. Die Frist beginnt mit der Entdeckung. Vereinbaren Sie deshalb, wie dringende Befunde während des Tests die Entwicklung erreichen.

Amazons Leitfaden zum Schwachstellenmanagement sieht außerdem einen zweiten Pentest nach der Behebung vor, um die Korrekturen zu überprüfen. Planen Sie dafür Zeit vor der Einreichungsfrist ein.

Wesentliche Änderungen lösen ausdrücklich Scans aus. Ein zusätzlicher Pentest nach einem grundlegenden Umbau ist eine sinnvolle risikobasierte Entscheidung, auch wenn der jährliche Test erst kürzlich stattfand.

Was sollte Ihr SP-API-Pentest abdecken?

DPP-Abschnitt 2.7.2 verlangt eine branchenweit anerkannte Methodik und die Abdeckung der Systeme, die Amazon-Daten verarbeiten. Amazons Testleitfaden nennt relevante Netzwerkinfrastruktur, Cloud-Umgebungen, Anwendungen, APIs und Speicher. Identifizieren Sie diese Systeme und ihre Abhängigkeiten anhand Ihres Datenflussdiagramms.

Für eine SP-API-Integration empfehlen wir fünf Prüfbereiche:

  • Verkäuferautorisierung und Zugangsdaten: Wie Ihre Anwendung eine Autorisierung dem richtigen Verkäufer zuordnet und Login-with-Amazon-Zugangsdaten, Refresh Tokens, Access Tokens sowie gegebenenfalls RDTs schützt.
  • Zugriffskontrollen in Anwendung und API: Ob Benutzer auf Bestellungen, Exporte oder Versandinformationen anderer Verkäufer zugreifen können, indem sie Kennungen ändern, Organisationen wechseln oder Funktionen außerhalb ihrer Rolle aufrufen.
  • Hintergrundverarbeitung und Integrationen: Ob Jobs, Warteschlangen, Importe, Callbacks und Exporte die vorgesehenen Berechtigungen beim Datentransfer zwischen Komponenten erhalten.
  • Datenspeicher: Wie Datenbanken, Objektspeicher, Backups und Administrationsoberflächen Amazon-Daten schützen, einschließlich Kopien außerhalb der Hauptanwendung.
  • Cloud- und Netzwerkkontrollen: Ob Dienstberechtigungen, exponierte Ressourcen, Konfigurationsfehler oder interne Zugriffspfade die Integration gefährden können.

Ein API-Penetrationstest untersucht, ob die Autorisierung über Benutzer, Rollen und Abläufe hinweg funktioniert. Eine funktionierende SP-API-Verbindung sagt wenig darüber aus, ob Ihr eigenes Backend diese Grenzen durchsetzt.

Verfolgen Sie die Daten über die API hinaus. Ein Export kann bei der Erstellung korrekte Verkäuferberechtigungen übernehmen, aber über eine gemeinsam genutzte Download-URL anderen Kunden zugänglich werden. Anwendung, Exportprozess und Speicherberechtigungen tragen gemeinsam zu diesem Risiko bei. Je nach Architektur sollten Sie Cloud-Penetrationstests und Netzwerk-Penetrationstests einbeziehen.

Klären Sie die Eigentümerschaft der Systeme und die Testfreigaben vor Beginn. Für kundenseitig betriebene AWS-Ressourcen gilt die AWS-Richtlinie für Penetrationstests. Sie erlaubt keine Angriffe auf Amazons SP-API-Dienst selbst.

Beispielhafter SP-API-Prüfumfang: Zugangsdaten, Mandantentrennung, Verarbeitung, Speicher und Cloud-Kontrollen der Integration; Amazon-Dienste ausgeschlossen.

Warum ein Schwachstellenscan keinen vollständigen Pentest ersetzt

Scans erkennen bekannte Schwachstellen und Konfigurationsprobleme. Pentests untersuchen, ob sich Schwächen im Kontext Ihrer Anwendung ausnutzen lassen. Beide Aktivitäten gehören in das Testprogramm.

Ein Scanner kann beispielsweise eine veraltete Abhängigkeit finden. Das beantwortet nicht, ob ein Lagermitarbeiter Kundenadressen eines anderen Verkäufers herunterladen kann. Dafür braucht es geeignete Konten, ein Verständnis der Berechtigungen und Tests des Anwendungsverhaltens.

SP-API Guard kann AWS-Konfigurationen anhand von DPP-Kontrollen bewerten. Die Ergebnisse helfen bei der Vorbereitung, weisen aber nicht nach, dass der jährliche Pentest durchgeführt wurde.

Blaze führt manuelle Pentests durch und nutzt KI-Unterstützung, wo sie sinnvoll ist. Sicherheitsforscher steuern die Prüfung, untersuchen Anwendungslogik und validieren Befunde. Automatisierung unterstützt die Arbeit; der Bericht dokumentiert die tatsächlich geprüften und nachgewiesenen Sachverhalte.

Welche Nachweise sollte der Bericht enthalten?

Amazons Leitfaden zum Schwachstellenmanagement beschreibt einen Bericht über Testaktivitäten, Schwachstellen und empfohlene Maßnahmen. Berücksichtigen Sie zusätzliche Nachweisvorgaben Ihres Prüfvorgangs.

Für eine aussagekräftige Einreichung empfehlen wir:

  • Umfang und Termine: Systeme, Umgebungen, Rollen und Testzeitraum sowie klar benannte Ausschlüsse und Zugriffsbeschränkungen.
  • Methodik und Abdeckung: Die benannte Methodik, ihre Anwendung sowie die geprüften Systeme und Sicherheitsgrenzen.
  • Validierte Befunde: Reproduzierbare Nachweise, betroffene Systeme, Schweregrad, geschäftliche Auswirkungen und umsetzbare Behebungshinweise.
  • Überprüfung der Korrekturen: Was wann erneut getestet wurde und welche Befunde behoben oder noch offen sind.

Eine Management-Zusammenfassung erklärt die Risiken für Entscheidungsträger. Technische Nachweise helfen der Entwicklung, sie zu reproduzieren und zu beheben. Beide müssen die geprüfte Umgebung zutreffend beschreiben.

Führen Sie ein Befundregister mit betroffenem System, Entdeckungsdatum, Schweregrad, Verantwortlichem, Behebungsfrist, Korrekturbeleg und Retest-Ergebnis. Bewahren Sie die ursprünglichen Befunde dazu auf. Ein Bericht mit Umfang, Ergebnissen und Nachprüfung liefert mehr Informationen als eine reine Testbestätigung.

Unser Amazon-SP-API-Penetrationstest umfasst die Integration und ihre unterstützenden Systeme. Vereinbaren Sie Bericht und Retest-Leistungen vor Testbeginn.

Bereiten Sie Ihre Integration auf Amazons Prüfung vor

Geben Sie dem Testteam vorab ausreichend Kontext:

  1. Teilen Sie Amazons Anfrage, die relevanten Rollen und Ihre Prüfungsfrist.
  2. Dokumentieren Sie den Weg der Amazon-Daten durch Anwendung, Infrastruktur, Speicher und externe Abhängigkeiten.
  3. Stellen Sie API-Dokumentation und repräsentative Konten für unterschiedliche Verkäufer und Benutzerrollen bereit.
  4. Vereinbaren Sie Umgebung, erlaubte Techniken, Zugänge und Eskalationskontakt.
  5. Reservieren Sie Entwicklungskapazität für die Behebung und planen Sie die Überprüfung der Korrekturen.

Unser englischsprachiger Leitfaden zur API-Pentest-Vorbereitung erklärt Dokumentation und Zugangsanforderungen ausführlicher.

Prüfen Sie die Testkonten vor dem Start. Kann sich das Team anmelden, aber Bestellverarbeitung, Exporte oder Verwaltungsabläufe nicht erreichen, leidet die Abdeckung. Schließen Sie diese Zugangslücken, solange Sie den Plan noch anpassen können.

Unser englischsprachiger Leitfaden zu SOC-2-Pentest-Anforderungen erklärt, wie Rahmenwerk und Prüfumfang die Wiederverwendung von Nachweisen beeinflussen.

Amazons Sicherheitsleitfaden verweist auf qualifizierte Sicherheitsfachleute oder externe Unternehmen.

Definieren Sie den Umfang Ihres SP-API-Pentests

Wenn Amazon Testnachweise angefordert hat, bringen Sie Architektur, Details zum Datenzugriff und Prüfungsfrist zum Scoping-Gespräch mit. Blaze prüft die relevanten Systeme durch manuelle Pentests mit sinnvoller KI-Unterstützung und liefert validierte Befunde sowie vereinbarte Nachweise zur Überprüfung der Korrekturen.

Sprechen Sie mit einem Experten.

Häufige Fragen

Die ausdrückliche jährliche Pflicht gehört zu den zusätzlichen PII-Anforderungen der DPP. Prüfen Sie Ihre Datenverarbeitung und Amazons Vorgaben. Integrationen ohne PII unterliegen weiterhin allgemeinen Sicherheitsanforderungen. Kundenverträge oder andere Verpflichtungen können unabhängig davon Tests verlangen.

Die geprüften öffentlichen Quellen nennen keine allgemeine Liste Amazon-zugelassener Anbieter und keine universelle CREST-Pflicht. Amazons Sicherheitsleitfaden verweist auf qualifizierte Sicherheitsfachleute oder externe Unternehmen. Prüfen Sie deren Fähigkeit, Ihre Anwendung, Cloud und Netzwerke zu testen, sowie die Vorgaben Ihres Prüfvorgangs.

Das ist möglich, wenn Umfang, Zeitpunkt, Methodik und Nachweise die Amazon-Anforderungen erfüllen. Prüfen Sie, ob die SP-API-Integration und ihre unterstützenden Systeme enthalten waren. Ein Compliance-Label allein belegt keine geeignete Abdeckung.

Nein. Guard bewertet AWS-Konfigurationen anhand von DPP-Kontrollen. Nutzen Sie die Befunde, um Konfigurationslücken zu erkennen und weitere Prüfungen vorzubereiten. Führen Sie die separat geforderten Scans und Pentests durch und dokumentieren Sie Umfang, Ergebnisse und Behebung.

Die Kalkulation hängt von Anwendungen, Endpunkten, Rollen, Infrastruktur, verfügbaren Zugängen und Retests ab. Teilen Sie Architektur und Frist für ein passendes Angebot. Vergleichen Sie manuellen Testaufwand, Systemabdeckung, Berichtsinhalte und enthaltene Retests. Planen Sie anschließende Entwicklungsarbeit ein: Berichtslieferung und abgeschlossene Behebung sind unterschiedliche Meilensteine.

Nein. Amazon prüft weitere Sicherheitskontrollen und entscheidet über das Ergebnis. Ein Bericht liefert technische Nachweise für den vereinbarten Umfang. Korrekte Dokumentation, umgesetzte Kontrollen, Behebungsnachweise und Antworten im Prüfvorgang tragen ebenfalls zur Bewertung bei.

Haben Sie Fragen? Lassen Sie uns sprechen.

Kontaktieren Sie unsere Cybersecurity-Experten

Mehr erfahren