Monday, November 29, 2021


Joomla! Websites Showcase


For articles, tips, hints, tools, videos and much more relating to Mobile Phones, and the mobile phone industry, visit. . .

For more about the travels of the Website developer, visit . . .

header copy
For images, hints and tips on New Zealand postage stamps and philately
Philately co nz

Downtown San Francisco


Internet Search

Long Read

There are many good pieces of advice available with regards to good practices in keeping your Joomla!® website safe and secure.

Much of those pieces of advice are consistent - would like to give you some tips and advice here.

Why do we want, or need, to keep our website safe ?

  • To maintain our own control and ownership of our website;

On a shared server, in particular, where you share the server with other hosting company clients - a compromised website can affect the stability of the entire server - including other people's websites.

You do not want another person's website to affect the operation of your website - and the other way around too;

How can our website be compromised ?

  • We protect our home(s) and computers from hack*ers and in the same way we need to protect our website(s) from unscrupulous persons;
  • A website can be breached - data can be accessed illegally;
  • Your website could be taken over (hijacked) - you lose access to the administrator area and you cannot recover it;

ListHere is our list of Best-Practices, in no particular order:

Let us expand on those items above.

Back to topBack to top of page

Choose a good web-host

A good web-host will take security very seriously, and will indeed be very proactive in ensuring their servers are secure - but it is your responsibility to ensure your website is secure.

Read reviews.

Seek recommendations from people (developers) who you trust and who themselves are held in high regard.

ListBack to list of Best Practices

Back to topBack to top of page

Use the latest stable version of Joomla

Joomla gets updated at intervals - many updates are for new or improved features - but if a vulnerability is identified an update may be solely for security fixes and remedies.

Typically, when a security vulnerability is identified it will be remedied with a new release of Joomla before any details are released into the public domain of that vulnerability.

In the case where a release contains a security fix - it would be very important to update your Joomla install promptly because the release change-log will most likely explain what and where the vulnerability is.

An unscrupulous person could then attempt to find Joomla powered websites that have not been updated and still contain the said vulnerability.

ListBack to list of Best Practices

Back to topBack to top of page

Use the latest stable release of extensions

For exactly the same reason(s) above as using the latest stable release of Joomla.

ListBack to list of Best Practices

Back to topBack to top of page

Use extensions that are recently and regularly updated

An extension that is not recently updated by the developer(s) of that extension - say several months ago - may contain one or more vulnerability.

An extension that has not been updated by the developer(s) of that extension, for say several months - may be an extension that is no longer be supported/developed.

An extension not updated recently by the developer(s) of that extension may not be compatible with the latest stable version of Joomla or the latest versions of PHP that are used on your server.

ListBack to list of Best Practices

Back to topBack to top of page

Keep File and Folder permissions appropriate

File and folder permissions can, broadly, be classed as determining Read, Write, and Execute rights for the file/directory.

Only certain levels of access should be able to write, and likewise read or execute a file.

ListBack to list of Best Practices

Back to topBack to top of page

Use a Web Application Firewall

Using a Web Application Firewall (WAF) is like using a filter.

While a WAF is used to help provide real-time protection against common attacks, it should always be borne in mind that NO security system is 100% effective 100% of the time.

A good security feature is always being developed and adapted to suit current trends and technologies.

A Web Application Firewall (WAF) can be used to help:

  • Give protection against SQL Injection attacks;
  • Give protection against Brute Force Attack;
  • Provide Login Protection;
  • And much more;

ListBack to list of Best Practices

Back to topBack to top of page

Take Regular Backups

How regular is regular ?

How much work or data can you "afford" to lose ? 2 hours work? Two day's work ?

Do you have an eCommerce website with one or two sales taking place hourly ? Or hundreds of sales per hour ?

The above, hopefully places some form of "scale" to your back-up approach.

There are times when you should backup your website as a matter of routine:

  • Before, and again after carrying out an extension update;
  • Before, and again after carrying out a Joomla update;
  • If you write several articles each day - carry out a backup before and after each article;
  • If you make several sales from your eCommerce website every hour - carry out a backup every 1/2 an hour.


Carrying out a back-up and restoring that back-up is much, much less trouble than losing several hours work, or any amount of sales information.

The good news is:

Carrying out a backup does not have to be a burden.

If you use a great web-host and Akeeba Backup Professional you can schedule your backups to take place - even to take place while you sleep, eat, socialise - by using a CRON schedule.


If you are a user of Akeeba Backup for Joomla, when Akeeba Backup carries out a Backup you will most likely use the "Default Backup Directory" - this is where your backup goes.

The location of the default backup directory is well documented.

The drawback of this - "hackers" have a fair chance of attacking this location and abuse your backups.

