How to check for website vulnerability with a security audit

Batten down the hatches

The whole point of a website security audit is to give you and your clients peace of mind. Knowing that you have gone through a client’s site, eliminated any website vulnerability you identify, and secured the site should bring a smile to your face.

Related: Making website maintenance plans a requirement for all clients

Why should you regularly check for website vulnerabilities?

The No. 1 reason to do regular security audits is the potential losses from not doing them. If there is a security breach, it can be costly to fix. Costly not only financially, but in time used saving face and saving your customers.

Other reasons for performing a security audit:

  1. Hackers never stop trying to get in. It doesn’t matter what your site is about, they will still try to hack into it.
  2. Updates and development changes often introduce bugs and potential vulnerabilities.
  3. Hacked websites decrease your credibility and reputation.
  4. You owe it to your customers to keep things secure.

Related: Understanding Online Security Threats

How to perform different types of security audits

The audit can be as long or as short as you like. I’d rather be safe than sorry, so this list is a little long. I’m sure in some cases though, like dealing with HIPAA requirements, more security and longer lists should be followed.

A free Sucuri scan will quickly tell you if you have any malware or if your server has been blacklisted.

Website Vulnerability sucuri
Photo: Sucuri Sitecheck Landing Page

Jumpstart your audit with a free Sucuri scan. It will quickly tell you if you have any malware or if your server has been blacklisted. If your server’s IP address has been blacklisted, let your hosting company know. If the scan reports that you have malware and you host on GoDaddy, they have an article written to walk you through the cleaning.

Editor’s note: Want an easier way to get rid of malware? Check out GoDaddy’s Express Malware Removal for expedited, complete cleanup, plus ongoing protection to stop malware from coming back.

Some of the server-side things are out of your control using shared hosting, and the majority of hosting out there is shared. Your hosting company is in control over things like updating PHP to a current version. If you notice that it is out of date, just ask them to upgrade it and there is a good chance they can do that for you. Nonetheless, I have such things listed just in case you are managing your own VPS.

Related: How to handle malware detection on your website

Here are the checklists:

Checklist for server audits

  1. Install available security updates for the server’s operating system (often Windows Server or Linux).
  2. Update backend software like PHP and MySQL. For example, PHP 5.6 is about to expire and it will no longer receive any updates. Which means any security holes in PHP 5.6 will never be fixed. Check your version of PHP against this list. This applies not only to PHP but to any scripting language that is on the server.
  3. Verify that network traffic is firewalled except only for necessary application and service ports. For example, a web server only needs port 80 (non-SSL) and 443 (SSL) to serve up pages, so closing all of the other ports makes sense.
  4. Only use SFTP (or SSH): Non-secure FTP doesn’t encrypt the username and password that is sent. If you’re at a coffee shop, someone could “sniff” the traffic at the shop and capture your username and password.
  5. Regularly backup your files and databases. This, many times, is covered in managed hosting, but not shared hosting. If you are using shared hosting, use a service like ManageWP to backup a WordPress installation.

Related: Guide to choosing a website firewall

Checklist for database audits

  1. Use individual user accounts that limit database privileges per application. There shouldn’t be a MySQL user that has access to other databases. This way, if one application gets hacked, other applications aren’t affected.
  2. Sanitize all user input when processing forms that insert data into the database. Using something like Ninja Forms or Caldera Forms in a Content Management System like WordPress will solve this issue. If it is a custom form, you will need to inspect the form and make sure it sanitizes the data.
  3. Force SSL on your web site. This is important for multiple reasons, first the security risk of sending sensitive data unencrypted, but secondly because Google is starting to hinder sites that aren’t using SSL.

Related: How to enable HTTPS on your server

Checklist for application or CMS audits

  1. Stay up to date: Keep WordPress or whichever CMS you are using up-to-date. Keep the plugins and extensions up to date also. WordPress does auto security updates, but plugins do not.
  2. Disable Debugging: Make sure your site does not have debugging enabled. Turn debugging off when you aren’t debugging.
  3. Enable Captchas: Make sure forms on your website use anti-spam techniques like a CAPTCHA service.
  4. Force SSL: Again, this is critical for multiple reasons.
  5. XSS injections: If your website has any kind of interactivity, like forms, check for instances of possible Cross site scripting injections in your website.
  6. Require strong passwords: WordPress somewhat recently required stronger passwords and you should never disable that. In fact, there will be a time when 2FA is required everywhere. In WordPress, there is a way to implement it now and it is relatively easy.
  7. Limit and track: Limit login requests, track failed logins and ban repeat offenders. In the WordPress world, we use a plugin like Limit Login Attempts Reloaded to handle this.

Related: WordPress Security Resources

What happens after the security audit?

Now that you have gone through the list, you probably have some research to do and some things to fix. But don’t think that you only need to do this once. Most major companies go through an audit yearly. Maybe once a year is enough for you, but there is nothing wrong with more often. So adjust to what you are comfortable with.

Always remember, if you make major changes to the site, for example change from one CMS to another, you should go through that list again and make sure all things are still secure.