Website security checklist: audited steps to protect your site

A hardened website starts with thirteen controls, each one auditable in under five minutes. Run through this list now and mark each item pass or fail before reading further.

TLS/SSL — site responds only on port 443, HTTP redirects to HTTPS, certificate is valid and not self-signed, TLS 1.2/1.3 only. Fail if: browser shows a certificate warning or curl -I http://yoursite.com returns 200 instead of 301.
HSTS — Strict-Transport-Security header present with a max-age sufficient to enforce HTTPS for an extended period. Fail if: absent from response headers.
MFA on admin accounts — every administrator logs in with a second factor (authenticator app or hardware token). Fail if: any admin account uses password only. The ACSC recommends MFA as a core control to reduce compromise risk.
Least privilege — no user account holds more permissions than their role requires; no orphaned accounts remain active.
Secure cookies — session cookies carry Secure, HttpOnly, and SameSite flags configured to reduce session-theft risk. Fail if: browser DevTools shows a session cookie missing any flag.
Input validation — all user-supplied data is validated server-side; parameterised queries used for every database call.
Server hardening — unused services and modules disabled; software and dependencies patched within 30 days of a critical advisory.
WAF/CDN active — a web application firewall sits in front of the origin; direct access to the origin IP is restricted.
Third-party scripts inventoried — every external script has a known owner, a version, and a review date.
Backups verified — encrypted backups stored off-site; restore tests conducted regularly to verify recovery capability.
Monitoring and alerting live — logs collected centrally; alerts fire on repeated login failures and unusual error spikes.
Security headers deployed — Content Security Policy, X-Content-Type-Options, X-Frame-Options, and Referrer-Policy all present.
DNS records correct — SPF, DKIM, DMARC, and CAA records published and validated.

Statistic: 42% of cyberattacks target small businesses, yet most breaches exploit controls that appear on this list — expired certificates, missing MFA, unpatched plugins.

Any item you marked fail is a live risk. The sections below explain exactly how to fix each one.

Key takeaways

A hardened website requires layered controls across authentication, transport security, input validation, monitoring, and regular testing — no single fix is sufficient.

Point	Details
MFA first	Enable MFA on every admin account before any other fix — it prevents the majority of credential-based breaches.
Headers are low-effort, high-return	HSTS, `X-Content-Type-Options`, and `X-Frame-Options` can be deployed in under two hours and block several common attack classes.
Backups must be tested	An untested backup is not a recovery plan; restore to staging at least quarterly and document the time taken.
Prioritise by exploitability	Fix high-impact, low-effort gaps first; use a 30/60/90-day roadmap to sequence the rest.
Techbug covers the full stack	Techbug’s managed security services handle audits, patching, WAF management, and continuous monitoring for Australian SMBs.

Why does a website security checklist matter for your business?
What does a complete website security checklist cover?
How to prioritise fixes: a risk-based approach
Common misconfigurations Techbug sees in small businesses
How a practitioner runs this checklist in a real engagement
Techbug’s security services: audits, managed protection, and emergency response
Sources

Why does a website security checklist matter for your business?

No single control stops every attack. That is the core of defence-in-depth: layer protections so that when one fails, the next one holds. MDN’s web security guidance frames it plainly — combining a WAF, TLS, input validation, and browser-facing headers reduces single points of failure in a way that no individual tool can replicate.

For a small or mid-sized organisation, the practical stakes are:

Credential theft — compromised admin passwords give attackers full site control, often within minutes of a breach.
Data loss — customer records, payment data, and intellectual property can be exfiltrated silently.
Downtime — a DDoS attack or ransomware infection can take a site offline for hours or days, with direct revenue impact.
Regulatory exposure — under the Australian Privacy Act and the GDPR (if you handle EU residents’ data), a notifiable breach carries real legal and financial consequences.

A checklist buys you something specific: a repeatable audit you can run quarterly, assign to a team member, and use to demonstrate due diligence to insurers, clients, or regulators. It converts abstract “security” into pass/fail items with owners and deadlines.

Statistic: The ACSC’s Essential Eight framework identifies patching, MFA, and application control as the three controls that prevent the majority of targeted attacks against Australian businesses.

