Torkil Johnsen

My personal piece of cyberspace

Collection of Joomla Security Tips

Posted in joomla,Security on Sep 18th, 2010

This is a post where I have collected a lot of tips and links from wherever I could find them. Originally I was going to wait for Joomla 1.6 to publish this and make sure to adjust the list according to what 1.6 will look like, but 1.6 is still in beta, and I grow tired of waiting, so this is a list targeted at Joomla 1.5.

Disclaimer: This post is not to be considered final by any means. Please help out people like yourself by adding more stuff to the comments or tweet them to me @torkilj, and I’ll update this list accordingly!

Table of contents

  1. Choosing a host for your Joomla site
  2. Installation
  3. Setting up and configuring the website
  4. Running the website
  5. Developer’s checklist
  6. What to do if your site gets hacked
  7. Further reading, other resources
  8. Acknowledgements

Choosing a host for your Joomla site

First of all, you should find a proper hosting provider. You could ask others in the Joomla community for their recommendations, and you could check out the shortlist of hosting providers on the Joomla Resource Directory. These have at least gone through a manual screening process where their server setup has been checked for the most common pitfalls.

If you’re considering a host, here’s a brief list of requirements that you can run by your hosting provider to see if they fit the bill:

  1. Secure communication

    Make sure your host supports secure connections. It will cost you around $30/year to get a 256-bit SSL certificate to secure your backend. If you need to transfer files, make sure that SFTP or SCP is an available option to you, instead of having to use plain FTP.

  2. PHP configuration

    • As with any software: Don’t use outdated versions, like PHP4
    • Disable potentially harmful PHP functions
    • Use open_basedir (with care, see comments after this article by Nicholas)
    • Turn magic quotes off
    • Don’t register globals
    • Allow users to set local php.ini files
  3. Apache configuration

    • Enable .htaccess
    • Enable mod_rewrite
    • Enable mod_security
    • Enable suPHP


  1. Connect securely

    Use SFTP or SSH when you connect to your server, and do not store your password in for instance your FTP client. This of course also goes for any subsequent connections to the server after you have finished your install.

  2. Follow your own best practices

    If you have already set up one site where you follow all the basic security measures you want to follow, and you have already implemented the security extensions of your choice, there is no need to reinvent the wheel: Use a backup tool like Akeeba Backup or something similar, take a backup of the site and use that backup as a starting point for your new site.

    Kudos to @hermanpeeren for the tip!

  3. Do not use the standard DB prefix jos_.

    Many SQL injection attacks are based on the assumption that your database tables are named “jos_”. In case you did use jos_, you can still change it with a simple PHP script.

  4. One database user per installation

    Do not give the same database user access to multiple installations, and do not use the server’s root user for your database connection.

  5. Consider db user password quality

    Use a long and complicated password for your database, and when installation is done, for your login. It’s too easy to decrypt an MD5 or SHA1 hash these day. There are even webapps that help you do it. If someone gets hold of your database of hashed passwords, it’s only a matter of time before they are broken. There are lots of good tips for password quality in this previous article I wrote, “How to create—and remember—a different password for every single login“, and there are also a lot of good tips in the article’s comments.

    In general, when it comes to passwords: Don’t write them down anywhere, and if you have to, at least store them securely.

  6. Don’t install sample content

    Sample content identifies you and your installation, and makes you easy to find and target. Don’t install sample content on what is to be a live website, because forgetting to remove absolutely all sample content is just too easy.

