Introduction
If your application integrates with Amazon’s Selling Partner API (SP-API), especially for restricted data or operations, you’ll eventually need a penetration test that satisfies Amazon’s security review.
This isn’t just another checkbox. Amazon’s requirements are more specific and rigorous than a typical web application or cloud Pen-test. Many teams discover this the hard way after submitting a report only to receive clarification requests or outright rejection.
In this guide, we explain what an SP-API Pen-test actually is, the subtle but critical differences from standard testing, why generic vendors often fail, and how to ensure your assessment meets Amazon’s expectations.
What Is an SP-API Penetration Test?
At its core, an SP-API Pen-test is a targeted security assessment of your entire application ecosystem that touches Amazon’s data and APIs.
It goes beyond surface-level vulnerability scanning. Amazon wants proof that:
● Your integration handles authentication and authorization securely
● Amazon seller and customer data is protected throughout its lifecycle
● There are no exploitable weaknesses that could lead to data leakage or unauthorized access
This requirement stems from Amazon’s Selling Partner API Data Protection Policy. For apps requesting PII access or restricted roles, the Pen-test becomes a key part of the approval process.
Why SP-API Pen-tests Are Different: The Key Nuances
A standard web application Pen-test or AWS cloud assessment will not automatically satisfy Amazon. Here’s why it’s different:
- Scope Must Be Explicitly SP-API-Centric
Generic tests often miss critical elements. Amazon expects coverage of:
● Specific SP-API endpoints your app uses
● OAuth 2.0 / Login with Amazon (LWA) flows, including token issuance, refresh, storage, and rotation
● Any backend logic that processes or stores Amazon data
● Exposed web interfaces that interact with the integration
- A plain “network scan” or broad web app test without this focus is usually rejected.
- Authentication & Data Flow Are Heavily Scrutinized
Because SP-API uses OAuth, testers must validate token handling, scope enforcement, and session management in depth. Weaknesses here (e.g., improper token storage or insufficient rotation) are high-risk in Amazon’s eyes. - The Report Itself Is Part of the Product
Amazon reviewers read the report manually. It must be clear, professional, and structured in a way that allows quick validation not just a raw tool output dump. - Independence Is Non-Negotiable
The testing team cannot be the same entity that built the application. This rule is enforced more strictly than in many other compliance frameworks. - Remediation Expectations Are Explicit
Amazon wants confirmation that critical and high findings are resolved (or formally accepted with justification). They may request retesting evidence or a follow-up attestation letter.
These nuances explain why a Pen-test that works perfectly for SOC 2 or ISO 27001 can still fail Amazon’s review.
Why Not Every Pen-test Vendor Is Suitable
Many capable security firms struggle with SP-API assessments for these reasons:
● Lack of Amazon-Specific Experience: They don’t understand the exact scope elements Amazon reviewer’s check.
● Report Format Mismatch: Their standard templates lack the executive summary, attestation language, or evidence structure Amazon expects.
● Over-Reliance on Automation: Tools like Nessus are useful but insufficient alone. Amazon demands manual testing focused on business logic and API-specific risks.
● No Gray-Box Expertise: Providing architecture details and credentials (gray-box) is the most efficient and effective approach, but not every team is comfortable or skilled at it.
● Freelancer or In-House Testing: Amazon often rejects these due to independence concerns.
The result? Wasted time, delayed approvals, and sometimes the need for a complete retest.
Core Requirements Amazon Actually Checks
Here’s what consistently passes review:
● Independent Third-Party → Separate legal entity, clear credentials.
● Comprehensive Scope → SP-API endpoints, OAuth/LWA, token handling, data processing systems.
● Professional Methodology → Manual testing referencing OWASP Top 10, OWASP API Security Top 10, and standards like PTES or NIST SP 800-115.
● High-Quality Report → Company details, tester qualifications, dates, scope, findings with evidence, severity ratings, remediation guidance, and a clear statement on residual risk.
● Risk Posture → No unresolved critical or high issues. Medium findings must be addressed or justified.
● Recency → Typically within the last 12 months (or after significant architectural changes).
Grey-box testing is particularly well-suited here. With access to architecture diagrams and test credentials, testers can focus on real risks rather than spending excessive time on reconnaissance.
Common Findings and How to Fix Them
Top 5 Issues That Delay Amazon Approval
1. Insecure Token Storage
Finding: "Refresh tokens stored in browser local Storage without encryption, accessible via XSS attacks."
Risk:
● Tokens accessible through cross-site scripting vulnerabilities
● Tokens persist across browser sessions
● Tokens readable by any JavaScript on the page
Fix:
Best practice:
● Store refresh tokens server-side only
● Never expose refresh tokens to client-side JavaScript
● Use httpOnly, secure cookies for session IDs
● Implement token encryption at rest
● Set appropriate token expiration
2. Insufficient Scope Validation
Finding: "Application does not validate OAuth scopes before accessing SP-API endpoints. Successfully retrieved order data using access token granted only product:read scope."
Risk:
● Privilege escalation beyond granted permissions
● Accessing restricted data without authorization
● Violation of least-privilege principle
Fix:
Best practice:
● Validate OAuth scopes before every SP-API call
● Enforce scope restrictions on backend (don't trust frontend)
● Log scope validation failures for monitoring
● Return appropriate 403 Forbidden responses
3. Token Leakage in Logs
Finding: "Access tokens and refresh tokens logged in application error logs, accessible to development team and log aggregation systems."
Risk:
● Credential exposure through log files
● Tokens accessible to anyone with log access
● Potential token theft from compromised logging systems
Fix:
Best practice:
● Implement token redaction in logging framework
● Never log full tokens (use token_id or last 4 characters)
● Secure log storage with appropriate access controls
● Regular log audits for accidental credential exposure
● Configure logging libraries to automatically redact sensitive patterns
4. Missing TLS Certificate Validation
Finding: "Application does not validate SSL/TLS certificates when calling SP-API endpoints, allowing potential man-in-the-middle attacks."
Risk:
● Credential interception through MITM attacks
● Data theft during transmission
● Compromise of Amazon seller/customer data
Fix:
Best practice:
● Always verify SSL/TLS certificates
● Never disable certificate validation in production
● Consider certificate pinning for SP-API endpoints
● Monitor certificate expiration
● Use up-to-date TLS versions (1.2+)
5. Inadequate Token Rotation
Finding: "Refresh tokens are not rotated on use. Single compromised refresh token remains valid for 180 days, extending the window for unauthorized access."
Risk:
● Prolonged credential validity increases compromise impact
● Stolen refresh tokens usable for months
● Difficulty detecting and responding to token theft
Fix:
Best practice:
● Rotate refresh tokens on every use
● Invalidate old tokens immediately after rotation
● Store only the current refresh token
● Implement token theft detection (multiple simultaneous refresh attempts)
● Log all token refresh events for security monitoring|
How to Prepare for a Successful SP-API Pen-test
- Document your SP-API integration architecture clearly (endpoints, data flows, authentication).
- Prepare test accounts with realistic permissions.
- Choose a provider experienced in both API security and AWS cloud assessments.
- Request a sample report upfront to verify it matches Amazon’s expectations.
- Plan for remediation time critical findings must be fixed before submission.
Final Thoughts
An SP-API penetration test is more than a security exercise; it’s a compliance artifact that Amazon reviewers will examine closely. Understanding its nuances and choosing the right testing partner can save months of back-and-forth.
At REDSECLABS, we’ve helped numerous clients navigate this exact process with grey-box assessments tailored to Amazon’s requirements, producing clear, professional reports and attestation letters that accelerate approval.
If you’re building or scaling an SP-API integration and want to discuss your specific setup, feel free to reach out. We’re happy to review your architecture or answer questions about scoping.
Contact: www.redseclabs.com | [email protected]
