Security Testing for UAE Retail & E-commerce

A retailer in the UAE is expected to test against PCI DSS wherever card data is handled, the DESC ISR for Dubai government-linked entities and their suppliers, and the UAE consumer-protection and personal-data rules that govern how customer information is collected and held.

PCI DSS

Any environment that stores, processes or transmits cardholder data needs testing at defined intervals and after significant change. For a retailer that reaches the storefront, the checkout, the payment integration and the point-of-sale estate, so scoping and segmentation decide the cost more than anything else.

DESC

Dubai government-linked entities and the suppliers that serve them fall under the DESC Information Security Regulation. We scope and report so the evidence maps to it rather than leaving you to translate a generic test afterwards.

UAE consumer-data rules

The order history, loyalty profile and payment token you hold for a customer are personal data under UAE law. We test the controls that keep one customer's record out of another customer's reach, which is where the serious findings sit.

A storefront and checkout pentest covers authorisation at the object and function level, the discount and pricing logic, the cart and order flow, and the handover to the payment provider, because that is where an attacker reaches another customer's data or pays less than the basket is worth.

The most common high-severity finding we report on retail APIs is broken object level authorisation: changing an identifier in a request and receiving an order, an address or an account that belongs to someone else. A scanner cannot reason about it, so it is tested by hand, per role and per resource.

We also test the business logic that a scanner never sees: stacking expired vouchers, re-pricing an item in the cart, replaying a payment callback, or completing an order that the payment never cleared.

Point-of-sale and in-store testing is agreed in writing first, denial-of-service techniques are excluded by default, and the rules of engagement fix the testing window, the excluded techniques and a deconfliction contact before any work starts, so a till is never taken down during trading hours.

Where a test case would create real transactions or move real stock, it runs against a lab or production-equivalent terminal instead. Where that environment differs materially from the shop floor, the report says so, because a test of a different configuration is a test of a different system.

The POS estate is scoped alongside the store network and the back-office systems it talks to, because an attacker who reaches one till is usually after the flat network behind it.

Yes. A modern storefront runs on extensions: payment gateways, tag managers, review widgets, shipping and loyalty plugins. Each one runs in your customer's browser or on your server, and a weakness in any of them is a weakness in your checkout.

We test the integration as it is deployed, not as the vendor documents it, because a plugin configured with excess permissions or an exposed webhook is a common way into an otherwise sound store. Where a finding belongs to a third party, we set it out so you can take it to them with evidence.

Omnichannel retail is tested as one system, because a customer who orders online, collects in store and returns through the app is served by shared accounts, shared loyalty balances and shared payment tokens. A control enforced in one channel is not always enforced in another, and an attacker uses the weakest.

We scope the web storefront, the mobile shopping app and the in-store and point-of-sale systems against the same customer identity, and we check that loyalty points, stored cards and order history cannot be reached or redeemed from a channel that should not allow it.

Most retailers start with a web and API pentest of the storefront and checkout, add a mobile app pentest for the shopping app, and run an infrastructure pentest across the store networks and point-of-sale estate. An objective-based Red Team and a social engineering test follow once the basics are covered.

The right mix depends on what you are protecting and what a standard such as PCI DSS has asked for. We scope it with you rather than selling a fixed bundle, and we say where something is not worth buying yet.

The deliverable is an evidence chain, not a score. Every engagement starts from a signed NDA and written rules of engagement, and it is run by named, vetted operators you can reach directly. The report sets out the scope, the authorisation, each finding with its severity and the owner who has to fix it, the order to remediate in, and a retest that confirms closure with evidence.

Findings are mapped to MITRE ATT&CK, so a technique we used against your checkout or your store network reads the same way to your defenders as it did to us, rather than sitting in a private vocabulary.

The retest is priced at scoping, not sold afterwards, so closing a finding does not open a new negotiation. When a board or a procurement team asks whether the testing happened, we provide an attestation of the work done and the scope it covered, which is the document most retailers hand to a partner or a payment provider.