Setting up and configuring the website

  1. Use correct file- and directory permissions

    Avoid 777 of course. It seems this can’t be repeated enough times though. Extensions like suPHP will take care of setting proper permissions, so talk to your host and make sure they support it.

    This will also make the need for the Joomla FTP-layer redundant, so you won’t neet to use your FTP username and password anywhere.

  2. Uninstall stuff you don’t need

    Brian Teeman has a saying: “Nothing appears on my website that I didn’t put there“. Uninstall core components, modules, plugins, templates and other extensions that you’re not using, including templates and even images. Extensions on your website are all potential security liabilities, either because they add security holes or because they help attackers identify potential security holes.

    Observe for instance that installing the JCE WYSIWYG editor will also install TinyMCE, as it is bundled with JCE. Joomla comes with TinyMCE installed as it’s default editor, so then you’ll have two TinyMCE installations.

    Some core stuff can’t be uninstalled through the normal uninstaller. This is because they are marked as “core” elements in the database. In the components, modules and plugins database tables, there are fields called “core” which is set to 1 for these extensions. Change this value to 0 to make them possible to uninstall.

  3. Global configuration setup

    1. Disable registration/login

      If you don’t want people to register and/or login on the frontend, make sure you disable the functionality.

    2. Disable XML-RPC

      Disable the XML-RPC-server if you don’t need it.

    3. Replace default Joomla meta information with your own data

      Make sure you replace, or at least replace, the default metadata. These will show up in your sourcecode and in Google.

    4. Use SEF urls

      Regular URLs gives away the fact that Joomla is running your system. But then again, so can a lot of other things. Like for instance a template graphic, a static file, a code structure. Changing from regular to SEF URLs won’t render the regular URLs useless either, so this is not a very strong security measure. Make sure you also enable the .htaccess-file, see below.

    5. Move logs and cache outside the site root

      Change the log and cache paths in the administrator to a folder outside the site root so that they can’t be accessed through a web browser, or protect the folders in some other way.

  4. Remove generator information

    Remove the generator tag from the head-section of your website.

  5. Delete the default user account

    The userid 62 and the username “admin” represents a weakness, but there’s no easy way to replace these during installation. In the administration, the easiest thing you can do is to add a new super administrator, log in as the new super administrator, then demote the admin user to a lower usergroup and then delete the user all together. As our greek friend @nikosdion demonstrates, you can also fix this and add users below id 62 with some easy SQL.

    Here’s some quick SQL to help you change the user id and username of the default account right after installation:

    -- Change 3 in both queries with the userid you want
    -- Change jos_ with your own db prefix
    -- Change yourusername with your new username
    UPDATE jos_users SET id=3, username='yourusername' WHERE id=62;
    UPDATE jos_core_acl_aro SET VALUE=3 WHERE VALUE=62;
  6. Enable the .htaccess-file

    The default .htaccess-file has some basic security built in. In Joomla versions earlier than 1.5.15, you should also make sure it restricts access to critical files. In versions newer than 1.5.15 (1.5.20 is the latest version at the time this writing), you still have to uncomment parts of the .htaccess-file to activate this security measure. 

  7. Enhance the .htaccess-file

    Nicholas K. Dionysopoulos (that’s @nikosdion in twitterish) also has a nice Master .htaccess-file with lots of other goodies included, that’s really worth a peek. For instance: Restrict directory listings, force https on certain pages, blocking of some common exploits, file injection protection, fingerprint attack blocking, and more.

  8. Encrypt communication, or at least the login

    A nice article by Herman Peeren highlights the dangers of not logging in to your site with SSL, and suggests that if you can’t set up SSL you at least look into an extension called Encrypt configuration.

  9. Make fingerprinting your site harder

    One of the easiest ways for an attacker to decide if your site is a potential Joomla! target is to perform a rudimentary visual fingerprinting. Both Joomla! and PHP comes with many static resources, special features and even easter eggs that can make it easy to identify what software you’re using, and what versions they are.

    There is a great post in the October 2010 Joomla Community Magazine about this: “Only a ninja can kill another ninja“, by @nikosdion.

  10. Choose your extensions wisely

    1. Avoid extensions with encrypted sourcecode

      You can’t fix bugs in encrypted sourcecode yourself, and you’ll be left at the mercy of the extension producer should something bad surface. This is mostly a personal preference of mine, as I like probing around in people’s code both to learn and to get a general feeling for the actual quality of the software I’m running.

    2. Avoid dead extensions

      If a extension’s homepage is returning a 404 error, or hasn’t been updated in ages, it’s a good indicator that you should check out if this extension is still being maintained or not, before you decide to install it.

    3. Avoid legacy extensions

      Stick to extensions with fresh 1.5 compatible code. Joomla 1.0′s EOL has passed now, over a year ago, time to move on.

  11. Add extra layers of security

    1. Protect /administrator with extra measures

      You could require an extra password to access /administrator, or even restrict access to certain IP addresses. Some security plugins, like jSecure can help you accomplish stuff like this too. (thanks to @nikosdion again)

    2. Consider installing security extensions

      Lots of opportunities on the JED in the categories site protection, site monitoring and login protection. Many of these will help you with the items in this list.

    3. Monitor your site for unwanted changes

      Lots of tools can be used here, for example there is a Windows tool out there called Akeeba SiteDiff, which you can use with Akeeba Backup, and which will compare the state of your site with the last known good state. Read more about Akeeba SiteDiff.

    4. Add a custom ACL solution

      Joomla 1.5′s default ACL is not very restrictive, and you may be giving out more access privileges than you’d like. Brian Teeman has a nice table showing who gets to do what exactly. Consider adding a custom ACL solution for better access control.

  12. Avoid exposing information

    Disable the display of errors on live sites, so that system paths and server information is not shown. Set display_errors to 0 in a local php.ini for instance, or use php_value in a .htaccess-file.

  13. Don’t send out username/password in plain text e-mails

    Sending a plain e-mail is like sending a postcard; it’s not wise to include anything sensitive in it. Joomla does this by default (!) each time you add a new user to your users list, or when a user signs up.

    One way to avoid this is to override the language files; the text that goes out in the account creating confirmation e-mails is located in the language file, so this can be tweaked to not include the password.

    In Joomla 1.6 you can also override a single language string without having to create a whole language pack, which makes this easier. There is also a plugin for 1.5 called Translation Override, which may prove to be useful for this purpose. (thanks to @jlleblanc, @nikosdion and @ot2sen for the tips)