The good thing with Akeeba Backup - you can configure where the backup goes - a good place in your hosting diectory tree is to create a uniquely named directory (folder) above public_html which by definition is inaccessible over the web, and significantly harder for the unscrupulous to guess and find.

ListBack to list of Best Practices

Back to topBack to top of page

Use difficult to guess usernames and passwords

Do not use words from a dictionary as either a username or password.

There are software programs that can be used to attempt to find a password.

Dictionary words are quite easy for a computer program to work out: the word "Dictionary" could take a computer approximately 1 month to determine. The word "Joomla" could take a computer program approximately 500 milliseconds (that is 1/2 a second !) to determine.

There are some excellent tools available to help you create a strong password one such tool is this StrongPasswordGenerator


Do not use (or allow) a Username of, or similar to the following as these can be easy to "guess":
- Admin
- admin
- Administrator
- administrator

The "default" Joomla Super User id should be changed as you are setting up your joomla install


Do not use a Username or Password that you use on another website - either for the Administrator area or the "front-end"

Seriously - good advice that can never be repeated too often !

ListBack to list of Best Practices

Back to topBack to top of page

Have your website served over HTTPS with an SSL certificate

HTTPS is a secure encrypted form of website delivery to your browser.

Installing and setting up an SSL certificate used to be a time consuming and expensive process.

However now it can be very easy and either free of charge or very cheap.

Some web hosts even offer clients the option of a free LetsEncrypt SSL certificate and the host will even set it up for you and renew it when required.

One such web host is SiteGround - their cPanel allows you to simply choose "yes" for an SSL against your cPanel domain name.

ListBack to list of Best Practices

Back to topBack to top of page

Protect the Administrator area login

Joomla, by default, has access to the Administrator area login panel by a commonly known URL (web address).

Any hack*er who wants to have a go at your website simply needs to use this known url - he / she does not even need to know your site is using Joomla - attack several hundred websites and if one gets him / her the login URL part of his / her job is done !

There are security tools available that will allow you to protect the administrator area URL so that the administrator area URL is known ONLY to you.

ListBack to list of Best Practices

Back to topBack to top of page

Use Joomla Security Extensions

All of the above might seem like a lot to do - individually, perhaps it is a lot to do.

There are however some excellent security tools available that can do a lot of the hard work.

Here at we highly and strongly recommend:

If you want to read our articles on the above three items, you might like to visit:

ListBack to list of Best Practices

Back to topBack to top of page

When using FTP client Use SFTP

When transferring files via FTP (File Transfer Protocol), for example when using cuteFTP, to transfer files between your website and your local computer, or vice-versa, the files could be intercepted between your server and your local computer.

Using SFTP (Secure File Transfer Protocol) will help greatly in protecting your files being transferred by encrypting them during "transfer".

ListBack to list of Best Practices

Back to topBack to top of page

Do not keep backup archives within your website

A website backup package / extension may place your website backup archive in a backup output directory within your website directory structure.

There are two reasons why you might want to consider not keeping website backup archives within your website directory structure:

  • The backup archive takes up an element of your allocated server space;
  • In the event of your website becoming compromised - your backup archive may become accessible to someone you do not wish it to be accessible to;

So, what should you do ?

Take your backup - let it go to an output directory / folder within your website directory structure - if  that is what it does, and then:

  1. Using your FTP Client download the backup archive to somewhere of your choice, for example to your local PC, or external hard drive, and then
  2. Returning to your website administrator area, go to the backup archive folder and delete the archive;

Or, as a bonus, the Backup software package we use here at, any number of "Profiles" can be set up. Within any profile the backup process can be configured with Post-processing.

Post-processing allows for the backup to be transferred to a remote storage facility such as:

  • Amazon S3;
  • OneDrive;
  • CloudMe;
  • RackSpace Cloud Files;
  • DreamObjects;
  • OVH object Storage;
  • SugarSync;
  • WebDAV;
  • Google Drive;

ListBack to list of Best Practices

Back to topBack to top of page

Keep more than one copy of each of your backup archive(s)

If we keep only one copy of our backup archive - lots can happen.

  • The hard drive can fail - we have lost our backup stored on it;
  • The hard drive can become damaged - for example: water damage, fire.


Paranoia can be your friend !

Keep multiple copies of each backup archive on / in physically separate places / drives.

If you keep a copy of each backup archive on, for example, five physically separate drives - what are the chances of all five drives failing, or becoming damaged ?

Slim ?

Here at we keep a copy of every backup archive on five physically separate hard drives.

There are some excellent External Hard Drives available via Amazon

ListBack to list of Best Practices

Back to topBack to top of page

Keep backup archives for a period of time

Set yourself a minimum period of time over which you keep your backup archives.

Why ?

