The retail attack surface
Retail carries the most public attack surface of any sector. The storefront is built to be found, the APIs behind it are built to be fast, and the account layer is built to be easy. Each of those design goals is also an attacker's shortcut.
Modern commerce stacks widen it further. Headless front ends call a dozen internal services. Mobile apps and marketplace integrations consume the same APIs with different authentication. Third-party scripts execute inside pages that also collect payment details. Loyalty balances and gift cards hold value that can be stolen without a card number ever changing hands. Behind all of it, stores, distribution centres and back-of-house networks form an internal estate that head office rarely scans.
Testing a retail estate properly means covering all of that, not just the domain the marketing team remembers. Common findings include:
- Injection, cross-site scripting, SSRF and access-control flaws in storefront and admin surfaces.
- Broken object-level and function-level authorisation in order, account and pricing APIs.
- Weak authentication and account-recovery flows that make customer logins and loyalty balances easy to take over.
- Third-party and marketing scripts loaded into checkout journeys with more privilege than they need.
- Forgotten campaign microsites, staging environments and regional domains left running after a promotion ended.
- Store, warehouse and back-of-house networks with shared credentials and flat internal routing.
Change velocity: why annual testing fails retail
The platform you run in July is not the platform that was tested in March. Teams ship weekly, agencies push campaign sites in days, new partners arrive with new integrations, and the estate expands ahead of every major trading period. A point-in-time report ages out before the invoice is paid.
Then the code freeze lands. Between the freeze and the end of peak trading, the platform you cannot change is the one attackers are most interested in. Testing has to happen before the freeze, and monitoring has to continue through it.
PentestOps is priced per asset with unlimited scans within fair use, so re-testing after every significant release costs nothing extra. Scheduled scans and scan comparison show whether a fix actually landed. Asset re-verification every 7 days plus drift detection with a full change ledger catch new hosts and quiet changes, and Enterprise customers add continuous monitoring for real-time alerts on the perimeter between scheduled scans. That is the continuous testing model, and retail is the sector that needs it most.
PCI DSS v4.0 and the wider regulatory picture
If you store, process or transmit cardholder data, PCI DSS v4.0 drives the schedule. Requirement 11.4 sets the expectation for penetration testing of the cardholder data environment at defined intervals and after significant change, and v4.0 added explicit expectations around scripts loaded into payment pages and detecting unauthorised change to them.
Two honest caveats. PentestOps is not an Approved Scanning Vendor, so the quarterly external ASV scans that PCI DSS requires are a separate exercise. And no platform makes an organisation compliant: your QSA determines scope and validation. What PentestOps provides is technical testing, evidence, and findings already mapped to the frameworks your assessors work from.
Cards are not the whole story. The Australian Privacy Act and the Notifiable Data Breaches scheme apply to customer data whether or not a payment is involved, retailers selling into Europe carry GDPR obligations, and marketplace partners and enterprise buyers commonly ask for ISO 27001 or SMB1001 evidence. Reports map findings to 8 compliance reporting frameworks (OWASP Top 10, PCI DSS v4.0, NIST 800-53, SOC 2, HIPAA, GDPR, ISO 27001, SMB1001) plus CIS Benchmarks for AWS, Azure, GCP and Kubernetes. The mappings show where findings sit against each framework; they are not a certification of your environment.
Regulatory landscape
PCI DSS v4.0 is the instrument most retailers plan around, and its most consequential additions for eCommerce are about the browser rather than the server. Skimming attacks in the Magecart style do not breach your database. They inject or subvert a script already loaded into a payment page and read the card details as the shopper types them, which leaves the back end untouched and the theft invisible to server-side logging.
Requirements 6.4.3 and 11.6.1 exist for exactly that. The first expects you to know and justify every script that loads and executes in the consumer's browser on a payment page, and to assure its integrity. The second expects a change-and-tamper detection mechanism that alerts on unauthorised modification to the HTTP headers and content of payment pages as the browser receives them, evaluated on a defined schedule.
Read the table below as obligation to evidence. Testing supplies inputs and proof; the controls themselves remain yours to operate, and your QSA determines scope and validation.
| Obligation | What it asks of the retailer | Evidence testing can contribute |
|---|---|---|
| PCI DSS v4.0 requirement 11.4, penetration testing | Internal and external penetration testing at defined intervals and after significant change, with exploitable findings corrected and testing repeated | On-demand internal and external assessments, unlimited within fair use per asset, with scan comparison recording the retest result |
| PCI DSS v4.0 requirement 6.4.3, payment page scripts | An inventory of every script loaded and executed in the consumer's browser on a payment page, each with written justification and assured integrity | External and web application testing that shows which third-party scripts a checkout journey actually pulls in, as an input to the inventory you maintain |
| PCI DSS v4.0 requirement 11.6.1, tamper detection | A mechanism that alerts on unauthorised change to HTTP headers and payment page content as received by the browser, evaluated on a defined schedule | Drift detection and 7-day asset re-verification record change across in-scope assets. The payment page tamper detection mechanism is a separate control you operate |
| PCI DSS v4.0 quarterly external scanning | External vulnerability scans performed by an Approved Scanning Vendor and passing on a quarterly cycle | Not covered. PentestOps is not an Approved Scanning Vendor, so ASV scanning remains a separate exercise with a separate provider |
| Privacy Act 1988 and the Notifiable Data Breaches scheme | Reasonable steps to protect customer, loyalty and staff personal information, and prompt notification of eligible data breaches | Exploit-validated evidence of which paths to customer data are genuinely reachable, with a dated remediation history behind each fix |
What testing can and cannot settle
Testing surfaces the conditions that make client-side skimming possible: unnecessary third-party scripts in a checkout journey, cross-site scripting and access-control flaws that let an attacker introduce or alter one, weak administrative access to the content and tag management systems that publish them, and forgotten hosts serving the same code.
It does not stand in for the script inventory, the integrity assurance method or the tamper detection mechanism that 6.4.3 and 11.6.1 require you to run. Those are operational controls. PentestOps supplies technical evidence and findings already mapped to the frameworks your assessors work from; it does not make any organisation compliant.
How PentestOps maps to a retail programme
A retail engagement usually spans four surfaces: what shoppers touch, what their apps call, what the internet can still find, and what sits inside your sites.
| Asset | What gets tested | How it runs |
|---|---|---|
| Storefront and admin | Injection, XSS, SSRF, IDOR and authentication bypass against OWASP Top 10 risks, with a live finding stream | Agentless |
| Commerce and mobile APIs | REST and GraphQL endpoints against OWASP API Top 10 risks, including authorisation testing between roles | Agentless |
| Internet-facing estate | Campaign microsites, regional domains, staging leftovers and exposed services found by 24+ external recon modules | Agentless |
| Stores, DCs and back-of-house | Host and service discovery, credential testing and lateral movement validation via 18+ internal modules | On-premise agent |
| Cloud and Kubernetes | Identity, storage and network configuration against CIS Benchmarks; clusters audited via read-only kubeconfig | Agentless, read-only credentials |
Prioritised by what is actually reachable
Findings are correlated against the CVE database, scored with CVSS v3.1, flagged for known exploit availability and prioritised against CISA KEV, with false-positive reduction so the queue stays credible. Where safe exploitation is authorised under your Rules of Engagement, validated findings carry a full evidence trail, and scope enforcement automatically stops activity outside authorised assets.
Automation runs the repetitive, high-volume testing so your people can spend time on the creative work that automation handles poorly. Promotion and pricing logic abuse, for example, still rewards human review. The platform is built to shorten that list, not to replace the reviewer.
Typical use cases
- Harden before the freeze. Run a full assessment of the storefront, APIs and perimeter ahead of peak trading, then keep monitoring while the change window is shut.
- Test every significant release. Re-run web application testing and API testing after each deployment, and compare scans to confirm the fix held.
- Find the estate you forgot. Campaign microsites, regional domains and staging environments surface through external recon and attack surface management.
- Resist account takeover. Test authentication, session handling and account-recovery flows that protect customer profiles, saved payment tokens and loyalty balances.
- Baseline store networks. Put an agent in a representative store or distribution centre and see what back-of-house systems expose.
- Support assurance conversations. Share compliance-mapped reports with your QSA, acquiring bank or marketplace partner as supporting technical evidence.
Why retailers choose PentestOps
Retail security teams are small, the release train never stops, and the busiest weeks of the year are the ones you are least allowed to touch. The platform is built for that shape of work.
- Web, API, external, internal, cloud and identity testing in one subscription instead of separate tools and separate invoices.
- Asset-wise pricing: a hostname, web application, internal subnet target, cloud account or cluster is one asset, with unlimited scans within fair use. See pricing.
- Evidence over noise: CVSS v3.1 scoring, exploit availability, CISA KEV prioritisation and safe exploitation with proof attached.
- Store coverage without new firewall rules: the on-premise agent deploys in about five minutes and connects outbound only over TLS 443.
- Self-hosted AI by default, so scan data and the evidence it contains are analysed on infrastructure operated by Extranet Systems rather than sent to third-party model providers.
- Australian-built and operated. The platform is hosted in Australia, customer data is stored in Australia, and Extranet Systems Pty Ltd is ISO/IEC 27001:2022 certified.