E-commerce Cybersecurity
CERT-In empanelled cybersecurity services for E-commerce organisations. 6,700+ assessments delivered since 2006.
Challenges
Security challenges in E-commerce
PCI DSS v4.0 compliance for payment-card processing across web, mobile, and API channels
Customer PII at scale — millions of profiles, purchase histories, and payment instruments
Account takeover and credential-stuffing attacks targeting consumer accounts
Third-party marketplace seller integration and supply-chain API security
Seasonal traffic spikes that make security testing windows narrow and critical
Fraud detection across orders, returns, loyalty points, and gift card abuse
Trusted by
The requirement
No regulator supervises a merchant. Your acquirer does.
Retailers selling online often expect to find a supervisory instrument with their name on it, and there is not one. What binds an e-commerce business is the contract with its acquiring bank and payment partners, which passes the card-scheme rules down as a term of doing business. That is a harder constraint than it sounds, not a softer one: a supervisor issues findings and a timetable, whereas an acquirer can decline to process, and there is no appeal to a regulator. The practical consequence is that the security requirements arrive as a compliance level assigned by transaction volume, an annual validation, and a set of scanning obligations — from a counterparty whose incentive is its own exposure rather than your improvement. Read the contract before scoping any assessment, because it is the document that decides what has to be evidenced and how often.
The estate
The store is the smallest part of the surface
Almost everything that has to hold is code somebody else wrote, running in your customer's browser or on your behalf.
The checkout, and everything loaded next to it
Analytics, tag managers, chat widgets, personalisation, A/B tooling — each one executing in the same page as the card form, each one able to read it, and most of them updatable by their vendor without telling you.
The mobile applications
Shipped artefacts anyone can pull apart offline, frequently holding keys that were only ever meant to reach your own backend.
Promotions and pricing logic
Coupons, loyalty balances, referral credits and cart rules. This is business-logic territory, where the flaw is not a broken control but a sequence of legitimate requests that produces an illegitimate price.
Marketplace and channel listings
Your catalogue on somebody else's platform, with credentials into your inventory and pricing. The account is yours to protect; the platform is not yours to test.
Fulfilment and logistics integrations
Address, contact and order data flowing to couriers and warehouses over interfaces built for throughput. Frequently the least-authenticated thing in the estate.
Returns, refunds and support tooling
The internal side, where a support agent can alter an order, issue a credit or read a customer record. It is the money path that is not the checkout, and it is rarely in scope.
The data
Following the card number to where it actually rests
Most merchants can describe the intended path. The assessment is about the copies nobody intended.
-
Entry
The browser, and whatever else is in it
If the form is yours rather than the processor's, every script on the page is inside the cardholder data environment whether or not the diagram says so. Establishing which scripts load, from where, and who can change them is the first question.
-
Transit
The hop to the processor
Usually the best-understood part, and rarely where the problem is. Worth confirming that the fallback path — the one used when the primary processor is unavailable — is held to the same standard as the primary.
-
Rest
The copies made for operational reasons
Logs, error captures, session replay, support tickets, fraud-review queues and analytics events. Card data reaches all of these by accident, and the accident is a configuration default more often than a bug.
-
Exit
Reconciliation, exports and the finance team
Settlement files, chargeback workflows and the spreadsheets built around them. This is where cardholder data leaves the systems designed to hold it and enters systems designed for convenience.
What we test
The questions a scanner cannot answer
An automated scan validates configuration. These need somebody to reason about intent.
| Question | Why it is worth the manual effort |
|---|---|
| Can the price be changed between cart and capture? | Every step between selecting an item and charging for it is an opportunity to substitute a value the server trusts. Discount stacking, currency handling and partial refunds are where this concentrates, and none of it looks like an attack in a log. |
| What can one customer account reach? | Order history, saved addresses, stored payment tokens and returns belong to an account, and the check that an object belongs to the caller is applied per endpoint rather than centrally. Missing it once exposes every customer. |
| Who can change what runs in the checkout page? | A third-party script is a code deployment into your most sensitive page, performed by a vendor, outside your release process. The control is inventory plus integrity checking, and the test is whether either exists. |
| Does the support tooling enforce the same rules? | Internal interfaces are built for staff who are assumed to be trusted, and they can usually do more to an order than the customer can. If one is reachable with a stolen agent credential, the customer-facing controls stop mattering. |
Can the price be changed between cart and capture?
- Why it is worth the manual effort
- Every step between selecting an item and charging for it is an opportunity to substitute a value the server trusts. Discount stacking, currency handling and partial refunds are where this concentrates, and none of it looks like an attack in a log.
What can one customer account reach?
- Why it is worth the manual effort
- Order history, saved addresses, stored payment tokens and returns belong to an account, and the check that an object belongs to the caller is applied per endpoint rather than centrally. Missing it once exposes every customer.
Who can change what runs in the checkout page?
- Why it is worth the manual effort
- A third-party script is a code deployment into your most sensitive page, performed by a vendor, outside your release process. The control is inventory plus integrity checking, and the test is whether either exists.
Does the support tooling enforce the same rules?
- Why it is worth the manual effort
- Internal interfaces are built for staff who are assumed to be trusted, and they can usually do more to an order than the customer can. If one is reachable with a stolen agent credential, the customer-facing controls stop mattering.
Services
Recommended Services for E-Commerce
PCI DSS and data protection security for online retail
Web Application Penetration Testing
Security testing for e-commerce storefronts, cart/checkout flows, customer accounts, and admin panels.
Learn More →API Security Testing
Testing for payment gateway integrations, shipping/logistics APIs, inventory sync, and third-party marketplace connectors.
Learn More →PCI DSS Compliance
PCI DSS v4.0 compliance — SAQ or ROC, ASV scanning, CDE scoping, and remediation for cardholder data environments.
Learn More →Cloud Security Assessment
Security posture review for e-commerce hosting, CDN, WAF configuration, and cloud-native checkout infrastructure.
Learn More →Red Team Assessment
Adversary simulation targeting payment fraud, account takeover, gift card abuse, and loyalty program manipulation.
Learn More →Compliance
Frameworks that matter to E-commerce
Frequently Asked Questions
Our payment provider handles the card data. Are we out of scope?
Partly, and the boundary is worth establishing precisely rather than assuming. A hosted field or redirect genuinely removes the card number from your systems — but only if nothing on your page can read it, which means the scripts sharing that page are in scope even when the card data is not. The order, the customer record and the refund path stay yours regardless, and those are where most of the findings on a merchant assessment are.
We are small. Does any of this apply at our volume?
The validation burden scales with transaction volume; the attack does not. Automated card-skimming targets the script surface rather than the brand, and it finds small merchants because they run the same third-party tooling as large ones with fewer people watching it. The proportionate answer is usually a scoped application test plus a hard look at what loads in the checkout, rather than the full programme a large retailer runs.
Secure Your E-commerce Organisation
One scoping call to align on scope, methodology, and timing.
Request a Scoping Call →