What does a complete website security checklist cover?

1. Implement sitewide TLS/SSL and validate certificates

Every page on your site must be served over TLS. That means TLS 1.2 at minimum, TLS 1.3 preferred, with SSLv3, TLS 1.0, and TLS 1.1 disabled entirely. HTTP requests should return a 301 redirect to HTTPS, not a 200 response.

Validation checklist:

Certificate is issued by a trusted CA (not self-signed), covers all subdomains in use (check SANs), and expires more than 30 days from today.
openssl s_client -connect yoursite.com:443 shows TLS 1.2 or 1.3 in the handshake.
An online scanner such as SSL Labs grades the configuration A or A+.
Strict-Transport-Security: max-age=31536000; includeSubDomains is present in the response header.

HSTS tells browsers to refuse plain HTTP connections for the duration of max-age. Once you are confident every subdomain has a valid certificate, consider submitting to the HSTS preload list, which bakes the HTTPS-only rule into browsers before a user ever visits your site. Preload is irreversible in the short term, so verify subdomain coverage first.

Cipher-suite hygiene matters too. Disable RC4, 3DES, and export-grade ciphers. Apache’s SSL/TLS configuration guide provides concrete SSLCipherSuite directives for common server setups.

Pro Tip: Set a calendar reminder 60 days before your certificate expiry date. Let’s Encrypt auto-renewal is reliable, but a misconfigured renewal cron job is one of the most common causes of unexpected certificate expiry in production.

2. Enforce strong authentication and least-privilege access

MFA is the single highest-return control on this list. Require it for every administrative account without exception — authenticator apps (Google Authenticator, Microsoft Authenticator) are the practical minimum; hardware tokens (YubiKey) are stronger for high-value targets. The ACSC explicitly recommends MFA for administrative accounts as a core control to reduce compromise risk.

Account hardening checklist:

List every account with admin or elevated privileges. Remove any that belong to former staff or contractors.
Confirm MFA is active on each remaining admin account — check the authentication logs, not just the settings page.
Apply role-based access control (RBAC): editors cannot access server settings; developers cannot access billing; support staff cannot export the full user database.
Rename or disable default admin usernames (e.g. admin, administrator, root) where the platform allows it.
Set account lockout after five to ten failed login attempts to blunt brute-force attacks.
Review account recovery flows — security questions are weak; recovery codes stored securely are better.

For application control and permission enforcement, the principle is the same: grant the minimum access needed to do the job, then audit quarterly.

Pro Tip: Service accounts and shared credentials are the most common least-privilege failures. Give each integration its own account with only the permissions it needs, and rotate its credentials on a schedule. A shared “dev team” password with admin rights is a single point of failure for your entire site.

3. Secure cookies and session management

Session cookies are the keys to your users’ accounts. If an attacker can read or forge one, they own the session. Three cookie attributes close the most common theft vectors, and OWASP documents all three as non-negotiable for session cookies:

HttpOnly — prevents JavaScript from reading the cookie, blocking most XSS-based session theft.
Secure — cookie is only sent over HTTPS, never plain HTTP.
SameSite=Lax (or Strict) — limits cross-site cookie sending, reducing CSRF risk.

Beyond the flags, consider the __Host- and __Secure- cookie name prefixes. A cookie named __Host-session forces the browser to apply Secure, omit a Domain attribute, and set Path=/, making it significantly harder to override via a subdomain.

Session lifecycle controls:

Expire idle sessions after 15–30 minutes for admin interfaces; longer for low-risk public sessions.
Rotate the session token immediately after a privilege change (e.g. login, password reset, role upgrade).
Store session state server-side; never encode sensitive data in a client-side cookie, even if it is signed.

Validation: Open browser DevTools → Application → Cookies. Every session cookie should show a tick in the HttpOnly and Secure columns, and SameSite should read Lax or Strict.

4. Validate inputs and defend against injection and XSS

The rule is simple: never trust data that arrives from a browser. Every field, URL parameter, header, and file upload is a potential attack vector.

Core controls:

