E-commerce Security Beyond HTTPS: What Really Protects Your Store
HTTPS is only the start. The threats that actually hit online stores, from admin takeovers and checkout skimming to fake payment callbacks, and the controls, OWASP checks and monthly checklist that stop them.
HTTPS encrypts the connection between a customer's phone and your store. That is essential, but it does not stop someone logging into your admin panel with a leaked password, a malicious script copying card details on your checkout page, a fake "payment successful" message marking unpaid orders as paid, or a bug that lets one customer open another customer's orders. Real e-commerce security is a set of controls across payments, accounts, staff access, code, servers and monitoring.
For Egyptian stores the stakes are rising. Online payment is growing, customer data is valuable, and from 1 November 2026 the Personal Data Protection Law's executive regulations are fully in force, including notification of data breaches to the regulator within 72 hours. Trust is also a sales issue: in Baymard Institute's checkout research, 19% of shoppers who abandoned a purchase said they did not trust the site with their card information (Baymard Institute).
This guide lists the threats that actually hit online stores, the controls that stop them, and a checklist to use before launch and every month after.
Key takeaways
- Keep card data off your servers by using the payment gateway's hosted or embedded checkout, and protect the checkout page from injected scripts.
- Mark orders as paid only after verifying the gateway's signed server-to-server callback and the amount.
- Protect the admin panel with strong passwords, multi-factor authentication, role-based permissions and audit logs.
- Store customer passwords with salted hashing, rate-limit logins and use secure, HttpOnly session cookies.
- Patch dependencies and servers, monitor logs, test backups, and have a data breach plan that meets the 72-hour notification rule.
What HTTPS does, and what it does not
An SSL/TLS certificate encrypts traffic in transit and proves the domain's identity. It protects against eavesdropping on public Wi-Fi and is a baseline requirement for browsers, search engines and payment gateways. It does not protect:
- Data stored in your database or backups.
- Your admin panel from stolen or weak passwords.
- Your code from injection, broken access control or vulnerable libraries.
- Your checkout from malicious scripts loaded by a compromised plugin or third party.
- Your business from insiders exporting customer lists.
The threats that actually hit online stores
| Threat | What it looks like | Main control |
|---|---|---|
| Admin account takeover | A staff member's reused password leaks; an attacker changes prices or exports customers | MFA, strong passwords, least-privilege roles, audit logs |
| Credential stuffing on customer accounts | Bots try leaked email/password pairs to access accounts and saved addresses | Rate limiting, lockouts, salted password hashing, OTP for sensitive actions |
| Payment callback forgery | A fake "success" request marks an unpaid order as paid and it ships | Verify signed callbacks and amounts server-side |
| Checkout script injection (skimming) | A compromised third-party script copies card details as they are typed | Hosted/embedded payment page, script control, Content Security Policy |
| Broken access control | Changing an order number in the URL shows another customer's order | Server-side ownership checks on every request |
| Vulnerable plugins and libraries | An outdated component with a known flaw is exploited | Dependency inventory, updates, security advisories |
| Fake orders and bots | Scripts flood checkout with fake COD orders or test stolen cards | Rate limiting, bot protection, order verification |
| Data exposure by insiders | An employee exports the full customer list before leaving | Role-based access, export permissions, logging |
Use OWASP Top 10 as your checklist
The OWASP Top 10 is the most widely used awareness list of web application risks. Its 2025 edition lists: Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Software or Data Integrity Failures, Security Logging and Alerting Failures, and Mishandling of Exceptional Conditions (OWASP Top 10:2025). Ask your developer or agency how each one is handled in your store; clear answers are a good sign.
Payment security: keep card data away from your servers
Use hosted or embedded checkout
With a hosted payment page (redirect) or an embedded form (iframe) from a PCI DSS-compliant provider, card numbers are entered directly into the gateway's systems. Under PCI DSS, e-commerce merchants that fully outsource card entry this way can use the shortest self-assessment questionnaire, SAQ A. In February 2025 the PCI Security Standards Council clarified an added eligibility criterion: the merchant must confirm its site is protected from script-based attacks that could affect its e-commerce systems, either through its own controls or through confirmation from its payment provider (PCI SSC, 2025).
Verify every payment on the server
- Never trust the customer's browser redirect as proof of payment.
- Verify the gateway's callback signature (for example an HMAC) with your secret key.
- Check the amount, currency and order reference against your records.
- Process callbacks idempotently so duplicates cannot trigger double shipping or double refunds.
Control refunds
Refunds move money out. Limit who can issue them, require a reason, set approval thresholds for large amounts and log every refund.
Customer accounts and sessions
- Password storage: use a slow, salted password hashing algorithm. Never store passwords in plain text or with simple, fast hashes.
- Login protection: rate-limit login and password reset endpoints, and add OTP verification for sensitive changes such as phone number or address.
- Sessions: keep session tokens in secure, HttpOnly cookies so page scripts cannot read them, and expire sessions after inactivity.
- Access checks: every request for an order, address or invoice must confirm on the server that it belongs to the logged-in customer.
The admin panel and staff access
Most serious store incidents involve the back office, not the storefront.
- Require multi-factor authentication for every admin account.
- Create roles: customer service sees orders but not exports; marketing edits content but not prices; only the owner or finance issues large refunds.
- Log logins, price changes, refunds and data exports with user, time and IP.
- Remove access the same day an employee leaves.
- Consider restricting admin access by IP or VPN for high-value stores.
Hardening the application
- Security headers: set Content Security Policy, HSTS, frame and content-type protections; middleware such as Helmet does this for Node.js applications.
- Input validation: validate every input on the server against a strict schema, and use parameterised queries to prevent injection.
- Third-party scripts: keep a list of every script on checkout pages and remove anything not essential there, including chat widgets and extra trackers.
- Dependencies: keep an inventory, update regularly, and subscribe to security advisories for your framework and libraries.
- Error handling: show customers generic messages, log details privately, and make sure failures (for example a gateway timeout) leave orders in a safe state.
Servers, backups and monitoring
- Apply operating system and web server updates on a schedule.
- Expose only necessary ports; keep databases off the public internet.
- Take automatic, encrypted backups and test restoring them; an untested backup is a hope, not a plan.
- Centralise application logs and alert on unusual patterns: spikes in failed logins, many refunds, large exports.
- Prepare for traffic peaks such as White Friday and Ramadan campaigns, which attract both customers and bots.
Security and Egypt's data protection law
Law 151/2020 and its executive regulations, issued in November 2025 with compliance due by 1 November 2026, require organisations to protect personal data and to notify the regulator of personal data breaches within 72 hours, according to published legal analyses (CMS, 2026). For a store, that means knowing what data you hold, collecting only what you need, restricting access, and having a written incident response plan: who investigates, who decides, who notifies, and how customers are informed.
Security checklist: before launch and every month
| Check | Before launch | Monthly |
|---|---|---|
| HTTPS everywhere, HSTS enabled | Yes | Certificate renewal verified |
| Hosted/embedded checkout, callbacks verified | Yes | Review checkout scripts |
| Admin MFA and roles | Yes | Review users and remove leavers |
| Salted password hashing, login rate limits | Yes | Review failed-login alerts |
| Security headers and input validation | Yes | Re-test after major releases |
| Dependencies and server patches | Up to date | Apply updates |
| Backups | Automated and restore-tested | Test a restore |
| Incident response plan | Written | Update contacts |
How Nilex helps
Nilex builds online stores with security built into the stack: hosted or embedded checkout with verified gateway callbacks, salted password hashing, rate limiting on logins and checkout, security headers through Helmet, HttpOnly session cookies, role-based admin access with audit logs, and structured logging and backups on hardened servers.
Frequently asked questions
Is an SSL certificate enough to secure my online store?
No. SSL/TLS encrypts data in transit but does not protect your admin panel, database, code or checkout scripts. You also need secure payments, access controls, patching, monitoring and backups.
Do I need PCI DSS compliance if I use Paymob or another gateway?
Merchants that accept cards have PCI DSS obligations, but using the gateway's hosted or embedded checkout greatly reduces them, often to the SAQ A questionnaire. You still need to protect your site from script-based attacks on the payment page.
How can a store be tricked into shipping unpaid orders?
If the store treats the customer's browser redirect or an unsigned request as proof of payment, an attacker can fake it. Always verify the gateway's signed server-to-server callback and the amount before marking an order paid.
What should I do if my store's customer data leaks?
Contain the incident, preserve logs, assess what data was affected, and follow your response plan. Under Egypt's data protection regulations, breaches must be notified to the regulator within 72 hours, so get legal advice immediately.
Are store plugins a security risk?
They can be. Each plugin or script adds code you did not write. Install only what you need, keep everything updated, remove unused components, and keep non-essential scripts off the checkout page.
If you want an independent look at how your store handles payments, accounts and admin access, book a free consultation with Nilex and we will review it with you.
