E-commerce security: hardened, monitored, defended
The security work most developers skip: hardening the shop and the server underneath, catching attacks before customers notice, cleaning things up when something slips through. I run security as part of operations, not as an afterthought.
- Hardening the shop
- PrestaShop admin folder renamed and protected, strong passwords and 2FA for admins, module audit, unused modules removed, up-to-date core.
- Hardening the server
- Patches on a schedule, SSH on keys only, firewall and fail2ban tuned, TLS kept current, system users and permissions reviewed.
- Web application firewall
- ModSecurity with the OWASP Core Rule Set, tuned for PrestaShop and WHMCS so legitimate traffic is not blocked and attacks are.
- Monitoring and alerts
- Login attempts, admin changes, file integrity, service health and TLS expiry watched. I see problems before customers do.
- Backups that actually restore
- Off-site, encrypted, and periodically restore-tested on a staging server. A backup you have never restored is not a backup.
- Incident response
- When something happens, I isolate the system, clean it, find the entry point, close the gap, and write up what happened. There is a dedicated landing page for emergency cleanup.
- Security lead for your systems
- For customers on a maintenance contract I act as the named security lead: one accountable person who knows the shop, the server and the history.
- E-mail and DNS protection
- SPF, DKIM and DMARC configured and kept passing, so your domain is harder to spoof and your transactional mail reaches customers.
E-commerce is attacked every day, mostly by automated scans and credential stuffing, occasionally by someone who knows what they are doing. The right answer is not a single product: it is a set of habits applied to a specific shop, the server under it, and the people who have access to both. I run those habits for shops I build and for shops that come to me after an incident, and I act as the security lead for the systems I keep online.
I work in defense first: patching, firewall, access control, backups, monitoring, incident response. When a customer asks for an offensive check on their shop or infrastructure, I do that too, with a written authorization that defines scope and dates: there is a dedicated page for that.
Questions, answered
What is the difference between this page and the "hacked site" one?
This page is about keeping the shop safe before anything happens, and running it securely day to day. The "hacked site" page is for emergencies, when something has already gone wrong.
Do you also do penetration tests?
Yes, on request from the owner of the system and with a written authorization that defines scope and dates. See the penetration test page.
Can you be our named security lead for a compliance form?
For customers on a continuous maintenance contract, yes. I am the person who sees the servers and the shop every day: it only makes sense if the relationship is real.
What about PCI DSS?
If payments go through a hosted gateway (Stripe, PayPal, Nexi, Setefi, Scalapay) the shop is in SAQ A scope, which is the simplest tier. I help you keep the shop configured so it stays in that scope, and I prepare the technical answers for the questionnaire.
Related work
To go deeper
Tell me what’s not working, or not talking to what.
New build, a system that needs rescuing, an integration, EU compliance (withdrawal button, GPSR, accessibility). One developer who builds it and stays to run it. I reply within one business day.
Prefer email?
luca@cavallini.net