Use parameterised queries (prepared statements) for every database interaction. String concatenation in SQL is the direct cause of SQL injection, still one of the OWASP Top 10 attack categories.
Validate on the server side using a centralised library (e.g. OWASP Java HTML Sanitizer, Python’s bleach, or Laravel’s built-in validation). Client-side validation is a UX feature, not a security control.
Encode output before rendering it in HTML, JavaScript, or CSS contexts. A username that contains <script> should render as <script>, not execute.
Reject or sanitise file uploads: check MIME type server-side, store uploads outside the web root, and never execute uploaded files.

Testing checklist:

Run an automated scanner (OWASP ZAP or Burp Suite Community) against a staging environment monthly.
Manually test high-risk inputs: search fields, login forms, comment boxes, file upload endpoints.
Review code for raw query concatenation before every deployment.

Pro Tip: Automated scanners find known injection patterns quickly, but they miss logic flaws and second-order injection. MDN notes that scanners cannot replace secure coding practices — treat scanner results as a floor, not a ceiling.

5. Harden servers, services, and dependencies

A default server installation is a generous attack surface. The goal is to remove everything you do not need and keep everything you do need patched.

Hardening checklist:

Disable or remove unused services, modules, and daemons (e.g. FTP if you use SFTP, unused Apache modules like mod_status without access controls).
Run web server processes as a dedicated low-privilege user, not as root.
Remove sample files, default pages, and test scripts from production.
Disable directory listing on the web server.
Segregate components where possible: web server, application server, and database on separate hosts or containers, as the Canadian Centre for Cyber Security recommends.

Patching cadence:

Critical and high-severity patches: apply within 48–72 hours of release.
Medium patches: within 30 days.
Automate OS-level security updates where the platform supports it (e.g. unattended-upgrades on Debian/Ubuntu), but test in staging first for application-layer dependencies.

Dependency management:

Run npm audit, pip-audit, or composer audit in your CI pipeline on every build.
Pin dependency versions in production and review changes before updating.
Use a software composition analysis (SCA) tool such as Snyk or OWASP Dependency-Check to flag known CVEs in your dependency tree.

Pro Tip: Outdated WordPress plugins are the most common entry point Techbug sees in compromised small-business sites. Set plugins to auto-update for security releases, and delete plugins you are not actively using — an inactive plugin with a known CVE is just as dangerous as an active one.

6. Use a WAF, CDN, and DDoS protection

A web application firewall inspects HTTP/HTTPS traffic before it reaches your application and blocks requests that match known attack patterns: SQL injection strings, XSS payloads, path traversal attempts, and malformed headers. A CDN absorbs volumetric DDoS traffic at the network edge, far from your origin server.

Deployment checklist:

Place the WAF/CDN in front of your origin. Configure the origin to accept connections only from the WAF/CDN’s published IP ranges, not from the open internet.
Test origin protection: attempt a direct HTTP request to your origin IP. It should return a connection refused or a generic error, not your site.
Start the WAF in monitoring (log-only) mode. Review flagged requests for false positives before switching to blocking mode. SiteSecurityScore recommends this incremental approach to avoid disrupting legitimate traffic.
Enable rate limiting on login endpoints and API routes to reduce brute-force and credential-stuffing exposure.
Review WAF logs weekly during the first month after deployment; monthly thereafter.

Validation: After enabling origin restriction, use a tool like curl -H "Host: yoursite.com" http://<origin-ip>/ from an IP outside the WAF’s allowlist. A blocked response confirms the restriction is working.

7. Manage third-party scripts, plugins, and supply-chain risk

Every third-party script you load is code you did not write, running in your users’ browsers with access to the DOM and potentially to form inputs. Supply-chain attacks — where a legitimate script is compromised at the source — are a growing vector.

Third-party script inventory template:

Script / Plugin	Source URL	Owner	Version	Last reviewed	Risk level
Google Analytics	analytics.google.com	Google	GA4	March 2026	Low
Payment widget	checkout.provider.com	Stripe	v1.3	March 2026	High
Live chat	cdn.chatprovider.io	ChatCo	2.4.1	January 2026	Medium

Run this audit quarterly. Any script with an unknown owner or no recent review is a candidate for removal.

Controls:

