What are the best practices for data security in e-commerce?

The short answer: lock down how your web app handles input, sessions and access, patch what you’re running, and know where your POPIA §19 duty ends and PCI DSS begins. Most e-commerce breaches don’t start with a nation-state attacker — they start with an unpatched plugin, an admin panel with no rate limiting, or an API endpoint that trusts whatever the browser sends it.

We do web application security assessments for a living, so this is the layer we know best. Here’s what actually moves the needle for a South African online store, and where our scope stops.

Input validation is still where most damage starts

Every field a customer touches — search boxes, checkout forms, promo codes, product filters — is a door into your database if the app trusts it blindly. SQL injection and cross-site scripting are old vulnerability classes, but they’re still routinely found in production e-commerce sites, usually in a custom form, a plugin, or an API endpoint nobody thought to test. Validate and sanitise on the server side, not just in the browser — client-side validation is a UX nicety, not a security control, because anyone can bypass it with a proxy or a curl command.

Access control: assume someone will try the URL directly

A lot of e-commerce breaches aren’t clever exploits — they’re someone changing an order ID in the URL and seeing another customer’s invoice, or an unauthenticated request reaching an admin endpoint because the check only lived in the frontend. Enforce authorisation on every request, server-side, for every resource that touches customer or order data. If a logged-in customer can view /orders/1042, confirm the backend actually checks that order 1042 belongs to them — not just that they’re logged in.

Session and authentication handling

Session tokens need to expire, regenerate on login, and be invalidated properly on logout — not just cleared from the browser’s local view while the server-side session limps on. Enforce password complexity and lockouts on repeated failed logins, and put multi-factor authentication in front of anything that touches admin functions, payment settings, or bulk customer data exports. Cookies carrying session tokens should be flagged Secure and HttpOnly (with the narrow, well-understood exception of auth tokens that a client-side library genuinely needs to read — that’s a deliberate design choice, not an oversight, and it should be documented as one).

Protecting personal and order data at rest and in transit

Names, addresses, phone numbers, purchase history — this is personal information under POPIA, and it needs protecting whether or not a card number is anywhere nearby. TLS everywhere (not just on the checkout page), encryption for sensitive fields at rest, and — importantly — access restricted internally too. A support staffer with read access to every customer’s full order history when they only need the current ticket is a POPIA risk sitting quietly on your team, not just an external-attacker one.

Patch what you’re running

If your store runs on WooCommerce, Shopify apps, Magento extensions, or any third-party plugin ecosystem, outdated versions are one of the most common ways attackers get in — the vulnerability is public, the exploit is scripted, and the bot doesn’t care how small your store is. Keep the platform, plugins and server software current, and remove anything installed once and forgotten.

Where POPIA §19 comes in — and where it stops

POPIA §19 requires a responsible party to take “appropriate, reasonable technical and organisational measures” to protect personal information, to identify foreseeable risks, and to verify those safeguards are actually working — not just documented. In force since 1 July 2021, with breach notification to the Information Regulator and affected customers required under §22. For an online store, that means the web-application-layer practices above are squarely in scope: if a customer’s personal information leaks because of an unpatched plugin or a broken access check, that’s a §19 failure, and a bank, insurer or enterprise client asking for evidence of “reasonable technical measures” is asking for exactly what a confirmed vulnerability scan documents.

What this looks like in practice

Our Deep Scan is a done-for-you assessment of the live application — active testing, not an automated tool dump. We reproduce every finding with a re-runnable proof of concept, strip out false positives before you see a report, and only report what we can prove — 0 false positives on confirmed findings, no scary-looking noise you have to triage yourself. We never scan without your written authorisation and proof of domain ownership. Findings map to MITRE ATT&CK, NIST CSF, OWASP and CWE, so your evidence trail is recognisable to whoever’s asking, and every engagement ends with a 30-minute debrief where we walk through what we found and what to fix first.

If you need POPIA §19 evidence for a bank, insurer, or enterprise client — and you want it right-sized rather than gold-plated — that’s the gap we sit in. Get in touch and we’ll tell you honestly whether a Deep Scan is what you need, or whether you should be talking to a PCI QSA instead.