Cybersecurity for E-commerce Businesses in India
Most Indian e-commerce breaches we investigate do not start at the payment gateway. They start at a forgotten staging server, an admin panel with a default password, or an order-lookup API that returns any customer's address if you just change the order ID in the URL. The gateway is the one part everybody hardens. The rest is where you actually bleed.
If you run an online store in India and you think a PCI DSS certificate from your payment processor covers you, this article is written for you. It does not. Your customers' phone numbers, delivery addresses, order history and saved cards live in your systems, on your APIs, and now under a law that can fine you up to two hundred and fifty crore rupees per instance. Let us walk through what an auditor actually looks for.
Where e-commerce security actually breaks
E-commerce is unusual because you are stitching together a dozen third parties in real time: a payment gateway, a shipping aggregator, an SMS/OTP provider, a marketing platform, a review widget, an analytics pixel. Every one of them is a door. The customer sees a checkout button; you are running a distributed system that leaks at the seams.
When we scope a VAPT (Vulnerability Assessment and Penetration Test) for an online retailer, the same four failure classes show up again and again, regardless of whether the store does two crore or two hundred crore in annual GMV.
The four gaps that sink e-commerce audits
- Broken object-level authorisation on APIs — the classic /api/orders/10231 where changing the number shows you someone else's order. The Open Web Application Security Project ranks this (BOLA/IDOR) as the number one API risk, and it is the single most common finding we file against Indian storefronts.
- Card and PII handling outside the certified boundary — a store thinks it is out of scope because it uses a hosted gateway, but its own frontend JavaScript touches card fields, or its CRM stores full card numbers pulled back from the gateway for reconciliation.
- Unpatched and unhardened infrastructure — admin panels (WordPress/Magento/custom) exposed to the internet, old plugin versions, default credentials, and staging environments with production data.
- No breach detection — logs are either not collected or nobody reads them. The average time to even notice a card-skimming script (Magecart) on a checkout page is measured in weeks, not minutes.
The three regimes you are actually accountable to
Indian e-commerce sits at the intersection of three separate rulebooks. They overlap, but each has a different owner, a different trigger, and a different penalty. Confusing them is how compliance budgets get spent on the wrong control.
| Regime | What it governs | Who enforces it | What triggers it |
|---|---|---|---|
| PCI DSS v4.0.1 | How you handle, transmit and store cardholder data | Card networks via your acquiring bank | Any card transaction — you inherit scope the moment cards touch your flow |
| DPDP Act, 2023 | Processing of any personal data of Indian customers | Data Protection Board of India | Collecting name, phone, address, email — i.e. every order you ship |
| CERT-In Directions (2022) + IT Rules | Incident reporting, log retention, security posture | CERT-In (under MeitY) | Operating any internet-facing service serving Indian users |
PCI DSS: what QSAs actually check on a store
PCI DSS (the Payment Card Industry Data Security Standard) does not care how big you are; it cares how cards flow. The March 2024 move to v4.0.1 made two requirements especially painful for e-commerce, and both became mandatory from 31 March 2025.
- Requirement 6.4.3 — you must inventory and justify every script that runs on your payment page, and confirm each has not been tampered with. This exists precisely because of Magecart card skimmers injected through a compromised third-party widget.
- Requirement 11.6.1 — you must deploy a change-and-tamper detection mechanism on the payment page that alerts on unauthorised modification of HTTP headers and page content, checked at least weekly.
- Requirement 8.3.6 — minimum twelve-character passwords, up from seven, for all in-scope access.
- Requirement 8.4.2 / 8.5.1 — multi-factor authentication for all access into the cardholder data environment, not just remote/admin access.
The other thing QSAs check is which Self-Assessment Questionnaire (SAQ) you are eligible for, because most merchants quietly claim the wrong one. If any part of your own site handles the card data element — even collecting it and posting to the gateway — you are not eligible for the easy SAQ A. You need SAQ A-EP, which is roughly four times the number of requirements. We see this misclassification on the majority of first-time assessments.
| SAQ type | When it applies | Rough requirement count |
|---|---|---|
| SAQ A | Fully outsourced — an iframe or redirect from the gateway; your page never touches card data | ~30 controls |
| SAQ A-EP | Your site handles the payment page but does not store card data (e.g. a JavaScript that posts to the gateway) | ~130 controls |
| SAQ D | You store, process or transmit card data directly | ~330 controls |
DPDP: the bill most stores have not budgeted for
The Digital Personal Data Protection Act, 2023 is the one that changes e-commerce operationally, because it applies to data you have always treated as harmless: the delivery address, the phone number, the order history. Under DPDP every one of your customers is a Data Principal, you are a Data Fiduciary, and consent has to be free, specific, informed and unambiguous — the pre-ticked marketing checkbox is dead.
The Draft DPDP Rules, released for consultation in January 2025, fill in the operational detail. Here is what an e-commerce fiduciary has to be able to demonstrate.
- Itemised consent notice — you cannot bundle order-fulfilment consent with marketing consent with data-sharing-to-partners consent. Each purpose needs its own clear ask.
- A working consent-withdrawal path that is as easy as giving consent, plus the ability to fulfil access, correction and erasure requests from customers.
- Breach notification to the Data Protection Board without undue delay, with intimation to affected users — there is no lower size threshold, unlike CERT-In's separate obligations.
- Purpose limitation and retention limits — you must delete personal data when the purpose is served (the draft rules point to erasure timelines, e.g. three years of inactivity for large platforms), rather than hoarding a decade of order data.
- Data processing agreements with every processor — your shipping aggregator, your SMS provider, your cloud host — because you remain liable for what they do with the data you hand them.
The penalty structure is what makes the CFO listen. A failure to take reasonable security safeguards that leads to a breach carries a fine of up to two hundred and fifty crore rupees. Failure to notify a breach is up to two hundred crore. These are per-instance ceilings decided by the Board, not theoretical caps buried in a schedule.
What actually happens: an anatomy of a checkout skimmer
Let us make this concrete. A mid-sized fashion retailer in Pune, doing about forty crore a year, came to us after their bank flagged a spike in fraud reports traced to cards used on their site over a six-week window.
The gateway was fine. The cards were never stored. What had happened: eight months earlier a marketing team had added a third-party pop-up widget for exit-intent discounts, pasted from the vendor's dashboard as a script tag on every page — including checkout. The vendor's own CDN account was compromised. The attacker modified the hosted script to add a small piece of code that read the card and CVV fields as the customer typed and exfiltrated them to a domain that looked like a fonts provider.
Nobody noticed for six weeks because there was no integrity monitoring on the payment page (the exact gap Requirement 11.6.1 now closes), no content-security-policy restricting where scripts could send data, and no one reviewing the list of scripts on the checkout flow. The forensic and remediation bill — incident response, re-assessment, card-network fines passed through the acquirer, and a very unhappy set of customers — ran well past sixty lakh rupees. The exit-intent widget had generated a few thousand rupees of extra sales.
That is the shape of a real e-commerce breach. Not a hacker cracking your encryption — a trusted third-party script you forgot you had loaded on the one page that mattered.
The API layer: where modern stores actually leak
Your mobile app and your website talk to the same backend APIs, and those APIs are frequently the least-tested surface in the whole business. In pen-tests of Indian storefronts these are the findings we file most often.
- Object-level authorisation missing — the endpoint checks that you are logged in, but not that the resource belongs to you. Sequential or guessable IDs turn this into a mass data-harvest.
- Coupon and pricing logic enforced only on the client — a tampered request buys a fifty-thousand-rupee phone for one rupee, or stacks discount codes the UI would never allow.
- OTP and rate-limiting weaknesses — no lockout on the OTP endpoint, so an attacker brute-forces a four-digit code, or the OTP is returned in the API response for the app to auto-fill (yes, we still find this).
- Excessive data exposure — the product API returns internal cost price, supplier IDs, and the customer profile API returns the full record including a hashed-but-crackable password or a saved-card token.
- No authentication on webhooks — the payment-confirmation webhook that marks an order as paid is not verifying the gateway's signature, so a forged callback ships free goods.
A right-sized programme by stage
You do not need a bank's security budget. You need controls proportionate to your card flow and data volume. Here is roughly how we scope it, with realistic Indian pricing.
| Stage | Card handling | Baseline controls | Indicative annual cost (INR) |
|---|---|---|---|
| Early store (<5 cr GMV) | Redirect/iframe gateway, SAQ A | Self-assessed PCI SAQ A, annual web VAPT, DPDP consent + privacy notice, MFA on admin | 2–6 lakh |
| Growth (5–50 cr) | JS on payment page, SAQ A-EP | SAQ A-EP with QSA guidance, web + API VAPT twice yearly, payment-page integrity monitoring, DPO/consent manager, DPAs with processors | 8–20 lakh |
| Scale (50 cr+) | Complex / stored tokens | Full RoC-style assessment where applicable, quarterly VAPT + ASV scans, WAF, SIEM/log monitoring, DPDP significant-fiduciary readiness | 25 lakh+ |
A few notes on timelines, because they trip people up. An external ASV (Approved Scanning Vendor) scan under PCI must pass every quarter — a single failing scan resets the clock. A full web-plus-API VAPT engagement typically runs three to five weeks from scoping to a re-tested clean report. DPDP consent and notice re-plumbing is usually a four-to-eight-week project once you factor in legal review and engineering.
The fix-it checklist
If you do nothing else this quarter, work down this list. It is ordered by how often the gap shows up in real assessments, not by how hard it is.
- Inventory every script on your checkout and payment pages; remove any you cannot justify, and add integrity/tamper monitoring on those pages (closes PCI 6.4.3 and 11.6.1).
- Deploy a Content-Security-Policy that restricts where checkout scripts can load from and send data to — this alone would have stopped the skimmer scenario above.
- Test object-level authorisation on every API that returns customer data; never trust sequential IDs, and enforce ownership server-side.
- Confirm which SAQ you are genuinely eligible for — if your own page touches card fields, budget for SAQ A-EP, not SAQ A.
- Turn on MFA and enforce twelve-character minimum passwords for all admin, CRM and cardholder-environment access (PCI 8.3.6, 8.4.2).
- Rewrite consent flows to be itemised and unbundled, and build a working data-access, correction and deletion path (DPDP).
- Sign data processing agreements with every third party that touches customer data — shipping, SMS, cloud, marketing.
- Register your CERT-In contact, enable log retention for 180 days as directed, and write a one-page incident-response runbook with the six-hour reporting clock in it.
- Verify payment webhook signatures and enforce all pricing, coupon and inventory logic server-side.
- Run VAPT before every major release and at least twice a year — a certificate from twelve months ago tells an examiner nothing about the code you shipped last week.
The point of all this
Come back to where we started. The breach that hurts you will not be the one you spent your whole budget defending. It will be the forgotten widget, the guessable order ID, the SAQ you claimed you were eligible for but were not. E-commerce security is less about buying a bigger firewall and more about knowing, precisely, every place your customers' data and cards travel — and watching those places like they matter, because a regulator now agrees they do.
If you want a second set of eyes that has actually sat in the audit room, our team at CyberSigma are senior CERT-In empanelled auditors and PCI QSAs who scope, test and re-test e-commerce stacks hands-on — no templated report, no theatre. We are happy to walk your checkout flow with you and tell you plainly where it leaks.
FAQs
We use Razorpay/Stripe, so are we already PCI compliant?
No. Your gateway is compliant for the part it handles. You still inherit PCI scope, and unless your page uses a pure redirect or iframe that never touches card fields, you likely need SAQ A-EP rather than the simpler SAQ A. You are also fully responsible for the customer PII on your own systems, which the gateway never sees.
Does DPDP apply to a small store that only ships within India?
Yes. The DPDP Act applies to processing the personal data of Indian Data Principals regardless of your size — there is no small-business exemption from the core obligations. The government may notify lighter obligations for certain classes, but consent, security safeguards and breach handling apply to you today.
How often do we need a VAPT for our e-commerce site?
At minimum twice a year, and before any significant release or architecture change. For PCI, you also need passing quarterly ASV external scans and an annual penetration test. A VAPT is a snapshot of the code at a point in time, so a report older than your last few deployments has limited assurance value.
What is the difference between an ASV scan and a VAPT?
An ASV scan is an automated external vulnerability scan by a PCI-approved vendor, run quarterly, that checks your internet-facing surface for known issues. A VAPT is a deeper, largely manual assessment — including business-logic, authorisation and API testing — that finds the flaws automation misses, such as an order-lookup that exposes other customers' data.
What are the real penalties if our store is breached?
Under DPDP, failing to take reasonable security safeguards can attract a fine of up to two hundred and fifty crore rupees, and failure to notify the Data Protection Board up to two hundred crore. Separately, card-network fines and remediation costs flow through your acquiring bank, and CERT-In non-reporting carries its own penalties under the IT Act.
We are tiny — where should our first rupee of security spend go?
Two places. First, a web and API VAPT to find the authorisation and business-logic flaws that cause data leaks. Second, cleaning up your checkout page: inventory every script, add a content-security-policy, and enable payment-page integrity monitoring. That combination addresses the most common and most expensive e-commerce failure modes for a modest cost.
Liked the post? Share on:
Leave A Comment