Use Subresource Integrity (SRI) hashes on scripts loaded from CDNs: <script src="..." integrity="sha384-..." crossorigin="anonymous">. The browser refuses to execute the script if the hash does not match.
Apply a Content Security Policy (see Section 12) that restricts which domains can serve scripts to your page.
For high-risk third-party widgets (payment forms, chat), load them in an <iframe> with a restrictive sandbox attribute where the provider supports it.
Subscribe to security advisories for every plugin and CMS you use (WordPress, Drupal, Joomla all publish CVE feeds). For Drupal-specific plugin guidance, this Drupal security plugin overview covers configuration considerations worth reviewing.

Pro Tip: The question is not “is this plugin safe?” but “do we still need it?” A plugin that was installed for a one-off campaign three years ago and never removed is pure attack surface. Audit your plugin list every quarter and delete anything without a clear current purpose.

8. Backups, reliability, and restore testing

A backup you have never restored is a hypothesis, not a safety net. The goal is a verified, off-site, encrypted copy of everything needed to rebuild your site from scratch.

Define backup scope. Include site files, databases, application configuration, environment variables, and SSL certificates. Do not forget DNS zone files and server configuration if you manage your own infrastructure.
Store backups off-site and immutably. A backup on the same server as the site is destroyed in the same ransomware event. Use a separate cloud storage bucket with object-lock (immutable) enabled, or a dedicated cloud backup service.
Encrypt backups at rest. Use AES-256 encryption. Store the encryption key separately from the backup itself.
Set retention. Keep daily backups for 30 days, weekly backups for 90 days, and monthly backups for one year. This covers both accidental deletion (discovered days later) and slow-burn compromise (discovered weeks later).
Restrict backup access. Only the backup system and a named recovery administrator should have write access to the backup destination. Read access should require MFA.
Run a restore test. At least quarterly, restore the most recent backup to a staging environment and verify: the site loads correctly, the database contains expected recent records, and the restore completed within your recovery time objective (RTO). Document the time taken and any errors.
Measure success. Recovery Point Objective (RPO) — how much data can you afford to lose? Recovery Time Objective (RTO) — how long can the site be down? Your backup cadence and restore speed must meet both.

9. Monitoring, logging, detection, and incident response

You cannot respond to an incident you did not detect. Centralised logging turns raw server noise into an auditable record that supports both real-time alerting and post-incident forensics.

Essential logs to collect:

Web server access and error logs (Apache/Nginx)
Application-level authentication events (login success, failure, password reset, MFA bypass)
Database query logs for anomalous patterns
Server system logs (auth.log, syslog)
WAF and CDN event logs

Retain logs for at least 90 days for investigation purposes; 12 months is better for regulatory compliance under the Australian Privacy Act.

Alert thresholds worth configuring:

More than ten failed login attempts from a single IP in five minutes — likely brute force.
A sudden spike in HTTP 500 errors — possible injection attempt or application crash.
New admin account created outside business hours.
Backup job failure.

Pro Tip: Ship logs to a separate system your web server cannot write to. If an attacker compromises the web server and can delete logs, your forensic trail disappears. A read-only log sink — even a simple S3 bucket with write-once policy — preserves evidence.

Minimal incident response playbook:

Contain — isolate the affected system (take it offline or block the attacking IP at the WAF) to stop active damage.
Preserve — snapshot logs and disk state before making changes. Evidence lost during cleanup cannot be recovered.
Restore — deploy from the last known-good backup to a clean environment, then verify integrity before going live.
Notify — if personal data was accessed, the Australian Privacy Act’s Notifiable Data Breaches scheme requires notification to the OAIC and affected individuals within 30 days of becoming aware of the breach.
Review — conduct a post-incident review within 72 hours to identify the root cause and close the gap.

10. Regular testing: vulnerability scanning, dependency checks, and penetration testing

Testing is how you find gaps before attackers do. The cadence matters as much as the tooling.

