Websites

Your website is your gateway to the world and, at (many) times, the entry vector to your network or customer database for a malicious actor. It only takes one flaw for someone to exploit the website, thus exposing the backend database, which should be for trusted employees only. Data exfiltration is not the only worry—uptime (the A in CIA [not Langley]) is another concern. If your website turns over hundreds of thousands of pounds daily, then it being offline for eight hours will lose you cash.

Patch, patch, patch
Why is ‘patch’ written three times, you may wonder? You need to patch the server & software, the core web application (maybe a CMS), and any plugins. Some CMSs and operating systems (Linux) can download & patch themselves to some extent. Monitor all areas weekly and patch quickly. Subscribe to vulnerability emails for the products you use.

Filter inputs
The third top attack is injection, which lets an attacker query the database (LDAP & more), and even add records to it. XSS, CSRF and others are dangerous for a different reason. Your web application, server and WAF need to filter out bad strings. If a field is for a phone number, then A-Z or special characters are not at all needed. Do not just use your WAF to filter; do it at different layers.

Be conservative with error messages
Buildings do not shout out how many staff they have inside or what defences they have, so your website does not need to either. Strip out any reference to what operating system or web application you are using. Errors should not say Joomla version 5.1 or Apache version 2.4. Such poor errors could give an attacker helpful snippets.

Pen test it
Before going live, have an unbiased 3rd party expert test your web application. That is not to have them run just an off-the-shelf tool you could do yourself but to have them test it manually as well. Have them follow the OWASP Top 10 as any competent tester would. Do not let the whole exercise be a top management tick box to move through your internal gating process. It should not be a one-off exercise but run on the whole website more than yearly.

Peer review or scan your code
Ask five people a question, and you get five different points of view. Most coders are not security bods, and most security bods are not coders. All code should be reviewed by 1-2 other coders to spot flaws, and ideally, they should understand secure coding. If you are a one-(wo)man coder, use a code scanner or outsource reviews.

TLS up your website
Many people will say to use the HTTPS everywhere method, but that is a rather high-level statement. You could turn on SSL v3 without knowing. You should be using TLS 1.2+ without SHA1/RC4/3DES/CBC. Use the HSTS security header in tandem with other headers.

Turn on security headers
Content-Security-Policy, HSTS, Referrer-Policy and X-Frame are just to name a few. These usually force the end user’s browser to do something. They can be injected at different levels: the web application, web server, WAF, load balancer and elsewhere.

Scan and filter file uploads
Uploaded files are bad for two reasons: 1. They could infect your web server, and 2. They could infect your end users. You should filter files end users can upload, i.e. block .exe, .msi, .docm, .ps1 etc. Do not just rely on the file extension; since these can be changed, look at the file headers. On top of this malware, scan files and use more than just a single engine.

Block directory browsing
A schoolboy (or girl) error is to upload non-public files to a web server and then leave directory browsing on. Firstly, do not upload non-public files and, anyway, disable directory browsing so people cannot view the contents of a directory. HTACCESS has rules to assist you and use an index file as well.

Firewall non-essential ports
Web traffic is served over 80/TCP or 443/TCP for encrypted traffic (TLS). End users do not need to see or use anything else. The admin control panel (if you use a control panel – try not to) port and SSH or RDP should be locked down to the IP addresses of your corporate network.

“Encrypt” your passwords and more
The word encrypt has quotes around it for a reason. Encryption is reversible, but hashing is one-way encryption and cannot be technically reversed, though due to pre-computation, it kind of can. You should be using SHA-2 at a minimum and ideally higher, along with salting. On top of this, you can use real encryption, too, but be careful where you store the encryption key – an HSM would be nice!

Change the defaults
As with anything if the default username is admin rename it, delete it or if you cannot, put two-factor authentication on it. Go through all settings with a fine-tooth comb and tweak them. Many CMSs use a default login directory like /administrator for Joomla—everyone knows it exists, so stick a username/password on the whole directory.

Proper authentication and/or IP whitelisting
In 2025, people at some corporations are still rolling out externally facing websites or services with just a username (often to make it easy an email address) and password. Tonnes of flaws exist in this method. Avoid obvious usernames like email addresses or initialsurname, and use usernames that include numbers, too. Two-factor should also be used, though it can be defeated, so why not just IP filter the folder or username back to your corporate network?

Chmod everything
As with a conventional folder or file on Windows, it is not available to everyone, nor does everyone have full rights to it. Files and folders should have minimum permissions, and especially not 777 (full permissions) on everything. Block execution on file uploads to prevent them from executing once uploaded. Chmod should apply to both public web directories and local server directories.

Be careful of 3rd party plugins
The core of Drupal, WordPress, or Joomla may be “fairly” secure, well-patched, and vetted. 3rd party plugins are not vetted and could be insecure and/or not vetted. Just look into “vsftpd”, which was backdoored. If you are going to use a 3rd party plugin, research its history and manually review the code before you install it.

Vet your hosting provider
You could have the most secure website in the world, but there is always a weak link in the chain. If you have your own dedicated standalone server, great, but shared hosting or a VPS means you share everything with tens or even thousands of other websites. A breach of one of them could leak over to your container or blacklist the whole IP address.

Use a web application firewall
A normal firewall is just interested in ports, protocols and the state (SPI) of the connection, whereas a WAF is only interested in port 80/443. It can block known SQL injection attacks and filter known attacks against Joomla, WordPress, Drupal and more. If you use one, configure it based on your setup—don’t just leave the defaults on, as many do. WAF’s on-premise or SaaS can help with DDoS mitigation, though on-premise ones can get overloaded far more easily.

Tweak your PHP settings
PHP, a massive programming language, has hundreds of functions and is controlled by a file called “php.ini”. Present settings are security and non-security-focused. “shell_exec” and “system”, along with many more, can allow a shell to be executed. Even if an attacker managed to upload a PHP backdoor, if you have the right functions turned off, it would not execute.

Use a specialist website vulnerability scanner
If you are a small business and cannot afford up to £1200+VAT/day for a pen tester, you can use a website-focused vulnerability scanner instead. These often cost the same price as a day’s testing and will last a year. The secret is that pen testers use these tools! Have it scan all your pages and forms, especially to find OWASP flaws before the attackers do.

Backup your website
You have spent days or months building your website, and in a second, you could delete a folder by error or have it defaced. Have a copy at the web host and on-site so all your eggs are not in one basket. Your backup should include the full set of files & directories, plus whatever type of database you are using. If it is mission-critical, have it replicated and take snapshots multiple times per day.