Most website breaches don't involve a sophisticated attacker exploiting an unknown vulnerability. They involve outdated software, weak credentials, and misconfigurations that have been publicly documented for years. A realistic security checklist focuses on closing those well-known gaps first, since that's where nearly all real-world attacks actually happen. Attackers scanning the internet for vulnerable sites aren't targeting your business specifically, they're running automated tools against thousands of sites looking for exactly the gaps this checklist covers, which is precisely why closing them matters regardless of how high-profile your site is.

Keep software and dependencies patched

Outdated CMS versions, plugins, and third-party libraries are the single most common entry point for website compromises. Attackers don't need to find a new vulnerability when thousands of sites are still running software with a publicly known, unpatched one. Set a regular cadence, at minimum monthly, for reviewing and applying updates to the CMS core, plugins, server operating system, and any application dependencies. For custom-built applications, this means keeping an eye on dependency vulnerability alerts, not just framework updates.

Enforce real authentication hygiene

Weak or reused admin passwords remain a leading cause of account takeovers. Enforce multi-factor authentication on every account with administrative access, not just the primary admin login. Limit the number of accounts with elevated permissions, and remove access promptly when someone leaves the team or a contractor's engagement ends. Rate-limit login attempts so brute-force attacks against your login page get throttled rather than allowed to run unchecked. It's also worth periodically auditing who actually has admin access, since permissions granted for a one-off task have a habit of quietly staying active long after the task is finished.

Close the common web application vulnerabilities

A handful of vulnerability classes account for most real attacks: SQL injection, where unvalidated input reaches a database query directly; cross-site scripting, where user input is rendered on a page without sanitization; and cross-site request forgery, where a malicious site tricks a logged-in user's browser into making unwanted requests. Modern frameworks handle much of this by default when used correctly, parameterized queries prevent SQL injection, proper output encoding prevents cross-site scripting, but custom code that bypasses those defaults, raw SQL queries, unescaped template output, reintroduces the risk. Any custom-built form, search feature, or API endpoint that touches user input deserves a specific review against these categories. File upload features deserve particular attention too, since an upload endpoint that doesn't validate file type and size can become a way for an attacker to plant malicious code directly on your server.

HTTPS, headers, and the basics that still get skipped

Every site should run on HTTPS by default, with HTTP requests redirected, not just available as an option. Beyond that, a handful of HTTP security headers close off easy attack surface with minimal effort: a Content-Security-Policy header restricts where scripts can load from, an X-Frame-Options or frame-ancestors policy prevents clickjacking, and Strict-Transport-Security ensures browsers only ever connect over HTTPS once they've seen the site. These take minutes to configure and are frequently skipped entirely on sites that otherwise look secure. Free tools like Mozilla's Observatory or securityheaders.com will scan a live site and flag exactly which of these headers are missing, which makes this one of the fastest wins on this entire checklist.

  • CMS, plugins, and dependencies on a regular, tracked update schedule.
  • Multi-factor authentication enforced on all admin-level accounts.
  • Login rate limiting and account lockout after repeated failures.
  • HTTPS enforced site-wide with proper security headers configured.
  • Regular automated backups, stored separately from the live server.
  • A documented incident response plan, even a short one, before you need it.

Third-party scripts and plugins widen your attack surface

Every third-party script, analytics tag, chat widget, ad network snippet, runs with a surprising amount of access to your site once it's loaded, and a compromised third-party script can be used to inject malicious code onto pages you never touched directly. Audit which third-party scripts are actually in use, remove ones that aren't earning their keep, and keep an eye on advisories for the ones that remain. The same logic applies to CMS plugins: each one is effectively a piece of third-party code running with elevated access, so unused or abandoned plugins should be removed, not just deactivated.

Backups are part of your security posture

Security isn't only about preventing an incident, it's also about how fast you can recover from one. Automated, regularly tested backups, stored somewhere other than the same server as the live site, turn a ransomware attack or a corrupted database from an existential crisis into a few hours of restoration work. Backups that have never been tested by actually restoring from them are a false sense of security; test the restore process periodically, not just the backup job itself.

Monitoring and knowing when something's wrong

Most of the checklist above is prevention, but detection matters too. Uptime monitoring, log review, and alerts for unusual admin activity, logins from new locations, unexpected file changes, shrink the window between a compromise happening and someone noticing it. The longer that window stays open, the more damage an attacker can do and the harder it becomes to fully clean up afterward. A basic monitoring setup doesn't need to be elaborate to be effective; even simple alerting on failed login spikes and unexpected outbound traffic catches a meaningful share of incidents early, well before they escalate into something that shows up on the homepage.

Website security isn't a one-time project, it's an ongoing baseline of patching, access control, and monitoring that has to be maintained for as long as the site is live. If your current site hasn't had a security review recently, our web development team can audit it against this checklist and close the gaps that matter most.