Running the website

  1. Stay updated

    There’s one newsfeed for Joomla Security News and one feed for news about vulnerable extensions.

    You should use the information to avoid insecure extension, because you can bet that those looking to hack your website are also keeping up to date with news on new vulnerabilities. – Read the result of Brian Teeman’s “Investigation of Exploits” from August 2010. – Read the vulnerable extensions list in the docs wiki, and subscribe to it’s feed.

    Note that you can also subscribe to changes on a wiki page like the one above, to be notified whenever it changes. If you go to the vulnerable extensions list and register an account and log in, you will get a button in the top menu that allows you to subscribe to changes on that page.

  2. Install security patches immediately

    Pay attention to mailing lists announcing insecure extensions and updates to extensions you’re using, including Joomla itself of course.

  3. Backup your site regularly

    If your server host does not do backups for you, you could backup your site to the cloud, or make good use of a backup extension.

    Make sure to test that the backup works and always store the backup off-site.

Developer’s checklist

  1. Use an IDE

    IDEs can help considerably with code quality, development and testing.

  2. Use a versioning system

    Stuff like SVN and Git will be a lifesaver the day something is hacked or modified without your knowledge, or goes to hell in another way. It also makes it easier to maintain and roll out different versions of your software. Use versioning even if you’re the only one doing development, it’s well worth it.

  3. Test locally, deploy globally

    Run different configurations for your test sites and live sites: Stuff that gives away information should never be done where it’s visible to the public, in particular debugging. Errors should not be shown on a live site, especially not those who disclose paths or system information. As an extensions developer though, all you can do here is probably just advise your customers. This type of setting has to be done on the server.

  4. Use CSRF-protection

  5. Don’t chmod files or folders to 777!

    Not only is this a bad idea security wise, it also tells people reading your code that you’re lazy at best, and furthermore that you don’t know what you’re doing.

  6. Filter data

    Filter data the user inputs and escape outputting of user-provided content, which is especially useful for preventing SQL injection and XSS attacks. Read more about this and see examples.

  7. Keep your codebase small

    Reuse previously road-tested code where you can, and stay DRY (Don’t Repeat Yourself). Less code equals less potential security risks and less code maintenance costs for you.

  8. Use Nooku Framework

    If you’re creating a Joomla extension, you should consider using Nooku Framework, which reduces your codebase with around 80% and does a lot of things automatically, where you in Joomla would have to write code manually. Directly related to security, Nooku gives you automatic CSRF protection (automatic form tokens and token control), automatic data filtering and soon also automatic output escaping by default.

  9. No executable code in class files

    In your class files, stick to one class pr file and leave no executable code.

  10. Use _JEXEC

    use a _JEXEC test in files, especially templates or files with executable code, to make sure the file is loaded from within the application. Files with just a PHP class in them do not need this.

  11. Keep names and versions hidden

    Don’t display extension names and versions in the code or on your site. “Powered by Superapp version 1.5″ on page footers that use your application, combined with a listing of Superapp version 1.5 being vulnerable on the list of vulnerable extensions, makes your clients easy targets. At least don’t display this info until Joomla gets a better upgrading system so that people can update outdated extensions in a painless manner.

    Worth reading in this context: New Software Notifications in Google Webmaster Tools.