On occasion it might be conceivable that a backup archive might become corrupt - for example if a hard drive begins to fail.

Here at we retain backup archives for a minimum of 12 months.

ListBack to list of Best Practices

Back to topBack to top of page

Test your backup

You have done all your hard, time consuming work on your website, you are rightly proud of it, taken your website backup, saved a copy of your backup (on more than one physically separate hard drive !) - but - do you know that your backup is all good ? Have you tested it ?


Waiting until you need to restore your website from a backup is not the time to find that your chosen backup does not work !

How can we test our backup ?

In a nutshell - there are two ways: The first one below is the preferred method for us here at

  • Create a (password protected) "Test" directory within your hosting account and restore your backup to that directory, using a separate database created specifically for restoring your backup to;
  • Download and install a "local web-server", such as XAMPP and restore your backup to the local web-server. There are some "ifs and buts" associated with this method which are outside the scope of this article, but never-the-less is an option.

ListBack to list of Best Practices

Back to topBack to top of page

public_html Directory And Security

It is beyond the scope of this article to explain in great depth "what" the public_html directory does. Directory structure(s) and "permissions" can be an encyclopaedia (en-US: encyclopedia) all on its own !

In summary:

The most insecure directory on a UNIX server is the one serving Web files, usually called public_html. This is because it is generally publicly accessible, and possibly writeable.

That status is the very definition of insecure.

If there is any weakness (vulnerability) in any file within your public_html directory, your entire hosting account is potentially at risk (vulnerable), and not just one of your Web sites but possibly every Web site in your hosting account (if you have a hosting plan that allows you to host more than one website).

Such vulnerabilities give attackers access to the scripting used to run your site. If one website gets infected, like any medical virus - the virus placed into one of your websites within public_html directory could also pass into another website (Addon domain) within the SAME public_html directory.

In the directory structure, what is above (or outside) of your public_html directory is not so easily accessible via a web browser - on that basis, each addon domain can be placed below its own unique public_html directory. How to achieve this structure is beyond the scope of this article - but perhaps gives you food-for-thought.

ListBack to list of Best Practices

Back to topBack to top of page

Session Security

How many times do you start doing something - filling in a form, checking your bank account (the list could go on) on a website, any website, and you get interrupted ?

  • Dinner;
  • Phone call;
  • Important email that you MUST answer;

An hour later you remember what you were doing before the interruption - go back to it and one of three things has happened:

  1. Nothing - it is just as you left it;
  2. You are still logged in - and some prying eyes and fingers have wreaked havoc;
  3. You have been automatically logged out;

Number three above is probably the best of the three cpossible outcomes.

When a user logs in (including a Super User logging in to the Administrator area) a "Session" starts - you have a Session Cookie set on your browser. After a period of inactivity - when you, or your logged in user, has "done nothing" - literally - you, or your user, will then be logged out.

This is referred to as the "Session Lifetime" - this is adjustable - and is measured in minutes. Here at we recommend setting this to as low as possible - 15 minutes tends to be ample for the vast majority of users. This is the inactivity period - if you are working away you can get passed the 15 minutes without becoming automatically logged-out.

So, setting this low will reduce the chances of a user getting interrupted and having their account compromised - or even from "someone" sending that impolite message through your Contact Us form !

ListBack to list of Best Practices

Back to topBack to top of page

Update And Secure

This final section is really a combination of other sections above.

Would you secure a seriously outdated building ?

Just asking.

If "Yes" - perhaps an excercise in futility.

Would you wait until someone walks into your home and removes your posessions before locking your doors ?

There are many gaps and weaknesses in a seriously outdated website.

Get updated.

Get secure.

houseAn excercise in futility ?

ListBack to list of Best Practices

Back to topBack to top of page

Change the Meta Generator Tag

Your Joomla site always comes with a default meta generator tag to show that your website is a Joomla site, and sometimes it will show its version as well.

Finding the Meta Generator Tag - is very easy - simply by viewing the website source code - right click, select view page source

Some "unscrupulous persons" will look for and attack Joomla! powered websites, and your Meta Generator Tag - can reveal exactly what "they" are looking for.

If a known vulnerability exists in a specific Joomla! version - the unscrupulous can search out websites built using that vulnerable version and take advantage of the weakness.

It is possible, and advised, to change this for security measures if you do not want others to know you have built a Joomla site and what version it may be.

ListBack to list of Best Practices

Back to topBack to top of page

Pro-active Versus Re-active

No security plan or system is ever 100% guaranteed.

The unscrupulous can often be one-step-ahead.

However - arguably, the best approach is to be Pro-Active and dynamic.

Even if we are on the right track we can get run over if we just sit there !

ListBack to list of Best Practices

Back to topBack to top of page