Brian's Blog Homepage
caricature of a shocked Brian Teeman looking at a checklist

Most website owners like to think about security in terms of preventing attacks. We install updates, choose strong passwords, enable extra protection and hope that nothing ever goes wrong. But the reality is that if your website is online, there is always a possibility, some would say probability, that something unexpected will happen.

Your website may be hacked. A server may fail. An update may break something important. The question is not whether these things can happen, but whether you are prepared when they do.

Prepare to be hacked is a detailed guide to help you plan for the day when your website needs rescuing. It is not a short checklist of things to do in five minutes. It is a longer read, but it is worth taking the time to understand the process before you actually need it.

When something goes wrong, panic and uncertainty are often the biggest problems. Having a plan, knowing what information you need, understanding how to respond and knowing how to recover can turn a disaster into a manageable inconvenience.

Take some time to read this article now, while everything is working. The preparation you do today could save you hours of stress, downtime and frustration in the future.

Hope for the best. Prepare for the worst.

Every website owner hopes they will never have to deal with a security incident. Most never expect their site to be hacked, their server to fail, or an update to leave their website unusable. Unfortunately, hope is not a recovery strategy.

Whether your website is a personal blog, an online shop or a business-critical application, there is always some level of risk. Hardware fails, software contains bugs, extensions become vulnerable, passwords are stolen and, occasionally, mistakes are made by the people managing the site. No website is immune.

The good news is that the damage caused by an incident is often determined less by the incident itself and more by how prepared you are to respond. A website owner who has recent tested backups, secure documentation and a clear recovery plan can often restore service in minutes. Someone who has never considered what they would do may spend days trying to recover if they can recover at all.

This article is not about preventing every possible attack. No security measure can guarantee that. Instead, it explains how to prepare for the day something does go wrong and how to respond in a calm, organised way that gives you the best chance of recovering your website quickly and safely.

Preparation begins long before anything goes wrong

The worst time to start thinking about disaster recovery is after your website has already been compromised. Decisions made under pressure are rarely the best ones. Preparing in advance means you can spend your time solving the problem instead of searching for passwords, trying to remember who hosts your website or wondering whether your backups actually work.

Your recovery plan does not need to be a lengthy document. Even a simple checklist is far better than having no plan at all. As your experience grows, you can expand and improve it, but the important thing is to have something ready before you need it.

Every recovery plan should include up-to-date contact details for your hosting provider, secure access to your hosting control panel, FTP or SFTP accounts, your database credentials and your Joomla administrator account. Store this information securely using a password manager rather than on pieces of paper or in unencrypted text files.

You should also have a simple maintenance page ready to upload if your website needs to be taken offline. Visitors are much more understanding when they see a professional message explaining that the site is temporarily unavailable for maintenance than if they are greeted with server errors or a blank page.

Perhaps the single most important part of your preparation is your backup strategy. A backup is only useful if it can actually be restored. Automated backups using tools such as Akeeba Backup make creating backups straightforward, but they should never be your only line of defence. Keep multiple generations of backups, store copies away from your web server and regularly test that they can be restored successfully. A backup that has never been tested is simply an assumption.

Equally important is having somewhere safe to restore your website. Restoring directly onto a live server should not be your first step unless it is absolutely necessary. A local development environment or staging server allows you to investigate problems, verify backups and test repairs without making the situation worse.

Stay calm and think before you act

Discovering that your website has been compromised can be alarming, particularly if it supports your business or generates income. The natural reaction is to start deleting files, reinstalling extensions or restoring backups immediately. Resist that temptation.

The first few minutes after discovering an incident are often the most important. Acting too quickly can destroy valuable evidence, make the recovery more difficult or even allow an attacker to regain access after you think the problem has been solved.

Take a moment to assess what has happened. Is the website displaying unexpected content? Have users reported suspicious behaviour? Has your hosting company contacted you? Can you still access the Joomla administrator area? Understanding the symptoms before taking action will help determine the most appropriate response.

Remember that not every website problem is the result of an attack. Hosting issues, failed updates, expired SSL certificates and configuration mistakes can all produce symptoms that look very similar to a security incident. Avoid jumping to conclusions until you have gathered enough information.

Contain the problem before it becomes worse

If you have good reason to believe your website has been compromised, your first priority is to stop the situation from getting worse. That means limiting any further damage to your website, protecting your visitors and preserving as much evidence as possible.