What to do if your site gets hacked

  1. Take your site offline

    If malicious code has been injected into your site, you’d not want others to get their computers infected or compromised. For tougher cases: Add an IP filter so that only your IP-address can access your site while your fixing it.

    Remember: Offline does not mean unavailable

    Setting a website in maintenance mode is merely a visual thing that indeed will execute all plugins and component requests, but merely render the offline template. So if someone has found a loophole to get into your site, and you want to shut them out while you fix the problem, setting the site in maintenance mode will not help you.

    Nicholas Dionysopoulos published a blog post with information on this subject which is useful. He outlines one possible way around this issue, where he uses .htaccess to redirect all request to offline.html directly, bypassing Joomla completely. This means you have to have an offline-page of pure HTML to serve too of course. He also adds an exception so that you yourself can access the Joomla page from a specific IP-address.

    Read the original blog post for a more in-depth explenation and code sample.

  2. Find other people with similar errors

    First thing to do would be to search the Joomla forums or search the web to try to find scenarios similar or identical to yours. This can save you a lot of time in the recovery phase, since you may benefit from other people’s findings.

  3. Make sure your computers haven’t been compromised

    Malicious software on any computer with is used for accessing the site or it’s FTP accounts for instance, can be used by an intruder to gain access to your online user accounts. Use a scanner software to scan for malware, trojans, viruses, spyware, etc. A list of available software packages can be found in the Joomla documentation under “Local security”.

  4. Verify that you have the latest versions

    Check that you have the latest Joomla version and the latest versions of your extensions, and that you’re not using any extension versions with known vulnerabilities. See lists of vulnerable extensions on the Joomla documentation wiki and in the Joomla security newsfeed.

  5. Locate modified files

    Log in to your server and use the find command to find out which files have been changed recently.

    This command will list all files in the current folder where the file modification time (mtime) is less than three days old:

    find . -mtime -3

    This command will list all files in the current folder where the last change of file status (ctime) happened less than three days ago:

    find . -ctime -3

    This command will list all files changed at least one day ago but less than three days ago:

    find . -ctime +1 -a -ctime -3
  6. Find out what’s changed on your server

    If files have been modified on your server, or files have been uploaded for instance, you can check the timestamps on those files to find out when the attacker was on your site. This is typical in the case of sites being defaced or malicious code being injected somewhere. Most of the time, the attacker will have gained access to your site shortly before modifying or uploading files to it. By checking your access logs for the period around that time, you may find some clues as to how the attacker gained access and which IP-address the attack came from, thus enabling you to track down things more easily in the logs.

    You can also try searching for suspicious POST requests made to for instance non-form addresses on your site.

    Use any information gained from this to block out further attacks and patch weak spots in your system.

  7. Check your crontab/task scheduler

    Check your crontab and make sure there are no things in there that you didn’t put there yourself. If you can’t access your crontab or don’t know how to, ask your hosting provider for help.

  8. Report the attack to your host

    Get your host to help you flush out the problems and make sure the attacker has not left any hidden backdoors to make it easy for him to regain access to your site.

  9. Change your passwords

    Change passwords and, if you can, usernames to all access points to your site: MySQL databases, FTP users, administrators, SSH accounts, control panel logins, etc. Use strong passwords!

  10. Restore a working backup, or reinstall completely

    Wipe your server clean and roll back to a known, safe backup. Make sure all security holes have been patched before you reopen the site. You should also consider deleting the entire installation and just reinstall Joomla and your extensions from scratch, so that you are certain not to include any backdoors a hacker may have left behind prior to the attack.

  11. Report security issues you may find

    If you find soft spots in Joomla or any Joomla Extensions, report them on the security forum, but without outlining to the public how to hack one million Joomla sites in 10 seconds. Also contact extension developers directly to give them a chance to produce a patch for their users.

    When you report problems on the security forum, use the post assistant tool to make sure you include all the required information so that people are able to help you properly.

  12. Official tips lists

