Website Security for Ecommerce in 2026: Checklist for Shop Owners
TL;DR
- Move card data off your server. Use Stripe, Adyen, or Braintree so your PCI-DSS scope drops from 300+ controls to about 22 (SAQ A).
- Lock the basics: HTTPS everywhere, strong admin 2FA, a web application firewall, and nightly off-site backups. These block roughly 90% of opportunistic attacks.
- Add fraud rules before you add features. Velocity checks, address verification, and 3-D Secure 2 cut chargebacks fastest.
Running an online store in 2026 feels different than it did five years ago. Card skimming on checkout pages is back, bot-driven fraud jumped hard after LLMs made scripting cheap, and more card brands now push the cost of a breach straight onto the merchant.
The good news: you do not need a security team to run a safe shop. You need a short list of things done well, and a payment setup that keeps you out of the sensitive-data business in the first place. This guide walks you through it in plain English.
Why ecommerce is a bigger target than a regular website
A brochure site leaking an email list is bad. A store leaking live card data is a five-figure (or six-figure) event before you even count lost sales. Attackers know this. They also know most small-to-mid stores run on a stack of off-the-shelf parts: a CMS, a theme, maybe 20 plugins, a payment gateway, a shipping integration. Any one of those can be a door.
The three attack patterns I see again and again on client sites:
- Skimmers injected into checkout pages. A compromised plugin or supply-chain JS file writes a tiny script that reads the card fields and posts them to an attacker server. Your site still works. You find out when your processor sends a chargeback wave.
- Credential stuffing against customer accounts. Attackers take leaked password lists from other breaches, spray them at your login, and use working accounts to place fraudulent orders with stored cards.
- Admin takeover. Weak admin password, no 2FA, plus an outdated plugin with a known RCE. Attacker adds a rogue admin, ships gift cards or digital goods, then pivots to your database.
If your stack handles any of those three well, you are ahead of most stores your size.
PCI-DSS in plain English
PCI-DSS (Payment Card Industry Data Security Standard) is the rulebook the card brands set for anyone touching card data. Version 4.0.1 is the current one for 2026.
You do not "get PCI certified" the way you get an SSL cert. You fit into one of a few self-assessment levels, and the level depends on whether card data ever hits your server.
| Scenario | SAQ type | Controls | Plain meaning |
|---|---|---|---|
| Customer enters card on a hosted field from Stripe/Adyen (most Shopify, WooCommerce with Stripe) | SAQ A | ~22 | You never see the card. Much less paperwork. |
| Card fields are on your page but POST to the processor | SAQ A-EP | ~191 | Your code is in the card flow. Big scope. |
| You store card numbers anywhere | SAQ D | 300+ | Do not do this. Ever. |
The single biggest security decision you make as a shop owner is picking a payment setup that puts you in SAQ A. That means:
- Stripe Elements, Stripe Checkout, or Stripe Payment Element with the card iframe hosted by Stripe.
- Adyen Drop-in or Hosted Payment Pages.
- Braintree hosted fields.
- PayPal Commerce checkout.
- Any Shopify or BigCommerce default flow (they handle it for you).
Avoid any setup where the raw card number touches a form on your domain and your code moves it. The developer hours you "save" are not worth a 300-page assessment plus the liability.
Payment provider security, compared
A quick comparison of the five options most of my ecommerce clients pick in 2026:
| Provider | PCI scope for you | 3-D Secure 2 | Built-in fraud tools | Fees (US, card-present) |
|---|---|---|---|---|
| Stripe | SAQ A | Yes, auto-triggered by Radar | Radar (free tier + paid) | 2.9% + $0.30 |
| Adyen | SAQ A | Yes, with RevenueProtect | RevenueProtect | Interchange + 0.13% |
| Braintree | SAQ A | Yes | Kount basic | 2.59% + $0.49 |
| PayPal Commerce | SAQ A | Yes | Seller Protection | 2.99% + $0.49 |
| Shopify Payments | SAQ A | Yes | Shopify Fraud Analysis | 2.9% + $0.30 (Basic) |
The gap is smaller than the marketing suggests. Pick on integration fit and fraud tooling, not on a 0.1% fee delta.
The fraud detection layer
Payment providers block the most obvious frauds. They do not block everything. Two examples I have seen this year:
- A client on Stripe Radar default rules took $18K in fake orders over one weekend because the attacker spaced transactions across 40 fresh accounts and used 3-D Secure-exempt low-ticket amounts.
- A marketplace got hit by a refund-abuse ring: real cards, real deliveries, then forced chargebacks citing "item not received" after the goods resold on a gray market.
Layer your fraud defenses:
- Velocity checks. Block more than N orders from the same IP, email, card BIN, or shipping address in a rolling window.
- Address Verification Service (AVS) and CVV matching. Decline mismatches for first-time cards.
- 3-D Secure 2 for anything above your average order value. Shifts chargeback liability to the issuer.
- Email and phone reputation. SEON, Sift, or Kount flag throwaway addresses and recent-port phone numbers.
- Device fingerprinting. Radar, Forter, or Signifyd catch repeat attackers even when they rotate cards.
For stores under $2M GMV, Stripe Radar plus a few custom rules is enough. Above that, a dedicated fraud vendor pays for itself fast.
Cart abandonment protection
Cart abandonment is both a revenue and a security topic. Two threats hide in the "recover abandoned carts" flow:
- Email enumeration. If your "reminder" email sends only to real customers, an attacker can ping
/cart/abandonand learn which emails have accounts. Return the same response for both cases. - Session hijacking via reminder links. Many plugins bake a magic token into the recovery URL that restores the full session. If the token is long-lived and the page is served over plain HTTP anywhere in the chain, it leaks. Use short TTLs (24 hours max), rotate on use, and force re-auth for checkout.
On the revenue side: recovery emails at 1 hour, 24 hours, and 72 hours still work. Do not stack retargeting pixels that collect card-adjacent data in the reminder page, because that drags you back toward SAQ A-EP.
SSL, HTTPS, and HSTS
HTTPS is table-stakes. In 2026, a checkout page without HSTS is negligence. The short version:
- Use a free Let's Encrypt cert or your CDN-provided cert. Paid EV certificates stopped showing a green bar in browsers years ago and do not add real security for most shops.
- Force HTTPS at the edge. No mixed content, no HTTP fallback.
- Turn on HSTS with
max-age=31536000; includeSubDomains; preloadand submit to the preload list once you are sure every subdomain supports TLS. - Disable TLS 1.0 and 1.1. Keep TLS 1.2 and 1.3. PCI-DSS 4.0 mandates this.
For a step-by-step, see my SSL setup guide for business sites. It covers Let's Encrypt, HSTS headers, and the errors you hit on the first try.
SQL injection and CSRF in 2026
Both of these are old. Both still show up in the OWASP data every year because frameworks let you opt out of the safe path.
SQL injection happens when user input gets concatenated into a database query. Fix with parameterized queries or an ORM. Every major framework (Laravel Eloquent, Django ORM, Rails ActiveRecord, Prisma, Drizzle) handles this by default. The trap is raw queries you wrote "just this once" for a search or reporting feature. Audit those.
CSRF (cross-site request forgery) tricks a logged-in customer's browser into making a state-changing request on your site. Fix with:
- CSRF tokens on every form that changes state (cart, address, checkout).
SameSite=LaxorStrictcookies for session auth.- Require re-auth for password change and saved-card deletion.
Modern frameworks ship CSRF protection on by default. Turn it off only if you know exactly what you are replacing it with.
The shop-owner security checklist
Copy this into a shared doc and walk it once a quarter.
Identity and access
- Admin 2FA on every CMS and hosting account
- Unique admin emails (no shared mailbox logins)
- Quarterly review of who has admin access; remove ex-staff and ex-agencies
Payments
- Using a hosted payment flow that keeps you in SAQ A
- 3-D Secure 2 enabled for orders above your average ticket
- Radar or equivalent rules tuned to your real order pattern
Platform
- Core CMS, theme, and plugins updated monthly
- Staging site for testing updates before production
- Unused plugins and themes deleted, not just deactivated
Network
- WAF in front (Cloudflare, Sucuri, or AWS WAF)
- Rate limits on
/login,/register,/checkout,/cart - DDoS protection via your CDN
Data
- Nightly off-site backups, tested restore every quarter
- Customer PII encrypted at rest (database-level)
- No card numbers stored on your servers, ever
Monitoring
- Uptime monitor with SMS alerts
- Logs shipped to a place you can search (Datadog, Axiom, CloudWatch)
- Alert on new admin creation, plugin install, and file change in
/checkout
Incident readiness
- Written plan: who calls processor, who notifies customers, who talks to press
- Breach notification template ready for your state and any international customers
- Cyber insurance policy that names ecommerce as covered, not excluded
For the fuller business-owner view of threats and budgets across all site types, see my website security guide for business owners.
If the worst happens
A checklist is not a shield. If you get hit, the first 48 hours matter most. Isolate the compromised store, preserve logs, notify your processor, rotate every secret. I wrote a step-by-step playbook for that exact scenario: how to recover a hacked website.
How I set up stores for clients
When I build a new ecommerce project through custom web application development, the default stack for 2026 is:
- Next.js 16 storefront on Vercel, or Laravel + Filament admin for catalog-heavy stores
- Stripe Payment Element or Adyen Drop-in, never a self-built card form
- Cloudflare in front with WAF rules and bot management
- Postgres or MySQL with field-level encryption for PII
- GitHub Actions running dependency scans on every PR
I did a similar end-to-end integration for a payment-heavy product on the bolttech payment integration project. The lesson from that work: the 90% of security you need is a setup decision, not an ongoing heroic effort.
FAQ
Do I need to be PCI compliant if I only take payments through Stripe?
You still need to attest to SAQ A once a year. Stripe provides a prefilled template. It takes about 20 minutes.
Is Shopify really handling PCI for me?
For Shopify Payments, yes. For third-party gateways on Shopify, read the fine print. Anything that puts card fields back on your theme can push you out of SAQ A.
How often should I run a security audit?
Annually for most stores. Quarterly if you process over $5M GMV or handle any regulated data (health, alcohol, firearms). After any major stack change, no matter the size.
What is the cheapest useful security upgrade?
Admin 2FA plus a Cloudflare Pro plan at $20 per month. The two together stop most real attacks I have seen on client sites.
Can I just buy cyber insurance and skip the work?
You can buy it, but the policy will not pay out if you lacked basic controls. Underwriters now audit. Expect to prove MFA, backups, and patching before they cut a check.
Closing
Ecommerce security in 2026 rewards boring discipline, not clever tooling. Keep card data off your servers, keep your admins behind 2FA, keep your software updated, and keep a tested backup. The rest is tuning.
If you want someone to walk the checklist with you and quietly fix the gaps, I help shop owners do exactly that. Book a free strategy call and we will triage your biggest risks first.