# Securing your shop after a hack: what has to change

> A site that's cleaned up but brought back online exactly as it was before often ends up in the same state within a few months, because nothing changed in how it's maintained. The order of operations right after the incident matters, but it only closes the incident. Here's what then needs to become a habit, not a one-off action.

- Source canonique : [https://allaux.fr/en/securite/se-proteger-apres-un-nettoyage](https://allaux.fr/en/securite/se-proteger-apres-un-nettoyage)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> A regular update policy, a review of access and passwords, removing unused modules, backups that are tested rather than just scheduled, tracking published vulnerabilities in what's installed, and monitoring in place: these six habits, not the cleanup itself, are what sharply reduce the risk of a repeat.

## Before the habits: the order of the first operations

This page assumes the cleanup is done. If it isn't yet, the order matters as much as the operations themselves: bringing a hacked shop back online without addressing the cause is like leaving the door open, and the infection usually returns within days.

Isolate the shop: maintenance mode or a temporary shutdown, to limit the spread and cut visitor exposure while you work.

Change every password: CMS admin, FTP/SFTP, database, hosting panel. One access point left unchanged is enough to reinfect the site after cleanup.

Delete unknown admin accounts: an account created by the attacker is one of the most common backdoors, and it goes before the files are even cleaned.

Compare the files against a clean install of the same version: modified or added files are the most direct trace of an infection.

Check the database: malicious code is also injected into configuration or content fields, not only into files.

Update every component: the exploited flaw very often comes from an outdated one.

Bring it back online, then monitor the logs and activity over the following days, to confirm no backdoor was missed.

That sequence closes the incident. It changes nothing about what made it possible: that is what the rest of this page is for.

| Valeur | Description |
|---|---|
| 39.1% | of compromised CMS applications were running an outdated version at the time of infection |
| 13.97% | of compromised sites had at least one vulnerable extension or theme at the time of remediation |

Source : Sucuri, Hacked Website & Malware Threat Report 2023

## Six structural habits

1. **An update policy, not one-off updates** — The CMS, theme and modules or extensions need checking at regular intervals, not only when a problem shows up. The Sucuri report cited above shows an outdated version was involved in more than a third of the compromises studied: an observed correlation, not a demonstrated cause, but enough to make it a priority.
2. **Track security advisories for what's installed** — A published flaw in a module or extension leaves a window before it's actually exploited. Knowing where to follow these advisories for your CMS changes the odds of acting before you're affected.
3. **Remove what's no longer used** — A deactivated module that's still sitting on the server remains a potential entry point: deactivating it in the admin area doesn't stop a PHP file from running if it's called directly by its path.
4. **Regularly review access and passwords** — Admin accounts created "to help out" and never removed, FTP access given to a former contractor, a password reused elsewhere: a periodic review of who has access to what closes doors that were left open and forgotten.
5. **Test a backup, don't just schedule it** — A backup that exists but has never actually been restored can be incomplete, corrupted, or unknowingly backing up the infection itself. Testing it periodically on a separate environment is the only way to know it will work the day it's actually needed.
6. **Add monitoring or an application firewall** — An application firewall filters out part of the malicious traffic before it reaches the CMS, and file integrity monitoring flags a suspicious change quickly rather than weeks later. Neither replaces updating, but both narrow the window of exposure.

## What rounds this out

- **Track published vulnerabilities in what you use** — WPScan, official PrestaShop advisories, NVD: where and how to watch what actually affects you. ([/securite/surveiller-les-failles-qui-concernent-ma-boutique](/securite/surveiller-les-failles-qui-concernent-ma-boutique))
- **Ongoing maintenance rather than one-off fixes** — Updates, tested backups and monitoring handled on a continuous basis. ([/services/maintenance](/services/maintenance))
- **Abandoned modules and extensions** — The real leading entry point, ahead of weak passwords or a poorly configured server. ([/securite/modules-et-extensions-abandonnes](/securite/modules-et-extensions-abandonnes))
- **Cleaning an infected site** — The cleanup method itself, and why restoring a backup isn't always enough. ([/securite/nettoyer-un-site-infecte](/securite/nettoyer-un-site-infecte))
- **Do I have to notify customers and the regulator?** — What the rules require when personal data may have been exposed. ([/securite/dois-je-prevenir-mes-clients-et-la-cnil](/securite/dois-je-prevenir-mes-clients-et-la-cnil))

## FAQ

### Is a backup enough if I never actually test it?

No. A backup that's never really been restored can be incomplete or corrupted without anyone knowing, until the day it's supposed to be used. Testing it regularly is part of the backup itself, not an optional extra step.

### Should I remove a module even if it still works?

Yes, if it's no longer used or no longer maintained by its developer. The risk doesn't depend on whether the module still works, but on whether security fixes are still being published for it.

### How often should I check for available updates?

Regularly, though no single figure fits every situation. A reliable trigger is each security advisory published about an installed component, which means following those advisories rather than waiting for an alert from the host.

### Does an application firewall replace updates?

No, it complements them. It filters out some exploitation attempts, but an unpatched flaw is still a flaw: an application firewall narrows exposure, it doesn't remove it.

### Should I change my passwords even if nothing unusual has happened lately?

Yes, periodically, and always after sharing access with a third party, a contractor or a former team member who no longer needs it.

### Google or the browser still warns visitors after the cleanup. What now?

Once the cleanup is confirmed, a review request can be submitted through Google Search Console. How long the warning takes to lift then depends on how the request is processed. As long as the original flaw is open, a fresh flag remains possible within days: one more reason to fix the cause before asking for the review.