Whenever practical, place the website into maintenance mode. If you can still access the Joomla administrator area, enabling the site offline is the quickest approach. If administrator access has been lost or cannot be trusted, your hosting control panel may allow you to redirect visitors to a temporary maintenance page while you investigate.

If your website is distributing malicious content, redirecting visitors to phishing sites or attempting to install malware, take it offline immediately. Protecting your visitors must always take priority over keeping the website available.

At this stage, avoid making unnecessary changes. Resist the temptation to start deleting files or reinstalling Joomla. Every change you make removes information that may later help identify how the compromise occurred.

Tell the right people

Many website owners try to solve everything themselves before telling anyone. That is understandable, but it is often a mistake.

If the website belongs to a business or organisation, inform the people responsible as soon as possible. They need to understand what has happened, the likely impact and what steps are being taken. Surprises are rarely appreciated, especially if customers begin reporting problems before management is aware of them.

Your hosting provider should also be contacted at an early stage. They may already be aware of suspicious activity, they may have server logs that you cannot access and they may be able to isolate your account or help determine whether the attack originated elsewhere on the same server.

If you believe personal information may have been exposed, you should also begin considering your legal obligations. Depending on where you operate and the type of data involved, you may have responsibilities under regulations such as the UK GDPR or the EU GDPR to notify the appropriate authorities and affected users. Don't wait until your investigation is complete before considering these obligations.

Be honest with your users. You do not need to publish every technical detail, but you should communicate clearly if there is a possibility that their accounts or personal information have been affected. Clear communication builds trust far more effectively than silence.

Preserve the evidence

One of the most common mistakes after a security incident is immediately restoring yesterday's backup. While that may bring the website back online quickly, it can also destroy valuable evidence that could explain how the attacker gained access in the first place.

Before making significant changes, create a copy of the compromised website if possible. This includes both the website files and the database. Store these safely so they can be examined later if necessary.

Server logs are equally important. Access logs, error logs and security logs often reveal when suspicious activity began, which pages were accessed and, in some cases, the vulnerability that was exploited. Many hosting providers rotate or delete logs after a relatively short period, so collect them as early as possible.

If the incident turns out not to be a compromise, the time spent collecting this information will not have been wasted. If it was an attack, those records may prove invaluable.

Secure your accounts

Once the website has been contained and the initial evidence preserved, assume that any credentials stored on the server may have been compromised.

Start by changing the passwords for your hosting account, Joomla Super Users, database users and any FTP or SFTP accounts. If multiple administrators have access, make sure they all update their passwords as well. If your hosting provider supports two-factor authentication or passkeys, enable them immediately if they are not already in use.

Review every account with administrator access. Remove accounts that are no longer required and disable any that you do not recognise. Attackers will often create additional administrator accounts so they can regain access after the original vulnerability has been fixed.

Don't forget third-party services connected to your website. Backup destinations, cloud storage providers, SMTP services and API tokens may all need to be reviewed and regenerated if there is any possibility they have been exposed.

Understand what has actually happened

Before deciding how to recover your website, you need to understand the scale of the problem. Not every compromise requires the same response.

Look for unexpected administrator accounts, modified templates, unfamiliar extensions, recently changed files and unusual scheduled tasks. Compare the current website against a known good backup if one is available. Pay particular attention to the images, media and tmp directories, as attackers often hide malicious files in locations that receive less scrutiny.

Review your installed extensions carefully. Is everything still supported? Is everything fully updated? Have you left old extensions installed that are no longer being used? Forgotten software is a common point of entry for attackers.

Remember that the visible damage is not always the real damage. A defaced home page may be obvious, but a hidden backdoor designed to provide future access is often far more dangerous. Your goal is not simply to make the website look normal again. It is to understand why it was compromised and ensure it cannot happen again.

Choose the right recovery strategy

Once you understand what has happened, you can decide how best to recover your website. There is no single solution that fits every incident, and choosing the wrong approach can leave you with an insecure site or unnecessary downtime.

If only a small number of files have been affected and you are completely confident that you have identified both the vulnerability and every malicious change, repairing the existing website may be appropriate. This is often the quickest solution, but it also carries the greatest risk. Miss a single backdoor or malicious script and the attacker may simply return.

For most website owners, restoring from a known good backup is a much safer option. Assuming the backup was created before the compromise occurred, it provides a clean starting point and avoids the uncertainty of trying to identify every modified file.

