Website Security Audit Checklist: 45 Checks

A website security audit checks defined assets and controls for evidence of exploitable weaknesses, unsafe configuration and failed detection or recovery. Obtain written authorisation before scanning and specify allowed hosts, accounts, methods, rate limits and test windows.

These 45 checks form a configuration and control review rather than a penetration test. Record the request, response, timestamp, tool version, affected asset and validation method for every finding. A clean result does not prove that the site is secure.

SSL and HTTPS

SSL certificates encrypt the connection between your server and your visitors' browsers. Without HTTPS, any data transmitted — login credentials, form submissions, payment details — can be intercepted by anyone on the same network. Google has used HTTPS as a ranking signal since 2014, and modern browsers display "Not Secure" warnings on HTTP pages.

SSL certificate is installed and valid — visit your site and check for the padlock icon. Click it to verify the certificate details including expiry date and issuing authority.
Certificate validity is monitored — verify names, chain, validity period and renewal automation for each required endpoint. Set alert lead time from the renewal process and recovery window.
All pages load over HTTPS — check that HTTP URLs redirect to HTTPS with a 301. Mixed content warnings occur when a page loads over HTTPS but includes resources (images, scripts, stylesheets) loaded over HTTP.
HSTS is assessed safely — enable or expand Strict-Transport-Security only after required hosts and subdomains support HTTPS. Choose duration, subdomain scope and preload through security change control.
TLS version is 1.2 or higher — TLS 1.0 and 1.1 are deprecated and contain known vulnerabilities. Your server should only accept TLS 1.2 and 1.3 connections. Test with SSL Labs Server Test.
Weak cipher suites are disabled — older cipher suites like RC4, DES, and 3DES are vulnerable to attack. Your server configuration should only offer strong ciphers. SSL Labs grades your cipher suite configuration as part of its test.

Security Headers

Security headers are HTTP response headers that instruct browsers to enable specific security features. They are one of the easiest and most impactful security improvements you can make because they require only server configuration changes, no code modifications.

Content-Security-Policy (CSP) — defines which sources of content (scripts, styles, images, fonts) are allowed to load on your pages. A strong CSP prevents cross-site scripting (XSS) attacks by blocking inline scripts and unauthorised external resources. Start with a report-only policy to identify violations before enforcing.
X-Content-Type-Options: nosniff — prevents browsers from MIME-type sniffing, which can turn an innocuous-looking file into an executable script. This header should be present on every response.
X-Frame-Options: DENY or SAMEORIGIN — prevents your site from being embedded in an iframe on another domain, protecting against clickjacking attacks. Use DENY unless you specifically need iframes from your own domain.
Referrer-Policy — controls how much referrer information is sent when users navigate away from your site. Setting strict-origin-when-cross-origin provides useful analytics data without leaking sensitive URL paths to third parties.
Permissions-Policy — restricts which browser features (camera, microphone, geolocation, payment) your site can access. Disable features you do not use to reduce your attack surface.

Test your security headers at securityheaders.com. The tool scans your site and grades your header implementation from F to A+. Most sites score a D or lower on their first test because security headers are rarely configured during initial site setup.

Authentication

Authentication controls who can access your site's admin areas, user accounts, and protected content. Weak authentication is one of the most exploited attack vectors because it requires no technical sophistication — attackers simply guess or steal credentials.

Admin URLs are non-default — WordPress sites using /wp-admin and /wp-login.php are constantly scanned by bots. Change the login URL using a security plugin or server-level redirect to reduce automated attack volume.
Strong password policy is enforced — require passwords of at least 12 characters with a mix of character types. Reject common passwords using a blocklist. Consider implementing passkey support for passwordless authentication.
Two-factor authentication is enabled for all admin accounts — 2FA dramatically reduces the risk of account compromise even if passwords are stolen. Use TOTP-based 2FA (Google Authenticator, Authy) rather than SMS, which is vulnerable to SIM swapping.
Failed login attempts are rate-limited — after five to ten failed attempts, lock the account temporarily or require a CAPTCHA. This prevents brute-force password guessing attacks.
Session management is secure — session cookies should have the Secure, HttpOnly, and SameSite attributes set. Session tokens should expire after a reasonable period of inactivity (30 to 60 minutes for admin sessions).
Default credentials are changed — check that no admin account uses default usernames like "admin" or "administrator." Default credentials are the first thing attackers try.

Software Updates

Unpatched software is the leading cause of website compromises. When a vulnerability is discovered and a patch is released, attackers reverse-engineer the patch to understand the vulnerability and begin scanning the internet for unpatched sites. The window between patch release and active exploitation is often measured in days, not weeks.

CMS is running the latest stable version — whether you use WordPress, Drupal, Joomla, or another CMS, it must be current. Check your CMS dashboard for available updates.
All plugins and extensions are updated — plugins are the most common entry point for WordPress attacks. A single outdated plugin with a known vulnerability can compromise your entire site.
Unused plugins and themes are removed — deactivated plugins can still be exploited if their files are accessible on the server. Delete anything you are not actively using.
Server software is current — PHP, Node.js, Python, Apache, Nginx, and your database server all need regular updates. Check with your hosting provider if you do not manage the server directly.
Automatic updates are enabled where appropriate — WordPress supports auto-updates for minor releases and plugins. Enable them for security patches at minimum. Test major updates on a staging environment first.

