All articles

Shopify app security / Developer guide

Shopify Asked for a VAPT Report: What Does That Mean?

A Shopify VAPT request means the notice is asking for vulnerability assessment and penetration-testing evidence, often from an independent third party. The exact scope and submission requirements come from your own notice. It does not mean every Shopify app has the same requirement, that a scanner export is sufficient or that passing a test guarantees relisting.

By Scantra SecurityUpdated 4 min read

Translate the request into concrete deliverables

Vulnerability assessment identifies and evaluates weaknesses; penetration testing validates exploitation and impact under agreed conditions. In a combined VAPT engagement, automated discovery may assist the work, but the final report should explain what was tested, what was confirmed and what could not be evaluated. The acronym alone does not define the coverage.

Read whether Shopify requested independence, a final report, remediation verification, an incident report or a timeline for delivery. Write these down separately. If the request does not specify the environment or report format, seek clarification rather than buying the smallest advertised package. A report for your company website may not cover the app backend that triggered the review.

Understand what an independent assessor contributes

An independent assessor provides testing evidence separate from the developer’s own assertions. Ask who conducts the work, what methodology they use and how they document validated findings. The provider should be able to explain scope boundaries, access requirements, risk ratings and how remediation questions will be handled without promising approval from Shopify.

Independence is not established merely by putting a vendor logo on a scanner output. Look for an identifiable testing organisation, assessment dates, authorized targets and a signed or attributable conclusion. If a potential conflict exists, disclose it. There is no basis here to claim that Shopify maintains a universal approved-vendor list or accepts every report carrying a particular certification.

Scope the app rather than only its homepage

A Shopify app often includes an embedded interface, backend APIs, job workers, databases, webhooks and services connecting to merchant resources. Map how a request becomes associated with a shop and what checks control access to each resource. Shopify’s security guidance highlights broken access control and tenant isolation as important app risks.

Consider installation and OAuth callbacks, access token protection, staff roles, billing workflows, file handling and sensitive actions. Select surfaces according to actual functionality. Provide authorized test stores and accounts for different roles and tenants. Explicitly exclude Shopify’s own infrastructure unless separate authorization exists; permission to test your app is not permission to attack the platform.

Keep the VAPT report separate from the Incident Report

The Incident Report explains the known incident timeline, impact, investigation, containment and response. The VAPT report describes scoped testing and security findings. A penetration test conducted after a patch does not prove whether data was accessed before the patch. Conversely, a well-written incident timeline does not demonstrate the absence of other exploitable weaknesses.

If both reports were requested, coordinate them without merging their conclusions. Use consistent asset names, dates and finding references. Explain when an incident weakness overlaps with a VAPT finding and when it does not. State that a conclusion is unknown if evidence is missing. This is more credible than retrofitting a test result into an unsupported incident narrative.

Agree the finish line before work starts

Confirm whether the deliverable includes initial findings, developer clarification, remediation verification and a final report. Define what happens when a finding remains open, when access is incomplete or when the app changes during testing. A final report should not silently remove unresolved risks to make the submission look clean.

Prepare your acknowledgement and a realistic timeline for Shopify while the engagement is arranged. Share the notice securely with the assessor and avoid posting confidential evidence into marketing forms. Scantra’s notice intake is a starting point for triage and scope, not instant incident response. Shopify decides whether the evidence satisfies its own governance review.

Questions to put in the assessment brief

Before accepting a proposal, ask the provider to identify which app components, roles and tenants it will assess; how manual validation differs from scanning; which environments and versions it needs; how urgent findings are escalated; and which final reports and verification steps are included. Put the answers beside the wording of Shopify’s request. Any mismatch is a scoping question to resolve before testing, not an assumption to hide until submission. Also ask how unresolved findings, incomplete access and a changed deployment will be reported. Keep the brief factual: a vendor can commit to agreed work and deliverables, but it cannot commit Shopify to approval. Review the brief with the engineering owner so access and dependencies are actually available when the assessment begins.

Your working checklist

  • Identify the exact report requested.
  • Confirm third-party independence requirements.
  • List backend domains, APIs and app workflows.
  • Prepare authorized tenants and role-based accounts.
  • Agree reporting, retesting and exclusions.
  • Keep incident conclusions evidence-based.
  • Record remaining risks in the final package.
  • Ask Shopify to clarify ambiguous requirements.

Sources and scope of this guidance

Platform requirements below come from Shopify’s documentation. Response trackers and checklists are Scantra’s practical guidance, not an official Shopify workflow. Review current requirements and your own notice; this is not legal advice or an acceptance guarantee.

Where mentioned, the past relisting example is based on anonymised owner-supplied correspondence published with permission. Private client identities and incident evidence are not reproduced.