Step‑by‑step penetration test checklist for Indian e‑commerce sites

Define scope and legal boundaries

Start with a crystal‑clear scope. List every public URL, sub‑domain, API endpoint, mobile app bundle and any third‑party payment gateway you expose. In India, you must have a signed engagement letter that references the Information Technology Act, 2000 and any GST‑related data‑handling clauses. Without that paperwork, even a well‑intended test can land you in legal trouble.

Checklist items for scoping

1. Identify all asset owners and get their written consent.
2. Map out the technology stack – LAMP, MEAN, Java, etc.
3. Note any legacy browsers you still support (often Android 5 on low‑end phones).
4. Record compliance regimes: PCI‑DSS for card data, GDPR‑India equivalents for personal data, and any state‑level data‑localisation rules.
5. Agree on a testing window that avoids peak traffic (e.g., 2 am–5 am IST).

Information gathering (recon)

Passive recon is cheap and safe. Use public tools like whois, nslookup, and Shodan to list IP ranges, DNS records and exposed services. For Indian e‑commerce, pay attention to CDN edge locations – many sites sit behind Cloudflare or Akamai, which can mask origin IPs. If you can’t see the origin, request it from the client; otherwise, you’ll be probing the CDN, which may trigger rate limits.

Typical recon outputs

Threat modeling specific to Indian e‑commerce

Not every vulnerability matters equally. Map threats to business impact:

• Card data theft – direct loss, PCI fines.
• Personal data leakage – GST audit risk, consumer trust.
• Service disruption – loss of sales during peak festivals (Diwali, Holi).
• Supply‑chain compromise – third‑party logistics APIs.

Prioritise tests that could affect these assets. For example, a SQL injection on the checkout page is higher risk than a missing X‑Content‑Type‑Options header on the blog.

Vulnerability assessment

Automated scanning

Run a scanner that respects Indian bandwidth limits – set the max‑rate to ~200 kbps to avoid throttling on 2G/3G networks common among rural users. Tools like OWASP ZAP, Nessus, or Acunetix can flag:

• SQLi
• XSS
• Insecure deserialization
• Open redirects

Manual validation

Automated findings are noisy. Manually verify each high‑severity alert:

• Craft payloads that bypass WAF rules (e.g., using Unicode encoding).
• Test authentication bypass on admin portals – many Indian sites still use default admin/admin credentials.
• Check for insecure direct object references (IDOR) in order APIs.

Business‑logic testing

This is where most Indian e‑commerce bugs hide. Try scenarios like:

• Price manipulation – change price fields in the checkout request and see if the backend validates.
• Coupon stacking – apply multiple discount codes to exceed allowed limits.
• Cart tampering – add a high‑value item, then remove it from the UI but keep it in the request.
• Session fixation – reuse an old session token after login.

These tests require a good understanding of the purchase flow; they’re not covered by generic scanners.

Mobile app security (if you have Android/iOS apps)

Most Indian shoppers use Android on low‑end devices. Decompile the APK with apktool, look for hard‑coded API keys, and check for debuggable flag set to true. Run MobSF to scan for insecure storage of tokens. For iOS, use class‑dump to inspect binaries for hard‑coded URLs.

Payment gateway integration checks

PCI‑DSS mandates that card data never touch your servers if you use a hosted payment page. Verify that:

• The checkout form posts directly to the gateway URL.
• No card fields are present in your server logs.
• TLS 1.2+ is enforced end‑to‑end.

If you do store PAN or CVV, you must be fully PCI‑DSS compliant – a checklist item that often trips Indian startups.

Network and infrastructure hardening

Run a nmap sweep on the internal network (if you have VPN access). Look for:

• Open Redis or MongoDB instances without authentication.
• Unpatched Apache/NGINX versions exposing CVE‑2022‑XXXXX.
• SSH with password authentication enabled.

For cloud‑hosted sites on AWS or Azure, ensure security groups follow the principle of least privilege; many Indian firms leave port 22 open to the world for convenience.

Reporting and remediation guidance

A good report is actionable. Include:

• Finding title – concise, e.g., “SQL injection in /search endpoint”.
• Severity – use CVSS v3 but adjust for business impact (e.g., “Critical – could expose customer PII”).
• Proof of concept – a short curl command or screenshot.
• Remediation steps – code‑level fix plus configuration change.
• Verification – how to test that the fix works.

End the report with a risk matrix that maps each finding to compliance impact (PCI, GST, etc.).

Cost and time estimate (illustrative)

Final checklist you can copy‑paste

• [ ] Signed engagement letter covering IT Act, PCI‑DSS, GST clauses.
• [ ] Complete asset inventory (URLs, APIs, mobile bundles).
• [ ] Passive recon completed; origin IP identified.
• [ ] Threat model aligned with business impact.
• [ ] Automated scan run with bandwidth throttling.
• [ ] All high‑severity alerts manually verified.
• [ ] Business‑logic test cases executed and logged.
• [ ] Mobile app decompiled; secrets removed.
• [ ] Payment flow checked for PCI compliance.
• [ ] Infrastructure ports hardened; cloud security groups reviewed.
• [ ] Report drafted with CVSS, remediation, risk matrix.
• [ ] Findings presented to stakeholders; remediation plan agreed.

Running through this list ensures you don’t miss the low‑hanging fruit that often leads to data breaches in Indian e‑commerce.

We at Nexgino follow this disciplined approach when we help clients tighten their security posture.