Further reading, other resources

  1. Read Nicholas’ blog

    Nicholas K. Dionysopoulos’ blog is currently, by far, the best source of new information on this subject.

  2. Follow Jeff Channel (@jeffchannel)

    Jeff has found several security holes both in the Joomla core and in well-known Joomla extensions. He tweets regularly about security, and you could probably also hire him to do a security audit of your extension.

  3. Joomla security forum

    Discuss at the Joomla 1.5 security forum.

  4. Security checklist

    Joomla official security checklist


Thanks to Brian Teeman for valuable input and to Nicholas K. Dionysopoulos for his numerous articles on this subject!

  • Mustaq

    Thanks for consolidating this so nicely ; )

  • JoeJoomla

    Great blog post @torkilj – I’m certain this page will be bookmarked by many, including me, for reference.

  • Nicholas K. Dionysopoulos

    As per your request, the story of open_basedir was detailed in PHP Security Blog over three years ago:

    Another thing is that if you use open_basedir=/home/user/webroot/ then scripts can no longer list the files and directories in the webroot (as they would be scanning /home/user/webroot, without the trailing slash), killing off the essential functionality needed for security scanning and backup. If you set /home/user/webroot then an attacker could create a /home/user/webroot2 directory, inject his nasty code and symlink to the regular root to access the nasty script, thanks to Joomla!’s .htaccess having +FollowSymlinks turned on by default.

    I should stop saying more on the matter now. I don’t want to give prospective hackers any more ideas.

    Disclaimer: no live server was harmed during the research of this issue :D

    • Torkil Johnsen

      As you can see Nicholas is one of the go-to guys on this subject ;)

  • Adriel Brunson

    Thank you for this list! Do you know of a Joomla security company that can be trusted to perform an assessment and follow through with the admin changes for several Joomla sites?


    • Torkil Johnsen

      I do not know of any company that brand themselves as a “security company” in the Joomlasphere, so I can only give you a couple of recommendations from my personal experience:

      During my time collecting this list, I have, as mentioned, used a lot of links from Nicholas Dionysopoulos. I know also for a fact that he is about to release a security oriented extension any day now. So visiting or sending a tweet to @nikosdion could be worth a try.

      You could also try talking to Brian Teeman,, or send him a tweet at @brianteeman. He did a security audit of over 1500 extensions a short while back, and in my impression he knows a lot about what to look out for.

      Hope that helps!

  • Jo

    As someone relatively new to Joomla! this post is worth it’s weight in platinum. Bookmarked and hope to see it kept up-to-date. :)

    Thanks very much.

    • Torkil Johnsen

      Thanks Jo, updated it today!

      Notifications on future modifications to this list will be tweeted from @torkilj ;)

  • Anonymous

    Great info. Going to pass on the link too.

  • Herman Peeren

    Handy collection! Thank you, Torkil.

    For nr. 19, password encryption, also see my article at

    I always use a basic-configuration from which I install a new site (using Akeeba to move my basic-Joomla!-installation to the local server where I work out the new site). So all kinds of security measures are standard in my basic installation and I don’t have to redo the same things all the time. You can put extensions like JSecure and Configuration Encryption standard in you own basic “distribution”.

    • Torkil Johnsen

      That’s a brilliant point. You just made it to #1 and #16 on the list :)

      • Herman Peeren

        Thank you for the very quick update of the list. You are so fast! (I ‘m a bit slow…). Feel honored to see the “basic-distribution”-tip on nr.1, but credits for that should for sure go to Nicholas: it is Akeeba that showed me the easy way to compactly backup a complete site including an installator. I don’t know if any other backup-extension has the same capabilities to do that so easy. I’ll write a small article about “making your own basic distribution” in the Joomla! Community Magazine.

        • Torkil Johnsen

          Haha, Nicholas already got so much credit on this page so I’m sure he’d be happy to share some with those spreading the word on his extensions ;)

          Make sure you post a link here to your article when it’s ready!

  • gnumax

    Good and recommended practices..


  • Coolbrenz

    Thank you… Very Nice Post…

  • Bill Rosner

    Very nice, thank you! I too will keep this bookmarked.

  • Anonymous

    Hi Torkil,

    Thank you very much for this precious list, it has very good stuff here.

    I’d add one more though: Akeeba SiteDiff tool, which allows you to verify if files contained within a backup are different from a previous one, very useful to check if files have been modified.

    • Torkil Johnsen

      Thanks, updated the list with a new #24

  • Torkil Johnsen

    Guys and gals: How many of the bullet points in this article do you think should be solved by Joomla by default? Going through a 45+ point checklist every time you do an install is just… Tiresome; if we wanted to do that we would have become pilots instead! :)

    Seriously: Shouldn’t Joomla start handling some of these out of the box?

  • Antonie de Wilde

    Two small additions to backups. The first is to test a restore of your backup so you know it works. The second is not to store backups on the server where your website is at, but at a different location. In the case of a hack you know your backups are safe, and you are also protected from any mistakes/problems of your hoster.

    Don’t save FTP credentials in the administrator backend.

    If you use Filezilla, note that this always saves the password of websites in plain text on your hard driver by default. A lot of of websites are hacked because of this. Search for fzdefaults.xml, and run Filezilla in kiosk mode.

    • Torkil Johnsen

      Thanks, good tips! Updated the list with backup info in #19 and the FTP-info in #22.

      • Nicholas K. Dionysopoulos

        There are also some tips pertaining to the use of Akeeba Backup Professional. If you are using the command-line backup.php script to run backups on a schedule and use a remote storage service (e.g. S3 or DropBox) you don’t have to store the password for the remote storage service in your configuration file. You can use the command-line options of backup.php (explained in the documentation) to pass the password. This way the password is only stored on your user’s crontab file which is not readable unless someone steals your hosting username and password.

        Further to that, there is the JPS format (encrypted archive) which stores all your information encrypted with AES-128 encryption. Again, you don’t have to store the encryption password in the configuration. You can either supply it at backup time —if you are using the back-end backup mode— or as a command-line parameter to your CRON job if you are using the backup.php script. Encrypted archives can be stored on the same server as your site, even though it is not recommended, as they are useless to an attacker if stolen.

        Finally, if you value your sanity, do yourself a favour and use encrypted connections. A 256-bit SSL certificate to secure your backend costs about 30$/year, albeit the major problem is configuring it on a shared host. Talk to your host about it. Never use plain FTP to connect to your site, especially if it uses the same username/password as your hosting account. Use SCP/SFTP instead, as these protocols encapsulate the file transfers within an encrypted SSH connection.

        If you are a complete paranoid like me, never EVER write down your passwords to post-it notes or your address book, never reuse the same password and never use an easy to guess password. Use a secure random password generator and store your passwords to encrypted storage. There is an abundance of cryptographically sound software to store your passwords, i.e. CodeWallet or SplashID. Surely, use a long master password, otherwise there is no point! If you are more paranoid than I am, buy an IronKey and use it to store your sensitive information. It’s military grade protection, but comes at an equally spicy price.

        • Torkil Johnsen

          Nice info, updated #4 and added #41

  • A.Jesin

    Point number 11 is very useful I never thought the user ID would pose a risk. Time to change it

  • Torkil Johnsen

    Just updated this list with 8 new points, a few more links and changed the text here and there based on some feedback from Svein. (thanks!)

    Most new stuff is about recovering after an attack. I could really use more input there!

  • joomlaserviceprovider

     jSecure hides your Joomla administrator URL with a special key so that only you can access. The problem with Joomla is that anyone can tell if your site is Joomla by simply typing in the default URL to the administration area (i.e. jSecure helps you hide the fact that your website is built with Joomla from prying eyes.

    Check out jSecure in action here: 

  • hariesdesign

    You must see this tips Joomla Security tips.

    It will explain how to protect your joomla folder

Creative Commons License
This work by Torkil Johnsen is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.