Website security guide: where should you start?

• Website Security
• Updated: 4 October 2026
• About 10 min read

The framework in four steps

1. 1

   Know the threats

   Threats to websites fall under a few main headings: user input being processed as code or as a query (SQL injection, XSS), abuse of a user's session (CSRF, session hijacking), a malicious file being placed on the server (web shell), password guessing, known vulnerabilities in outdated software, a misconfigured server, and heavy traffic that makes the service unreachable (DDoS). The OWASP Top 10 list compiles these risks regularly; injection and access control failures are among its constant themes.

   : Enlarge

2. 2

   Build a layered defence

   No measure is enough on its own; if one layer is breached, the next should limit the damage. Think of five layers: code (input validation, output escaping, prepared statements), server (up-to-date software, correct permissions, security headers), access (strong passwords, two-factor authentication, least privilege), backups (copies that have been proven to restore) and monitoring (logs, file changes, alerts).

   : Enlarge

3. 3

   Work in order of priority

   You cannot do everything at once. Start with the tasks that reduce the most risk for the least effort: first updates and passwords, then backups, followed by HTTPS and security headers, clearing unnecessary files from the server, and finally reviewing the code and setting up monitoring. Code review takes the most effort, but for software written specifically for you it delivers the most lasting result.

   : Enlarge

4. 4

   Review regularly

   Security is not a job you do once and finish. New plugins are installed, staff change, software ages. Keep things in order with short weekly, monthly and yearly checks; for a ready-made list you can use the Website security checklist guide.

   : Enlarge

Threat types and related guides

• SQL injection: User input becomes part of a database query; this can lead to data leaks and data being altered. What is SQL injection and how do you prevent it?
• XSS: Unwanted script that runs in the visitor's browser gets into the page. What is XSS and how do you prevent it?
• CSRF: The browser of a logged-in user is made to perform an action without the user knowing. What is CSRF and how do you prevent it?
• Malicious file uploads and web shells: An executable file is placed on the server. File upload security and web shells
• Password guessing and session problems: Login and session security
• Missing browser protections: Security headers and HTTPS
• Heavy traffic and bots: DDoS and bot attacks
• Outdated software and plugins: Software updates and plugin security and, if you use WordPress, WordPress security
• Misconfigured server: Server and hosting security
• Data loss and late detection: Website backup and monitoring
• If an attack has happened: What to do if your website is hacked

The layers in detail

Code

The basic rule is this: do not trust any data that comes from the user, the address bar, a cookie, a file or another system. Validate data when you receive it (is it of the expected type and format?), use prepared statements when you send it to the database, and escape it according to its context when you write it to the page. Check authorisation on the server for every request; hiding a link in the menu is not an authorisation check.

Server

The operating system, web server, PHP and database should be on current, supported versions. Directory listing and on-screen error display should be switched off, backup and configuration files should not be left in the web root, and file permissions should be no wider than necessary. The small .htaccess block below gives you a few quick wins; you will find the details in the server and headers guides.

# Switch off directory listing
Options -Indexes

# Block outside access to files starting with a dot (.env, .git, .htpasswd)
# and to backup/dump extensions
<FilesMatch "(^\.|\.(sql|bak|old|orig|log|ini|sh|swp)$)">
    Require all denied
</FilesMatch>

# Basic security headers
<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Access

The hosting panel, FTP/SFTP, database and admin panel accounts should each have a separate, long and unique password. Turn on two-factor authentication wherever possible. Give each person their own account; do not use shared accounts, and close the access of anyone who leaves on the same day. For account security, see the Strong passwords and password managers and Two-factor authentication guides.

Backups

There should be regular, automatic backups of the files and the database, stored off the server. A backup that has never been restored is a backup that is not known to work; run a test restore at set intervals.

Monitoring

The earlier you notice an attack, the smaller the damage. Look at the access and error logs from time to time, watch for unexpected file changes, set up monitoring that checks the site's availability from outside, and keep an eye on the security issues report in Google Search Console.

The first ten tasks for a small site

1. Update the content management system, plugins, themes and PHP version; remove anything that is not in use.
2. Replace the hosting panel, FTP, database and administrator passwords with long, unique ones.
3. Turn on two-factor authentication for administrator accounts.
4. Set up automatic, off-server backups of the files and the database; try restoring once.
5. Redirect the whole site to HTTPS; confirm that the certificate renews automatically.
6. Use SFTP or FTPS instead of plain FTP.
7. Remove backups, archives, .sql, .env, phpinfo and similar files from the web root; switch off directory listing.
8. Disable script execution in upload folders.
9. Add the basic security headers.
10. Turn on uptime monitoring and Search Console notifications.

Questions to ask if someone else develops the software

If your site was written by an agency or a freelance developer, you need to know the answers to these questions:

• Are all database queries written with prepared statements?
• How are passwords stored? (Expected answer: password_hash or an equivalent; MD5 and SHA-1 are not acceptable.)
• Do the forms have CSRF protection?
• If there are file uploads, which types are allowed and where are the files stored?
• Which libraries and versions are used, and who keeps track of their updates?
• Where are the backups, how often are they taken, and when was a restore last tested?
• Who has access to the server and the admin panel? Do you hold an up-to-date copy of the source code?
• If a security problem arises, who should be contacted, how, and how quickly will they respond?

Common mistakes

• "We have SSL, so the site is secure": SSL only encrypts the connection; it does not close vulnerabilities in the code or on the server. See What is SSL?
• Relying on obscurity for security: Changing the address of the admin panel or storing a file under a hard-to-guess name can be an extra measure, but it is not the real protection.
• Relying on a single plugin: Security plugins and firewalls are useful, but they do not make up for outdated software and weak passwords.
• Keeping the backup on the same server: If the server is compromised, the backup goes with it.
• Leaving test and old versions accessible: Forgotten copies in folders such as /old, /test or /backup are never updated and become the weakest link.
• Not closing the entry point after cleaning up: After an attack, deleting only the malicious files is not enough; if the vulnerability is not fixed, the site will be compromised again.

The full checklist

Code

• All queries use prepared statements; sort orders and column names come from an allowlist.
• All output is escaped according to its context.
• A CSRF token and POST on every state-changing request.
• Server-side session and authorisation checks on every request.
• Passwords stored with password_hash; login attempts limited.
• Type, size and name checks on file uploads; a folder with execution disabled.

Server and configuration

• A supported PHP version; up-to-date CMS, plugins and libraries.
• HTTPS enforced; security headers defined.
• Directory listing and on-screen error display switched off.
• No backups, .git, .env, phpinfo or installation files in the web root.
• File permissions 644, folders 755; configuration files more restricted.
• Database closed to outside access; application user has least privilege.

Access

• A separate, strong password for every account; two-factor authentication.
• Personal accounts; access closed for people who have left.
• SFTP or FTPS; plain FTP disabled.

Backups and monitoring

• Automatic file and database backups; a copy off the server; restore tested.
• Logs are kept and reviewed from time to time.
• Uptime and file changes are monitored; Search Console notifications are on.
• It is written down who does what during an incident.

Frequently asked questions

Related guides

• Website security checklistWeekly, monthly and yearly tasks; every item links to the relevant guide, and the list is printable.
• Server and hosting securitySFTP/FTPS, file permissions, directory listing, error display, sensitive files and database access.
• Software updates and plugin securityKeeping the CMS, plugins, themes and libraries up to date; removing what is unused; supply chain risk.
• What to do if your website is hackedStep-by-step incident response: maintenance mode, evidence, passwords, clean-up, entry point, restore and notifications.