Weekly automated scans — run a lightweight configuration scanner against your live site to catch certificate expiry, missing headers, and known CVE matches. Tools like Nikto or a hosted scanner work for this.
Monthly dependency audits — run npm audit, composer audit, or pip-audit against your dependency manifest and triage any high or critical findings within 48 hours.
Quarterly DAST scans — run OWASP ZAP or Burp Suite against a staging environment to test for injection, authentication, and session management flaws. Next-generation vulnerability detection tools can automate much of this, but review findings manually before closing tickets.
Annual penetration test — for any site handling payments, health data, or significant personal information, commission an independent penetration test. A qualified tester will find logic flaws, privilege escalation paths, and chained vulnerabilities that automated tools miss.
Prioritise findings by exploitability × user impact. A medium-severity finding on the login page outranks a high-severity finding on an internal admin tool with no external access. Convert each finding into a tracked ticket with an owner and a due date.

MDN notes that automated scanners are valuable for known issues but cannot substitute secure coding and architecture reviews — use both.

11. DNS security and secure name resolution

DNS is the address book of the internet. An attacker who can manipulate your DNS records can redirect your traffic, intercept email, or obtain fraudulent certificates for your domain.

DNS records to publish and validate:

SPF (TXT record) — lists the mail servers authorised to send email from your domain. Prevents spoofed email that appears to come from your address.
DKIM (TXT record) — cryptographically signs outbound email so recipients can verify it was not tampered with in transit.
DMARC (TXT record) — tells receiving mail servers what to do with messages that fail SPF or DKIM checks (none, quarantine, or reject). Start with p=none to monitor, then move to quarantine or reject.
CAA (CAA record) — restricts which certificate authorities can issue TLS certificates for your domain. Prevents an attacker from obtaining a valid certificate from a different CA.
DNSSEC — cryptographically signs DNS responses so resolvers can detect tampering. Enable it if your registrar supports it; check your zone with dig +dnssec yoursite.com.

DNS-over-HTTPS (DoH): For outbound resolver queries from your servers, DoH encrypts DNS lookups so they cannot be intercepted or manipulated on the network path. Configure your server’s resolver to use a DoH-capable provider (Cloudflare 1.1.1.1 or Google 8.8.8.8 both support it).

Quick validation checklist:

Use MXToolbox or dig TXT yoursite.com to confirm SPF, DKIM, and DMARC records are present and syntactically correct.
Check CAA records with dig CAA yoursite.com.
Verify DNSSEC signing status at dnssec-analyzer.verisignlabs.com.

12. Security headers and secure defaults

Security headers are browser-enforced controls that cost almost nothing to deploy and block a meaningful range of client-side attacks. Deploy them in this order, testing each one before moving to the next.

Recommended headers:

Content-Security-Policy — restricts which sources can load scripts, styles, images, and frames. Start in report-only mode (Content-Security-Policy-Report-Only) and collect violation reports for two to four weeks before enforcing. A minimal starting policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self';
Strict-Transport-Security: max-age=31536000; includeSubDomains — forces HTTPS for one year. Add preload only after verifying all subdomains have valid certificates and you are ready to submit to the preload list.
X-Content-Type-Options: nosniff — prevents browsers from MIME-sniffing a response away from the declared content type.
X-Frame-Options: DENY (or use frame-ancestors 'none' in CSP for modern browsers) — blocks clickjacking by preventing your page from being embedded in an iframe.
Referrer-Policy: strict-origin-when-cross-origin — limits how much URL information is sent in the Referer header to external sites.
Permissions-Policy — restricts access to browser APIs (camera, microphone, geolocation) that your site does not use. Example: Permissions-Policy: geolocation=(), microphone=(), camera=()

SiteSecurityScore’s guidance recommends deploying CSP in report-only mode first to avoid breaking legitimate functionality — a CSP that blocks your own analytics or payment widget will hurt users before it hurts attackers.

Validation tools: securityheaders.com grades your headers in seconds. Browser DevTools → Network → response headers shows exactly what your server is sending.

How to prioritise fixes: a risk-based approach

Not every gap on your checklist carries equal weight. A practical way to sequence remediation is to score each finding on two axes: impact (what an attacker gains if they exploit it) and effort (hours of work to fix it). Quick wins — high impact, low effort — go first.

Prioritisation matrix:

For managed IT services pricing context, most of the immediate and week-one items above are within reach of a part-time IT manager or a short consulting engagement.

Suggested 30/60/90-day roadmap:

