For online retailers, marketplaces, direct-to-consumer brands, and retailers running stores, loyalty schemes and click-and-collect
Online shops are attacked through skimming scripts on checkout pages, account takeover for loyalty points and saved cards, bots that hoard stock and abuse promotions, and the plugins and third-party scripts every shop runs. We test the storefront, the checkout and the systems behind them as an attacker who wants to cash out would.
A skimmer on a checkout page copies card data from every customer until someone notices, and the warning often comes from a card scheme or a bank rather than from your own monitoring. Account takeover drains loyalty balances and gift cards that customers treat as money. Bot traffic and promotion abuse rarely make headlines but steadily eat margin. The bill arrives as a forensic investigation the card schemes can require, chargebacks, customer refunds and, in the worst cases, the loss of the right to take cards at all.
Malicious JavaScript injected into a checkout page, a tag manager or a compromised third-party script copies card details as customers type them. The page keeps working, so nothing looks wrong. PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 were written for this pattern.
Passwords stolen in other breaches are replayed against your website, app and API logins. Accounts holding loyalty balances, gift cards or saved payment methods are cashed out quickly, often after the attacker changes the account's email address.
Commerce platforms such as Magento, WooCommerce and PrestaShop run on extensions from many authors. One unpatched plugin with an injection or file-upload flaw is enough to plant a skimmer or a web shell.
Stacked discount codes, negative quantities, price changes between basket and payment, and refunds for items that were never returned. These flaws cost money directly, and no scanner reports them.
Automated traffic hoards limited stock, scrapes prices, opens fake accounts for sign-up offers and tests stolen cards at checkout. Rate limits and behaviour checks belong where the money moves, not only at login.
Order confirmations, delivery tracking pages and mobile APIs that use sequential identifiers show customer names, addresses and purchase histories to anyone who changes the number.
On a payment page, PCI DSS 4.0.1 requirement 6.4.3 asks for every script to be authorised, justified and checked for integrity, and 11.6.1 asks for unauthorised changes to the page to be detected. Requirement 11.4 adds penetration tests at least every 12 months for systems in scope, and 11.3.2 quarterly external scans by an Approved Scanning Vendor. Online marketplaces are among NIS2's other critical sectors, alongside search engines and social networks. Customer databases fall under GDPR's 72-hour breach notification in Europe and, in Israel, under the Data Security Regulations, to which Amendment 13 has attached monetary sanctions since 14 August 2025; the first, in July 2026, was NIS 256,000 for a severe incident reported about two months late.
The scoping call settles which of these apply to your systems.
A review of a public website's TLS and security headers, third-party scripts, CMS and plugin versions, forms, authentication and hosting configuration. Every check is marked pass, fail or not applicable with the evidence attached, so the result doubles as a compliance artefact.
Duration: 3 to 6 working days
Authenticated, role-aware testing of your application and its API surface, with an account for every role. We chain small findings into the access they lead to, such as a sequential invoice ID and a missing tenant check that together let one customer read another's invoices.
Duration: 5 to 10 working days
iOS and Android testing of the binary, on-device storage and transport, and of the backend API the app calls, replaying the app's own tokens to check whether one user can read another's data. On the device we check what the keychain or keystore stores, whether certificate pinning survives a bypass attempt and what deep links can trigger.
Duration: 6 to 10 working days
An IAM-first review of AWS, Azure or GCP. We map what an attacker reaches after compromising one workload or one developer laptop, then rank those paths by the data at the end of each and write the Terraform or policy change that cuts it.
Duration: 4 to 8 working days
Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.
Duration: Live incidents until recovery is verified; readiness work in days
The website security audit checks the storefront control by control (TLS, headers, every script on the payment page, CMS and plugin versions, forms and hosting) with evidence for each result. A penetration test attacks the shop: account takeover, cart and refund logic, and the path from a plugin flaw to a skimmer. Shops that take card payments on their own pages often need both, and the audit is the faster place to start.
Yes. A script injected into your own page can replace the provider's form with a fake one, overlay it or send the customer elsewhere before they reach it. The audit checks how the form is embedded, what else runs on that page and whether a change to it would be noticed.
You can, but it is rarely worth the risk. Testing windows are agreed in the rules of engagement, and for retailers that usually means avoiding sale periods and running anything load-sensitive against staging. If a release before peak is the reason for the test, book the scoping call early so the work finishes before your change freeze.
We pick the checks that apply to your systems and the frameworks you answer to. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.