File Permissions

File permissions determine who can read, write, and execute files on your server. Overly permissive settings allow attackers who gain limited access to escalate their privileges, modify files, and install malware.

Directories are set to 755 — the owner can read, write, and execute. Group and public can read and execute only. Never use 777, which gives everyone full permissions.
Files are set to 644 — the owner can read and write. Group and public can read only. Configuration files containing credentials should be set to 600 (owner read and write only).
wp-config.php or equivalent configuration file is protected — this file contains database credentials and security keys. It should not be accessible via the web. Move it above the web root or block access with server rules.
Directory listing is disabled — without this, visiting a directory URL (like /uploads/) shows a list of every file in it. Disable directory listing in your server configuration.
Upload directories do not execute scripts — attackers often upload malicious PHP or JavaScript files through form uploads or compromised plugins. Configure your server to prevent script execution in upload directories.

Input Validation

Every form field, URL parameter, and data input on your site is a potential attack vector. Input validation ensures that only expected data types and formats are accepted, preventing injection attacks that can compromise your database, execute malicious code, or steal user data.

All form inputs are validated server-side — client-side validation (JavaScript) is easily bypassed. Server-side validation is the real security boundary. Validate data type, length, format, and range for every input.
SQL injection controls are verified — use parameterised queries or prepared statements and review code paths that construct queries. Run active injection tools only within the written authorisation and safety limits.
Cross-site scripting (XSS) is prevented — encode all user-supplied output displayed on pages. Use context-appropriate encoding — HTML encoding for HTML contexts, JavaScript encoding for script contexts, URL encoding for URLs.
File uploads are restricted — if your site accepts file uploads, validate file type by checking the actual file content (magic bytes), not just the extension. Restrict allowed types to only what is needed. Limit file sizes. Store uploads outside the web root.
CSRF protection is implemented — cross-site request forgery tokens should be included in every form that performs a state-changing action (creating, updating, or deleting data). Verify the token on the server before processing the request.
URL parameters are sanitised — any data received through query strings must be validated and sanitised before use. Never trust URL parameters for security decisions.

Backup Strategy

Backups are your last line of defence. When everything else fails — when an attacker bypasses your security measures, when a server fails, when someone accidentally deletes the database — backups are what bring your site back. A security audit must verify that backups exist, work, and can be restored.

Automated backups meet the recovery point — schedule file, data and configuration backups frequently enough to meet the documented recovery-point objective, then alert on missed or failed jobs.
Backups are stored off-site — backups stored on the same server as your website are destroyed if the server is compromised or fails. Store backups in a separate location: a different server, cloud storage (S3, Google Cloud Storage), or a dedicated backup service.
Backup retention covers plausible recovery points — derive retention from recovery objectives, compromise-detection time and applicable data-retention duties. Preserve enough isolated generations to recover from accidental deletion and delayed compromise.
Restore process has been tested — run isolated restore tests often enough for the service's risk and change rate. Verify the recovered service against recovery objectives and document the steps and result.
Database and files are backed up separately — this allows you to restore one without the other if needed. Database corruption does not always coincide with file system compromise.

Monitoring

Security monitoring detects attacks in progress and compromises that have already occurred. Without monitoring, a breach can go undetected for weeks or months, giving attackers time to steal data, inject spam, and establish persistent access.

File integrity monitoring is active — tools like Sucuri, Wordfence, or OSSEC monitor your files for unauthorised changes. Any unexpected modification to a core file, plugin, or theme triggers an alert.
Login attempts are logged — record all authentication attempts including IP address, timestamp, username, and success or failure. Review logs weekly for patterns like brute-force attacks from specific IPs.
Uptime monitoring is in place — use UptimeRobot, Pingdom, or a similar service to check your site every one to five minutes and alert you immediately when it goes down.
Google Search Console is monitored — GSC alerts you to security issues Google detects, including malware warnings, social engineering, and hacked content. Check the Security and Manual Actions section regularly.
Web application firewall (WAF) is active — a WAF like Cloudflare, Sucuri, or AWS WAF filters malicious traffic before it reaches your server. It blocks common attack patterns including SQL injection, XSS, and DDoS attacks.
Error logs are reviewed regularly — server error logs often contain early signs of attack: unusual 404 patterns (directory scanning), repeated 403 errors (access attempts), or 500 errors caused by exploitation attempts.
Blacklist monitoring is set up — check whether your domain appears on any blacklists (Google Safe Browsing, Norton Safe Web, Spamhaus). Being blacklisted means your site has been flagged as dangerous, which destroys traffic and trust. Catch it early and resolve it fast.

Work through this checklist systematically and document your findings in a spreadsheet with columns for the check item, current status (pass, fail, partial), severity (critical, high, medium, low), and planned fix date. Address critical and high-severity items immediately. Schedule medium and low items for the next maintenance window. Then set a calendar reminder to re-run the checklist quarterly.

Use the OWASP Web Security Testing Guide and current NIST authentication guidance when interpreting results. Confirm the exact security scope of professional audit services before testing.