Retail Security Testing.
Zero Checkout Disruption.
End-to-end security testing across the entire retail attack surface — e-commerce applications, mobile commerce, point-of-sale infrastructure, loyalty and account security, supply chain integrations, and PCI DSS cardholder data environments — with regulatory mapping for PCI DSS v4.0, GDPR, and regional frameworks.
Magecart detection
6 retail attack surfaces
POS & XFS security
Supply chain assessment
Retail : High Volume, High Value, Constantly Exposed.
Retailers process more card transactions than any other sector and operate customer-facing systems around the clock with minimal maintenance windows — making them a sustained target for Magecart skimming campaigns, credential stuffing, and ransomware groups seeking operational disruption leverage.
Four Constraints That Define Retail Security Testing.
Always-On Revenue Systems
E-commerce platforms and POS networks process revenue 24 hours a day. Black Friday and peak trading periods require complete freeze on testing. Even during off-peak windows, checkout availability is monitored in real time and any degradation triggers immediate escalation. Testing must be precisely scoped to avoid any interaction with live payment processing flows.
PCI DSS Cardholder Data Scope Complexity
The Cardholder Data Environment in a multi-channel retailer typically spans in-store POS networks, e-commerce checkout flows, call centre systems, mobile applications, and back-office reconciliation platforms. Correctly defining and validating the CDE boundary — and demonstrating network segmentation between CDE and out-of-scope systems — is one of the most technically complex elements of PCI DSS v4.0 compliance.
Extensive Third-Party Attack Surface
Modern retail environments depend on dozens of third-party integrations: payment service providers, loyalty programme platforms, delivery and fulfilment APIs, marketing automation tools, analytics scripts, and CDN providers. Each integration is a potential supply chain attack vector, and the security controls applied at third-party boundaries are frequently inconsistent or unmonitored.
High-Volume Customer Account Ecosystem
Retail loyalty programmes and customer accounts represent high-value targets for credential stuffing and account takeover campaigns. A compromised loyalty account yields stored payment methods, purchase history, redeemable points balances, and personally identifiable data — making these accounts commercially attractive to fraud ecosystems that sell account access at scale.
Six Retail Layers. Tested End to End.
Select a layer to see what gets tested, how, and which regulatory obligation applies.
E-Commerce Applications
Magento · Shopify Plus · Salesforce Commerce Cloud · Custom checkout flows · Open Banking / buy-now-pay-later integrations
- Magecart and JavaScript supply chain attack detection: Content Security Policy enforcement, subresource integrity validation on all payment-page script loads, and baseline monitoring for unexpected script changes
- Checkout flow business logic testing: price manipulation, coupon stacking, negative quantity exploitation, and order total manipulation before payment capture
- Authentication and account takeover: brute-force protection, OTP replay, password reset flow security, and concurrent session policy for customer accounts
- Broken Object-Level Authorisation in order and wishlist APIs: whether order IDs permit enumeration of other customers’ purchase history and delivery addresses
- Admin panel exposure and access control: whether back-office product management, customer data, and order fulfilment interfaces are reachable without VPN and enforce MFA
- API security for headless commerce architectures: GraphQL depth and breadth limiting, introspection exposure, field-level authorisation on customer data queries
CRITICAL
Magecart-Style Script Injection via Compromised Tag Manager
PCI DSS v4.0 Req 11.6.1
GDPR Art. 32
An obfuscated skimming payload served through a compromised tag manager container was identified harvesting card data from the checkout form before submission. No Content Security Policy was configured to restrict third-party script execution. PCI DSS v4.0 Requirements 6.4.3 (payment page script management) and 11.6.1 (change and tamper detection) both unmet.
Mobile Commerce Applications
iOS retail apps · Android retail apps · Scan-and-Go · Mobile wallet integrations · In-store mobile payment
- Binary protection assessment: code obfuscation effectiveness, root and jailbreak detection bypass, anti-tampering control validation using dynamic instrumentation
- Local data storage security: payment method tokens, loyalty card data, and personally identifiable data stored in SQLite, NSUserDefaults, SharedPreferences, and application cache directories
- Network traffic security: TLS certificate validation, certificate pinning implementation, and susceptibility to proxy-based interception of API traffic
- Scan-and-Go business logic: SKU manipulation, price override via modified barcode scan, and QR code injection in self-checkout flows
- Deep link and intent handling: whether malicious applications can invoke payment flows, pre-fill delivery addresses, or trigger account modifications via exposed deep link handlers
- Mobile API surface: whether the mobile API enforces the same authorisation controls as the web application, or presents a wider attack surface due to reduced rate limiting or client-side trust assumptions
HIGH
Payment Tokens Stored Unencrypted in Android SharedPreferences
GDPR Art. 32
Payment vault tokens and customer email addresses persisted in unencrypted XML on device storage accessible to backup tools, rooted devices, or any application with storage access permission. Tokens remained valid after application uninstall. 1.4 million active app installs exposed to potential credential extraction without device compromise.
Point-of-Sale & Kiosk Infrastructure
Verifone · Ingenico · Windows POS terminals · Self-checkout kiosks · XFS/CEN middleware · Store network infrastructure
- POS terminal network segmentation: whether the in-store POS VLAN is isolated from corporate IT, staff devices, guest WiFi, and warehouse management networks
- XFS (eXtensions for Financial Services) middleware security: whether CEN/XFS interfaces on payment terminals expose card reader and PIN entry device management functions to unauthorised applications
- Default credential exposure on POS management consoles, back-office servers, and store network switches
- POS application integrity: whether software signing, application whitelisting, and anti-tampering controls prevent unauthorised code execution on terminal devices
- Remote access security for POS estate management: assessment of the remote management platform used for POS fleet updates and configuration, including VPN requirements and MFA enforcement
- Self-checkout kiosk breakout: testing whether kiosk lockdown configuration can be bypassed to reach underlying operating system, browser, or network functions
CRITICAL
POS Network Reachable from In-Store Guest WiFi
PCI DSS v4.0 Req 4.2.1
Wireless guest network routes directly to the POS payment processing subnet without any firewall or ACL restriction. A customer device connected to in-store guest WiFi could directly reach POS terminals and the in-store payment server. PCI DSS v4.0 Requirement 1.3.3 mandates that wireless networks are isolated from the CDE. Network segmentation test failed across all 340 tested store locations.
Loyalty Programmes & Customer Account Security
Loyalty platform APIs · Customer account portals · Points redemption systems · Referral & voucher systems
- Credential stuffing resilience: whether the customer account portal detects and blocks high-volume automated login attempts using leaked credential datasets
- Account takeover via password reset: reset token entropy, time-limited validity, whether active sessions are invalidated on password change, and email domain spoofing susceptibility
- Loyalty point manipulation: whether point balances, tier status, and voucher availability can be manipulated via API parameter tampering or race conditions in redemption flows
- Stored payment method exposure: whether saved card data (or tokens) is accessible via account API endpoints beyond the use case for which it was stored
- Bulk account enumeration: whether username existence can be determined via timing differences, error message variation, or HTTP status code differentiation in login and password reset flows
- Referral and voucher programme abuse: testing for business logic weaknesses that allow unlimited voucher generation, self-referral loops, or referral credit without genuine new customer acquisition
HIGH
No Rate Limiting on Customer Login — Credential Stuffing Unrestricted
PCI DSS v4.0 Req 8.3.4
Authentication endpoint accepts unlimited login attempts from a single IP address without rate limiting, CAPTCHA, or account lockout. An automated credential stuffing attack using a 50,000-record leaked credential set was simulated at 1,000 requests per minute for 50 minutes without triggering any detection or blocking mechanism. 8.3 million registered loyalty accounts exposed.
Supply Chain & Third-Party Integrations
Payment service providers · Delivery / fulfilment APIs · CDN providers · Analytics platforms · ERP integrations · Franchise partner networks
- Third-party script inventory and risk classification: identifying all third-party JavaScript loaded on checkout and account pages, with security classification and change monitoring status for each
- API integration security: authentication mechanisms (API key vs. OAuth vs. mutual TLS), authorisation scope, and rate limiting on integrations with fulfilment, warehouse, and logistics providers
- Franchise and partner network access controls: whether franchise partners sharing the e-commerce platform or loyalty system are correctly isolated and limited to their own data scope
- EDI and ERP integration security: validation of Electronic Data Interchange connections to supplier and logistics systems, including B2B portal access controls and message authentication
- CDN and edge security configuration: cache poisoning susceptibility, origin server exposure via direct IP access bypass, and web application firewall bypass techniques at the edge layer
- Supplier portal access control: whether supplier-facing portals expose purchase order data, inventory levels, or customer demand forecasts beyond what a specific supplier requires
HIGH
Origin Server Directly Accessible — CDN WAF Bypass
GDPR Art. 32
Origin server IP was identified through historical DNS records. Direct requests to the origin bypassed all CDN-based security controls — web application firewall, DDoS mitigation, bot management, and geo-blocking — allowing unrestricted access to the full e-commerce application without rate limiting. All WAF rules protecting the checkout and account API endpoints were effectively nullified.
PCI DSS v4.0 Compliance & Evidence Delivery
QSA-ready reporting · SAQ support · Network segmentation documentation · Scope validation artefacts
- CDE boundary validation: active discovery of systems storing, processing, or transmitting cardholder data outside the defined scope — including log aggregation systems, monitoring tools, and backup infrastructure
- Network segmentation penetration test per PCI DSS v4.0 Requirement 11.4.5: active path testing from out-of-scope systems to CDE systems to demonstrate isolation effectiveness
- E-commerce specific requirements: CSP enforcement (Req 6.4.3), payment page script integrity monitoring (Req 11.6.1), and open redirect prevention (Req 6.2.4)
- Authenticated vulnerability scan of all CDE-facing systems per Requirement 11.3.1: CVSS scoring, vendor patch status, and remediation prioritisation
- QSA-aligned penetration test report structure: methodology documentation, scope statement, finding narratives with specific requirement references, and re-test verification records
- SAQ-D and ROC supporting evidence: technical artefacts mapped to each testable control to reduce the documentation burden on internal compliance teams during QSA assessment
REPORT
Segmentation Test Report — PCI DSS v4.0 Req 11.4.5
PCI DSS v4.0 Req 1.3.2
Segmentation test report documents active traffic path testing from guest WiFi, corporate LAN, supplier portal, staff device VLAN, warehouse management network, and DR environment — confirming which segments are isolated and which require remediation. Each test includes source network, destination target, protocol tested, result (pass/fail), and supporting network capture evidence.
Every Finding Referenced Against Your Specific Obligation.
Retail security assessments map findings to the specific control section — not just the regulation — to support QSA engagements, internal audit, and board reporting.
Global
Version 4.0 became mandatory in March 2025. Key changes affecting retail include: Requirement 6.4.3 (management of all payment page scripts with authorised list, integrity verification, and justification); Requirement 11.6.1 (change and tamper detection for payment page HTTP headers and scripts); and Requirement 12.3.2 (targeted risk analysis for customised approach). The penetration testing requirement (11.4) now explicitly requires segmentation test evidence to be included in the annual assessment.
European Union
GDPR Article 32 requires retailers to implement appropriate technical and organisational measures to ensure security appropriate to the risk — including pseudonymisation, encryption, resilience, and regular testing. Retail breaches involving EU customer data trigger 72-hour notification obligations. Where loyalty programme data involves behavioural profiling, Article 22 automated decision-making provisions and DPIA requirements may also apply.
California
The California Consumer Privacy Act and California Privacy Rights Act apply to retailers processing personal information of California residents. Retailers meeting CPRA thresholds must implement reasonable security procedures appropriate to the nature of the data. Security assessments for businesses that share or sell sensitive personal information (which includes payment data and precise geolocation from mobile apps) are required under CPRA regulations effective 2023.
UAE
Retailers operating in the UAE must comply with Federal Decree-Law No. 44 of 2023 on Consumer Protection, which includes obligations around the security of consumer personal and financial data. The Central Bank of UAE’s payment security guidelines apply to retailers accepting card payments in the UAE market, and are aligned with PCI DSS requirements for payment card acceptance environments.
European Union
Large retailers meeting NIS2 Directive thresholds (as entities in the digital infrastructure or ICT service management sector) face obligations under Article 21 including risk management, supply chain security, encryption, access control, and incident handling. Retailers operating e-commerce platforms at scale may be classified as significant entities under national transpositions, triggering mandatory security measure implementation and incident reporting obligations.
Global
ISO 27001:2022 Annex A includes 93 controls across 4 themes — organisational, people, physical, and technological. Retail-relevant controls include A.8.9 (configuration management), A.8.23 (web filtering), A.8.25 (secure development lifecycle), A.8.29 (security testing in development and acceptance), and A.8.30 (outsourced development). Penetration testing findings provide direct evidence for Clause 9.1 performance evaluation and Clause 10.1 continual improvement.
Zero Checkout Disruption. PCI-Ready Evidence.
Trading-Window Aware Scheduling
All testing is scheduled around your trading calendar — avoiding peak trading days, promotional event windows, end-of-month processing, and payment settlement cycles. Active testing against checkout and payment infrastructure requires explicit written approval and includes a documented stop protocol. Store network testing is coordinated with regional IT and store operations teams to prevent any impact on trading. We do not test e-commerce checkout flows during peak hours without explicit CISO authorisation.
Cardholder Data Pattern Awareness
Test tooling is configured to detect and flag cardholder data patterns including PAN formats across all major card networks, CVV structures, and track data. Any intercepted or captured data matching cardholder data patterns is immediately anonymised before being written to test artefacts. Cardholder data is never retained in penetration test reports, tool outputs, or logs. All test environments use synthetic card numbers in approved test BIN ranges where interaction with live payment flows is required.
QSA-Aligned PCI DSS Reporting
Reports are structured for direct use by your QSA in the annual PCI DSS assessment — not generic pen test documents requiring manual mapping. Each finding cites the specific Requirement number. Segmentation test evidence is produced as a standalone document per Requirement 11.4.5. Script inventory documentation and payment page integrity evidence is produced per Requirements 6.4.3 and 11.6.1. Re-test verification records are included for all critical and high severity findings as standard.