Part 1 of 3 in the E-Commerce Security series. This post covers the fundamentals. Part 2 goes deeper for senior developers. Part 3 is for everyone who shops online.
I spent three years building e-commerce stores for companies across Europe. Shopping platforms, payment integrations, checkout flows - the works. That experience gave me a front-row seat to how the industry treats security, and it's not great. Across the board - in blog posts, conference talks, open-source projects, community forums - security is consistently treated as an afterthought. Something to "circle back to" after launch. Something for "phase two." Phase two rarely comes.
It's an industry-wide pattern. Deadlines push security tickets down the backlog. Teams optimise for features and conversions because that's what gets measured. And I get it - when you're under pressure to ship, security feels abstract until it isn't.
That pattern is what led me to study cybersecurity for my master's degree while I was still building those stores. I wanted to understand the full picture - not just the developer's instinct that something could be better, but the frameworks, the standards, the research behind what "doing it right" actually looks like. My dissertation focused on proposing a comprehensive e-commerce security framework, and it confirmed what I'd been thinking: the gap between what e-commerce stores should be doing and what the industry typically does is enormous. I now lead an engineering team at a cybersecurity company, and from that vantage point, the scale of the problem across the e-commerce industry is even clearer.
The numbers back this up. In 2014, Home Depot reached a $17.5 million settlement over a 2014 data breach that affected 40 million customers. In 2018, British Airways had 380,000 payment card details stolen through a compromised checkout flow - a breach that resulted in a GDPR fine from the ICO (I break down exactly how this attack worked in Part 2). Verizon's 2024 Data Breach Investigations Report found that small businesses continue to be disproportionately affected by breaches, many running off-the-shelf platforms that weren't built with security in mind.
What frustrates me most is that these aren't sophisticated attacks. They're basics that got skipped. And as someone who shops online too, it bothers me how little control we have over whether the store we're buying from has done the bare minimum to protect our data.
So here's the checklist I wish every e-commerce team pinned to their wall.
If You Do Nothing Else
Short on time or budget? These five items give you the most protection for the least effort:
- Enable MFA on every account with access to customer data. Not just admins - customer service, warehouse staff, anyone who can see personal information. This is a configuration change, not a project.
- Audit your logs for sensitive data. Search your application logs for credit card patterns, email addresses, passwords. If they're there, fix the logging and purge the old logs. This can be done in an afternoon.
- Stop storing what you don't need. Let your payment processor handle card data. Delete customer records you're no longer legally required to keep. Less data stored means less data to breach.
- Patch your dependencies. Run your dependency scanner right now. If you don't have one, add one to your CI pipeline today. Known vulnerabilities in unpatched dependencies are how the majority of preventable breaches happen.
- Read the OWASP Top 10. Seriously. It takes thirty minutes and covers the vulnerabilities most likely to exist in your codebase right now.
If you've done all five, read on. If you haven't, start there.
The Big Three Frameworks
During my research, I dug into the three industry frameworks that form the backbone of e-commerce security. If you take nothing else from this post, at least know these exist:
PCI DSS is non-negotiable if you handle credit card data. It covers network security, cardholder data protection, vulnerability management, access control, monitoring, and security policy. If you're processing payments, you're either compliant or you're a liability. You'd be surprised how many teams in this industry have never read the requirements.
OWASP Top 10 is your web application security baseline. Injection attacks, broken authentication, cross-site scripting, security misconfigurations - the vulnerabilities I saw most often in the wild are all on this list. If your development team hasn't read it, stop here and send them the link.
NIST Cybersecurity Framework organises security into five functions: Identify, Protect, Detect, Respond, and Recover. It gives you a mental model for thinking about security holistically rather than as a list of tools to install. It's not e-commerce-specific, but the structure is invaluable.
None of these alone covers everything. Together, they cover most of it.
The Checklist
Authentication - The Front Door
Your authentication is only as strong as its weakest user account. It's not uncommon in the industry to find stores where the admin panel has MFA but the customer service dashboard - with full access to customer addresses, order history, and partial payment details - is protected by a shared password.
- [ ] Multi-factor authentication enabled for all admin and staff accounts (not optional - mandatory)
- [ ] MFA available and encouraged for customer accounts, especially at checkout
- [ ] Password policy enforced: favour long passphrases over complexity rules, and check passwords against known breached password lists (per current NIST SP 800-63B guidance)
- [ ] Centralised authentication - no one-off login systems for different parts of the platform
- [ ] User permissions reviewed quarterly. People change roles. Permissions should change with them
- [ ] Brute-force protection: rate limiting, account lockout after failed attempts
The common mistake: MFA for admins but not for the customer service team who have access to customer data. Every account with access to sensitive data needs MFA.
Data Protection - What You Store Can Hurt You
The best way to protect data is to not store it in the first place. A pattern I've seen across the industry is stores logging full request bodies to help with debugging, without anyone thinking about what's in those request bodies - including payment details passing through on their way to the processor. That kind of log file is a breach waiting to happen.
- [ ] Encrypt sensitive data at rest (database, backups, logs)
- [ ] Encrypt data in transit (TLS everywhere, not just checkout pages)
- [ ] Don't store what you don't need. Credit card numbers should live with your payment processor, not in your database
- [ ] Role-based access controls: developers don't need access to production customer data
- [ ] Automated, tested backups. "We have backups" means nothing if you've never restored one
- [ ] GDPR compliance if you serve EU customers: data retention limits, right to deletion, consent management
The common mistake: Logging sensitive data. Your application logs shouldn't contain credit card numbers, passwords, or personal information. Audit your log output.
Monitoring - You Can't Fix What You Can't See
Most breaches aren't discovered by the victim. They're reported by a third party, often months later. That delay is the difference between a contained incident and a catastrophe.
- [ ] Network monitoring for unusual traffic patterns and connection attempts
- [ ] Log aggregation and analysis - centralised, searchable, with alerts
- [ ] Intrusion detection systems (IDS) on critical infrastructure
- [ ] Failed login monitoring with automated alerting
- [ ] File integrity monitoring on critical system files and configurations
- [ ] An actual incident response plan that your team has rehearsed, not just a document nobody's read
The common mistake: Collecting logs but never looking at them. Monitoring without alerting is just expensive storage.
Risk Assessment - Know Your Weak Points
You can't protect everything equally. Prioritise based on what would hurt the most. It's easy for teams to spend weeks hardening the storefront while the admin API - which has direct database access - sits wide open with default credentials. Nobody steps back to ask "what's actually at risk here?"
- [ ] Inventory your assets: what systems, data, and integrations exist?
- [ ] Map your threat landscape: what's most likely to go wrong, and what's the impact?
- [ ] Assess third-party risk. Your payment gateway, shipping API, analytics tools - they all have access to something
- [ ] Conduct risk assessments at least annually, or after any major change to infrastructure
- [ ] Document accepted risks explicitly. If leadership decides not to fix something, that decision should be on paper
The common mistake: Ignoring third-party risk. You might have airtight security, but if your chat widget provider gets breached and they have access to your customer sessions, that's your problem.
Security Controls - The Boring Stuff That Works
These aren't exciting. They're effective. And across the industry, they're consistently the first things to get deprioritised.
- [ ] Web Application Firewall (WAF) in front of your application
- [ ] Patch management process: OS, framework, dependencies. The British Airways breach exploited vulnerabilities that could have been mitigated with up-to-date security practices
- [ ] Network segmentation: your database server shouldn't be directly accessible from the internet
- [ ] Dependency scanning in CI/CD - know when your packages have known vulnerabilities
- [ ] Regular penetration testing by an external party (not just automated scans)
The common mistake: "We'll patch it next sprint." Patching is not a feature you prioritise - it's hygiene. If a critical CVE drops for a dependency you use, patch it now.
Team Training - Your Biggest Vulnerability Has a Pulse
Technology doesn't click phishing links. People do. This is the area I feel most strongly about. You can have the best firewall, the tightest access controls, the most encrypted database - and one employee clicking a link in a convincing email undoes all of it.
- [ ] Security awareness training for all staff, not just engineering
- [ ] Simulated phishing exercises (and don't shame people who fail - train them)
- [ ] Clear, simple process for reporting suspicious activity
- [ ] Secure coding training for developers, focused on the OWASP Top 10
- [ ] Social engineering awareness: vishing, pretexting, tailgating aren't just buzzwords
The common mistake: Annual compliance training that everyone clicks through. Make it short, relevant, and frequent. Monthly five-minute exercises beat yearly hour-long lectures.
What This Won't Do
This checklist won't make you invulnerable. Nothing will. What it does is cover the basics that prevent the vast majority of breaches - the ones that happen not because of sophisticated nation-state attacks, but because someone didn't enable MFA, didn't patch a known vulnerability, or stored credit card numbers in plaintext.
If you're a small business, you don't need to hire a CISO tomorrow. Start with the items marked as "common mistakes" above - those are the gaps I see most often. Then work through the rest systematically.
If you're a development team building an e-commerce platform, treat this as a minimum bar, not an aspiration. If your team is past the basics and wants implementation detail - CSP rollouts, API security, PCI compliance in practice - Part 2 goes deeper. Your customers trust you with their payment details and personal information. That trust is expensive to earn and trivially easy to lose.
And if you're a consumer - someone who shops online and wonders whether the store you're buying from is doing any of this - you're right to wonder. I wrote Part 3 specifically for you: practical things you can check in under a minute before handing over your card details.
This is Part 1 of a 3-part series on e-commerce security. Part 1: You are here | Part 2: Beyond the Checklist | Part 3: The One-Minute Safety Check
This article draws on my master's dissertation research at the University of Sunderland, A Comprehensive E-commerce Framework for Ensuring Secure and Trustworthy Online Transactions