Days 1–30 (urgent): MFA on all admin accounts, HSTS and basic security headers, critical patch cycle, off-site backups, WAF in monitoring mode, orphaned account audit.
Days 31–60 (medium priority): CSP report-only rollout, WAF tuning and switch to blocking mode, RBAC review, DNS record audit, centralised logging and alerting.
Days 61–90 (strategic): CSP enforcement, penetration test scoped and commissioned, dependency SCA integrated into CI, incident response playbook documented and tested.

Track progress by measuring the percentage of admin accounts with MFA active, the number of unpatched critical CVEs, and the date of the last successful backup restore test.

Common misconfigurations Techbug sees in small businesses

After working with small and medium businesses across Australia, a handful of misconfigurations come up repeatedly. They are not exotic — they are the basics that slip through when no one owns the security function.

The most common failures:

Expired TLS certificates — often on subdomains or staging environments that were forgotten. Browsers block access immediately; users see a hard error. Fix: audit every subdomain, not just the primary domain, and set renewal reminders 60 days out.
Open admin endpoints — WordPress /wp-admin, phpMyAdmin, and cPanel accessible from any IP. Fix: restrict admin URLs to known IP ranges at the server or WAF level, or move them to a non-standard path.
Outdated plugins with known CVEs — a plugin last updated two years ago is almost certainly carrying unpatched vulnerabilities. Fix: delete unused plugins; update the rest immediately. See small business IT security practices for a practical owner-level checklist.
No MFA on hosting control panels — cPanel, Plesk, and similar panels often have MFA available but disabled by default. Fix: enable it today; it takes ten minutes.
Backups stored on the same server — ransomware encrypts everything it can reach. Fix: move backups off-site immediately.
Missing security headers — a scan of most small-business sites shows no CSP, no X-Frame-Options, and no Referrer-Policy. Fix: add them in an afternoon; use securityheaders.com to verify.

For a small IT team or business owner with limited time, the realistic first week looks like this:

Day 1: Enable MFA on all admin accounts and the hosting panel.
Day 2: Run SSL Labs on your domain; fix any certificate or cipher issues.
Day 3: Add HSTS, X-Content-Type-Options, and X-Frame-Options headers.
Day 4: Audit plugins — delete unused ones, update the rest.
Day 5: Verify backups are running, off-site, and encrypted. Restore one file to confirm.

None of these require a large budget. They require an hour of focused attention each day for one week.

How a practitioner runs this checklist in a real engagement

The first thing to do in any security engagement is establish a baseline. That means running an automated scan, reviewing response headers, checking certificate validity, and pulling a list of every account with elevated privileges. The scan takes 20 minutes; the account audit often takes longer because no one has looked at it in years.

Remediation follows a strict order: fix the items that an attacker could exploit today with no skill (exposed admin panels, missing MFA, expired certificates) before touching anything that requires careful rollout (CSP, WAF rules). Rushing a CSP deployment without a report-only phase is a reliable way to break your own site.

The verification step is where most engagements find their second wave of issues. After applying fixes, re-run the scanner, check headers in a browser, and attempt to access the origin IP directly. What looked like a complete WAF deployment sometimes turns out to have a gap — a staging subdomain that bypasses the WAF, or a legacy API endpoint that still accepts direct connections.

Managed services add the most value in the monitoring and patching layers, where the work is continuous rather than project-based. A one-off audit finds the gaps; ongoing monitoring catches new ones before they are exploited.

Techbug’s security services: audits, managed protection, and emergency response

Running through this checklist manually takes time most business owners and IT managers do not have spare. Techbug’s IT security services cover the full scope: security audits that map your current posture against the controls above, managed detection and response that keeps monitoring live around the clock, and ransomware-safe backup and recovery so a restore test is never a surprise.

For businesses that want ongoing coverage rather than a one-off fix, Techbug’s managed security services for SMBs include proactive patching, WAF management, and staff security awareness training — the three layers that prevent the majority of breaches seen in Australian small businesses. There are no lock-in contracts; the engagement scales with what your business actually needs.

To get started, contact Techbug for a basic security health check. The team will identify your highest-risk gaps and give you a prioritised remediation plan within one business day.

Sources

The resources below are the authoritative references behind this checklist. Which one to read next depends on your role:

1300 655 121