Sometimes neither of these approaches is sufficient. If you cannot determine when the compromise happened, or you have reason to believe the attacker had access for an extended period, the safest option may be to perform a clean installation of Joomla and reinstall every extension from trusted sources before importing your content and media.

Although this requires more work, it provides the highest level of confidence that no malicious files or hidden backdoors remain.

Restore with care

Restoring a website is more than simply copying files back onto the server. Before putting the site back online, make sure you understand why the compromise happened in the first place. Otherwise, you may simply be restoring the same vulnerability.

If you are restoring from a backup, use one that you know is clean. This is where regular testing pays dividends. A backup that has been successfully restored and tested gives you confidence that it can be relied upon when you need it most.

After restoring the website, immediately update Joomla and every installed extension to their latest supported versions. If an extension has been abandoned by its developer or has a history of serious security issues, consider replacing it altogether rather than reinstalling it.

When copying media files such as images or documents from the compromised website, do so carefully. Although uncommon, attackers sometimes disguise malicious files as legitimate uploads or exploit weaknesses in upload directories. Copy only the files you actually need and review anything that appears unusual.

Find the root cause

Recovering your website is only half the job. Unless you identify how the compromise occurred, there is every chance it will happen again.

Start with the obvious questions. Was Joomla fully up to date? Were all extensions running supported versions? Were there extensions installed that were no longer being used? Were strong unique passwords in place? Was multi-factor authentication enabled for administrator accounts?

Review your server logs for unusual requests around the time the incident began. Look for repeated login attempts, requests to unexpected files or directories, or attempts to exploit known vulnerabilities. Hosting providers can often help interpret these logs if you are unsure what you are looking for.

If you discover that the compromise resulted from an outdated extension or weak password, fix that problem before bringing the site back online. If the cause cannot be identified, continue investigating. Treating the symptoms without addressing the underlying cause only postpones the next incident.

Review your security

Every security incident should lead to improvements. Once your website has been restored, take the opportunity to review your overall security rather than simply returning to business as usual.

Confirm that Joomla and every installed extension are fully up to date. Remove anything that is no longer required, including unused templates, extensions and user accounts. Software that is never used should not remain installed simply because it might be useful one day.

Review your file permissions and ensure that configuration files cannot be modified unnecessarily. Check that HTTPS is enforced throughout the site and that administrator access is protected with strong authentication.

Consider implementing additional security measures appropriate to your hosting environment, such as a Web Application Firewall (WAF), intrusion detection, malware scanning and automated monitoring. These tools cannot prevent every attack, but they can often detect suspicious activity long before a human notices that something is wrong.

Finally, review your backup strategy. Keep multiple backup generations, store copies away from your web server and test restoring them regularly. Your backup process should be so routine that recovering a website becomes an inconvenience rather than a crisis.

Learn from every incident

No website owner enjoys dealing with a security incident, but every incident provides an opportunity to improve. The most resilient websites are rarely those that have never experienced a problem. They are the ones whose administrators learned from previous incidents and improved their processes.

Document what happened, how it was discovered, how long recovery took and what changes were made afterwards. If you work as part of a team, review the incident together and identify what could have been done differently. A simple post-incident review often highlights weaknesses that would otherwise remain unnoticed.

Over time, these reviews become the foundation of an effective incident response plan. What begins as a basic checklist gradually develops into a well-tested process that allows you to respond quickly and confidently whenever something unexpected happens.

Final thoughts

Every website is vulnerable to failure. Whether the cause is a cyber attack, hardware failure, human error or a faulty software update, the question is not whether something can go wrong, but whether you are prepared when it does.

A well-prepared website owner does not rely on luck. They keep tested backups, maintain their software, protect administrator accounts, monitor their systems and know exactly what steps to take when an incident occurs.

You cannot eliminate every risk, but you can significantly reduce the impact of an incident. Preparation, careful planning and a calm, methodical response will almost always produce a better outcome than rushing to fix the visible symptoms.

When the unexpected happens, your recovery plan may turn out to be the most valuable piece of documentation you have ever created.

J o o m l a !

Brian Teeman

Brian Teeman wearing glasses and clean shaven

Who is Brian?

As a co-founder of Joomla! and OpenSourceMatters Inc I've never been known to be lacking an opinion or being too afraid to express it.

Despite what some people might think I'm a shy and modest man who doesn't like to blow his own trumpet or boast about achievements.

Where is Brian?

custom converse sneakers in the joomla colour scheme with the text joomla rocks embroidered on the heel