A website security checklist is a short, ordered list of controls that keeps attackers out of your site and limits the damage if one gets in: patched software, HTTPS everywhere, strong logins with multi-factor authentication, least-privilege access, input validation, security headers, a web application firewall, tested backups, logging, and a written plan for the bad day. Work through those twelve items in order and you close the gaps behind most real breaches.
The order matters more than most guides admit. Verizon’s 2026 Data Breach Investigations Report says 31% of breaches now start with the exploitation of a software vulnerability, which puts unpatched code ahead of stolen passwords as the most common way in. So patching comes first on our list, ahead of the controls that usually get the attention.
This guide is written for business owners, marketing heads and CTOs who are responsible for a company site but don’t run a security team. Each item says what to do, what it prevents, and roughly how much effort it takes, so you can hand the list to a developer or check the work yourself.
1. What a Website Security Checklist Covers and Why It Matters
Your website is often the most exposed piece of software your company owns. It’s public, it runs around the clock, and it usually connects to something valuable: a customer database, a payment flow, an admin panel, or your email domain. Attackers scan the whole internet automatically, so a small company site gets probed by the same bots that hit large ones.
A good website security checklist cuts down the number of ways in. It also shortens the gap between “something is wrong” and “we’re back online with clean data,” which is where most of the real business damage happens: lost sales, lost rankings and lost trust while the site is down or serving spam.
What attacks actually look like on business sites
Most incidents on small and mid-sized business sites are boring and automated. A bot finds an outdated plugin, uploads a script, and starts injecting spam links or redirecting visitors to scam pages. According to Sucuri data quoted in Patchstack’s State of WordPress Security in 2025 report, more than 500,000 websites were infected in 2024, including 422,466 cases of SEO spam and 175,520 malicious redirects.
The same report counted 7,966 new vulnerabilities in the WordPress ecosystem in 2024, 96% of them in plugins. A third (33%) were not fixed by the time they were made public. That’s the window attackers use.
For a business, the cost shows up in places you can measure:
- Google flags the site as unsafe and traffic drops overnight.
- Your domain lands on spam blocklists, so sales emails stop arriving.
- Customer records leak, which brings legal exposure and a lot of awkward phone calls.
- Ransomware takes the site and its database offline; Verizon’s 2026 report says 48% of breaches now involve it.
How the OWASP Top 10 fits in
The OWASP Top 10:2025 is the standard reference list of web application risks. Its ten categories run from A01 Broken Access Control and A02 Security Misconfiguration down to A10 Mishandling of Exceptional Conditions, with Software Supply Chain Failures new at A03. We map each checklist item below to the OWASP category it addresses, so your OWASP Top 10 protection is traceable rather than assumed.
2. The 12-Point Website Security Checklist
Each item below follows the same pattern: what to do, what it stops, and how to confirm it’s working. These are web application security best practices you can apply to WordPress, a headless CMS, or a custom-built web app. If you only have time for part of the website security checklist this week, do items 1, 3 and 10 first.
1) Patch the CMS, plugins, frameworks and server packages
Turn on automatic minor updates for your CMS and set a weekly window for everything else: plugins, themes, npm or Composer packages, PHP or Node versions, and the server OS. Delete plugins and themes you aren’t using, since deactivated code can still be reachable on disk.
Check it: run npm audit or composer audit on custom builds, and use your CMS’s update screen or a vulnerability feed for WordPress. Anything flagged as actively exploited gets patched the same day. This covers OWASP A03 (Software Supply Chain Failures).
2) Force HTTPS everywhere and add HSTS
Every page, image and API call should load over HTTPS with a valid certificate. Let’s Encrypt certificates are free and renew automatically on most hosts. Redirect all HTTP traffic to HTTPS with a 301, then add the Strict-Transport-Security header so browsers refuse to downgrade.
The OWASP HTTP Headers Cheat Sheet recommends max-age=63072000; includeSubDomains; preload (two years). Start with a shorter max-age if you’re unsure every subdomain supports HTTPS, then raise it. This item maps to A04 (Cryptographic Failures).
3) Lock down logins with MFA and modern password rules
Require multi-factor authentication for every admin, editor and hosting account. An authenticator app or a hardware key is far stronger than SMS codes.
Update your password policy too. NIST’s current guidance (SP 800-63B, revision 4) says passwords used on their own must be at least 15 characters, systems should accept at least 64, and you should not force mixed-character rules or scheduled password changes. New passwords should be checked against a list of known breached and common passwords instead. Add rate limiting or lockouts on the login form, because credential-stuffing bots try thousands of combinations an hour. This covers A07 (Authentication Failures).
4) Apply least privilege to every account and key
List every user with admin rights, then remove or downgrade anyone who doesn’t need them this month. Former staff and old agencies are the usual leftovers. Give content editors editor roles, not administrator roles.
The same rule applies to machines. Database users should only have the permissions the app needs, API keys should be scoped to one service, and secrets belong in environment variables or a secrets manager, never in your Git repository. Broken Access Control is A01 on the OWASP list for a reason.
5) Validate input and use parameterized queries
Treat everything a user sends as untrusted: form fields, URL parameters, file uploads, headers and JSON bodies. Validate on the server (type, length, allowed values), use parameterized queries or an ORM for every database call, and encode output so user-supplied text can’t run as script in someone else’s browser.
Patchstack found cross-site scripting made up almost half of all new WordPress vulnerabilities in 2024, so output encoding needs as much attention as SQL injection. This is the core of OWASP A05 (Injection) and one of the most direct ways to prevent website hacking on custom forms.
6) Restrict and scan file uploads
If your site accepts CVs, images or documents, allow only the file types you need, check the real file type rather than the extension, rename files on upload, and store them outside the web root or in object storage with script execution disabled. Set a size limit. A single upload form that accepts .php files is enough to hand over the whole server.
7) Set security headers
Headers tell the browser how to treat your pages. A sensible starting set from the OWASP cheat sheet:
Content-Security-Policy: start in report-only mode, list the script and style sources you actually use, then enforce.X-Content-Type-Options: nosniffX-Frame-Options: DENY(or the CSPframe-ancestorsdirective) to stop clickjacking.Referrer-Policy: strict-origin-when-cross-originPermissions-Policy: geolocation=(), camera=(), microphone=(), adjusted to features you use.
Remove the X-Powered-By header and don’t set X-XSS-Protection; OWASP advises against it. These fixes take an afternoon and close a slice of A02 (Security Misconfiguration).
8) Harden the server and hosting configuration
Disable directory listing, turn off debug mode and detailed error pages in production, close unused ports, and make sure .env, .git and backup files can’t be downloaded. Use SFTP or SSH keys instead of plain FTP. Keep staging sites behind a password, since forgotten staging copies with old plugins are a common way in.
Error handling belongs here too. OWASP added A10 (Mishandling of Exceptional Conditions) in 2025: a crash should return a generic message and log the details privately, never print a stack trace or database name to the visitor.
9) Put a web application firewall in front of the site
A WAF filters known attack patterns (SQL injection strings, bad bots, exploit attempts against popular plugins) before they reach your server. Cloud WAFs from CDN providers also absorb basic denial-of-service traffic and can block whole countries or ASNs if you don’t serve them.
A WAF buys you time. It doesn’t replace patching, because a new exploit can arrive before the rule does.
10) Back up automatically and test the restore
Follow the 3-2-1 pattern: three copies, on two kinds of storage, one of them off-site and out of reach of your main hosting account. Back up files and the database daily for active sites, and keep at least 30 days of history so you can roll back past an infection you didn’t notice right away.
The part most teams skip is the restore test. Once a quarter, restore a backup to a staging server and confirm the site works. An untested backup is a guess.
11) Log, monitor and alert
Keep logs of logins, admin actions, file changes and server errors for at least 90 days, stored somewhere an attacker on the web server can’t wipe. Set alerts for the events that matter: a new admin user, a changed core file, a spike in 404s or failed logins, an uptime check failing. Add Google Search Console to the site so you hear about malware or hacked-content flags quickly. This covers A09 (Security Logging and Alerting Failures).
12) Write a one-page incident response plan
Decide now who does what when the site is compromised. The plan should name the person in charge, list hosting and domain logins (stored in a password manager), describe how to take the site offline or into maintenance mode, and say where clean backups live.
Include the steps after recovery: rotate every password and API key, find the entry point, patch it, then request a review in Search Console if Google flagged the site. Without a plan, people restore the backup and leave the hole open.
3. Website Security Checklist Comparison: Effort, Cost Drivers and OWASP Mapping
Use this table to plan the work. Effort figures are our estimates for a typical business site with one CMS or custom web app; your numbers will move with the size of the site, the age of the code and how many integrations it has.
| Control | What it stops | OWASP 2025 | Estimated effort | Main cost driver |
|---|---|---|---|---|
| Patching and dependency audit | Known exploits in plugins and libraries | A03 | 2 to 4 hours, then 1 hour a week | Number of plugins or packages; custom code that blocks updates |
| HTTPS and HSTS | Snooping, downgrade attacks | A04 | 1 to 2 hours | Mixed-content fixes on old pages |
| MFA and password rules | Credential stuffing, account takeover | A07 | 2 to 6 hours | Number of user roles and login systems |
| Least privilege and secrets | Privilege abuse, leaked keys | A01 | 2 to 4 hours | Number of accounts and integrations |
| Input validation and safe queries | SQL injection, XSS | A05 | 1 to 5 days for custom apps | Number of forms and endpoints |
| Upload restrictions | Web shells, malware uploads | A05, A02 | 3 to 8 hours | Number of upload points |
| Security headers and CSP | Clickjacking, script injection impact | A02 | 4 hours to 2 days | Number of third-party scripts |
| Server hardening | Exposed files, debug leaks | A02, A10 | 4 to 8 hours | Shared vs managed vs self-run hosting |
| Web application firewall | Automated attacks, bad bots, basic DDoS | Several | 2 to 4 hours setup | Plan tier and custom rules |
| Backups and restore tests | Data loss, ransomware | A08 | 2 to 4 hours, then quarterly tests | Database size and retention period |
| Logging and alerts | Slow detection | A09 | 4 to 8 hours | Where logs are stored and for how long |
| Incident response plan | Chaotic, incomplete recovery | All | 2 to 3 hours | Number of people and vendors involved |
Most of the effort sits in item 5 for custom applications, because web application security best practices for input handling have to be applied form by form and endpoint by endpoint. For a standard WordPress site, the patching, access and backup items do most of the protective work.
4. How to Run the Checklist in 30 Days
You don’t need to do all twelve at once. Here’s the order we’d follow for a site that has never had a security review.
Week 1: Inventory and quick wins
- List every domain, subdomain, staging copy and admin login connected to the business.
- Update the CMS, plugins, themes and server packages; delete anything unused.
- Turn on MFA for all admin and hosting accounts.
- Confirm HTTPS works on every page and add the HTTP-to-HTTPS redirect.
- Take a full backup and store a copy off-site before you change anything else.
Week 2: Access and configuration
- Remove stale users and downgrade roles that are wider than needed.
- Move secrets out of code and rotate any key that was ever committed to Git.
- Disable debug output, directory listing and plain FTP.
- Add the basic security headers, with CSP in report-only mode.
Week 3: Application layer
- Review every form, search box and upload field for server-side validation.
- Check database calls for string-built queries and replace them with parameterized ones.
- Put the WAF in front of the site and watch its logs for a few days before tightening rules.
Week 4: Detection and recovery
- Set up logging, uptime checks and alerts for admin and file changes.
- Write the one-page incident response plan and share it with everyone named in it.
- Restore a backup to staging and time how long it takes.
- Move CSP from report-only to enforced once the reports are clean.
Who should own each item
Most checklists skip ownership, and that’s why items quietly stop happening. Assign every control to a named person, even in a small company:
- Developer or agency: patching, input validation, upload handling, headers, server hardening and the WAF rules.
- Site owner or marketing head: the user list, MFA enforcement for the team, and Search Console alerts.
- Hosting provider or IT lead: backups, restore tests, log retention and server-level access.
- Management: the incident response plan, vendor contacts and the yearly review budget.
Write the names next to each item in your website security checklist and review them whenever someone leaves or a vendor changes.
After the first month, the checklist becomes a routine: weekly updates, monthly access review, quarterly restore test, and a fuller review (or a penetration test, for sites that handle payments or personal data) once a year.
5. Common Mistakes That Leave Sites Exposed
We see the same problems again and again when we audit business sites. None of them need expensive tools to fix.
- Treating a security plugin as the whole plan. A plugin can scan and block, but it can’t fix an abandoned plugin with a known flaw or a reused admin password.
- Keeping “inactive” plugins installed. Deactivated code is still on the server and can still be reachable.
- Shared admin accounts. When five people use one login, you can’t enforce MFA properly or tell who did what.
- Backups on the same server. If ransomware or a hosting-account takeover hits the server, the backups go with it.
- Forgotten staging and test sites. An old copy on
dev.yourdomain.comwith three-year-old plugins is often easier to break into than the live site. - Ignoring the agency handover. When a vendor relationship ends, their accounts, SSH keys and API tokens should be removed the same week.
- Fixing the symptom only. Cleaning injected spam without finding the entry point means reinfection within days.
If your site already shows signs of trouble (strange redirects, spam pages in Google results, new admin users you didn’t create), skip ahead to item 12 of the website security checklist and treat it as an incident first.
6. How Golden Info Systems Approaches Website Security
At Golden Info Systems, we build security into websites and web applications from the first brief instead of bolting it on after launch. We’ve been building software for 12+ years and have delivered 850+ projects from Dhaka as a BASIS member company. Our web development services cover CMS-based websites, e-commerce applications and custom web apps, plus Website Rescue and Optimization for existing sites that are underperforming or need fixing, and ongoing support and maintenance that keeps sites secure and up to date after launch.
We apply the same website security checklist to new builds and to rescue projects. On a new site, controls like least privilege, input validation and security headers are part of the specification. On an existing site, we start with an audit and fix the highest-risk items first. We also look at speed alongside security, since outdated plugins usually hurt both; our Core Web Vitals optimization guide covers that side.
Every engagement follows our four-phase process:
- Requirements: we inventory your domains, hosting, CMS, plugins, integrations and user accounts, and agree on which data and pages matter most.
- Planning: we map findings to the twelve checklist items and the OWASP Top 10, estimate effort per fix, and decide what to fix now versus in a rebuild.
- Execution: we apply fixes on staging first, test them, then deploy in priority order.
- Delivery: we hand over a written summary, the incident response plan, backup and alert settings, and a maintenance schedule.
If you’re deciding between platforms before a rebuild, our comparison of headless CMS vs WordPress explains how each option changes your security workload.
7. Frequently Asked Questions
What should a website security checklist include?
At minimum: software patching, HTTPS with HSTS, multi-factor authentication, least-privilege accounts, server-side input validation, upload restrictions, security headers, server hardening, a web application firewall, automated off-site backups with restore tests, logging with alerts, and an incident response plan. Those twelve items cover the main OWASP Top 10:2025 categories. Smaller sites can start with patching, MFA, HTTPS and backups, since those four deal with the most common automated attacks.
How often should I review my website’s security?
Check for updates weekly, review user accounts monthly, and test a backup restore once a quarter. Run a full review against your website security checklist once a year, and again after any major change such as a redesign, a new payment integration, a hosting move, or a change of agency. Sites that take payments or store personal data should add an annual penetration test by someone who didn’t build the site.
Is an SSL certificate enough to keep a website secure?
No. An SSL/TLS certificate encrypts traffic between the visitor’s browser and your server, which stops people on the same network from reading or altering it. It does nothing about an outdated plugin, a weak admin password, or a form that’s open to SQL injection. Attackers who exploit those weaknesses come in over HTTPS like everyone else. Treat the padlock as one item of twelve.
How can I prevent website hacking on a WordPress site?
Keep WordPress core, plugins and themes updated, and delete anything you don’t use. Install plugins only from maintained sources with recent updates. Turn on MFA for every admin, limit login attempts, and give editors editor roles rather than admin rights. Add a WAF, disable file editing in the dashboard, and keep daily off-site backups. Patchstack’s data shows 96% of 2024’s WordPress vulnerabilities were in plugins, so plugin hygiene matters most.
What is OWASP Top 10 protection?
It means your site has controls for each risk category in the OWASP Top 10, the open, community-maintained list of the most serious web application risks. The 2025 edition starts with Broken Access Control, Security Misconfiguration and Software Supply Chain Failures. OWASP Top 10 protection usually combines secure coding (validation, safe queries, access checks), secure configuration (headers, hardening), dependency management and monitoring. A WAF helps, but it cannot cover design or access-control flaws by itself.
Do small business websites really get attacked?
Yes, and usually by automated bots rather than a person who chose you. Bots scan millions of sites for known flaws in popular plugins and frameworks, then exploit whatever responds. Sucuri data cited by Patchstack counted more than 500,000 infected websites in 2024, most of them hit with SEO spam or malicious redirects. Small sites are often easier targets because updates and backups get less attention.
How much does it cost to secure a business website?
It depends on the platform, the age of the code and how much custom functionality the site has. Many controls cost nothing but time: updates, MFA, free Let’s Encrypt certificates, security headers and access cleanup. Paid items usually include a WAF plan, managed backups, monitoring and developer hours for code fixes. Custom web applications with many forms and integrations need the most work, so ask for an audit before accepting a fixed quote.
8. Practical Next Step
Open a spreadsheet and list every admin login, plugin and integration on your site, with the date each one was last updated. Mark anything older than 90 days in red. That single sheet tells you where your website security checklist should start.
Then send it to our team through the Golden Info Systems contact page. We’ll review it, point out the highest-risk items, and come back with a scoped plan and estimate for fixing them.
