Website security checklist for a small business: SSL, headers, backups and the admin login

A small business website is secure when it does seven things: serves every page over HTTPS with a valid certificate, sends the standard security headers, keeps a backup that has been restored at least once, protects the admin login with a strong password and a second factor, blocks spam on its forms, keeps its software updated, and gets two quick checks after every change a developer makes. This checklist covers each of those with one line on why it matters, so the owner can hand it to whoever runs the site and ask for a tick against every line.

None of this needs a security specialist. Most of it is a one time setup plus a monthly look. About 390 people a month in India search for a website security checklist; most of them have just watched a site get defaced, blacklisted by Google or used to send phishing mail.

What SSL certificate does a website need for security?

Any valid certificate from a recognised authority. The padlock does not care whether the certificate was free or cost 10,000 rupees; both encrypt the connection the same way. What it cares about is that the certificate matches the domain, has not expired, and covers the www and non www versions.

• Every page over HTTPS, with HTTP redirecting to it. Why: without it, anything typed into a form on your site crosses the network in plain text, and Chrome marks the site "Not secure" next to your name.
• Certificate valid for both example.in and www.example.in. Why: a certificate on one and not the other throws a browser warning to half your visitors.
• Automatic renewal switched on, and the expiry date in someone's calendar anyway. Why: an expired certificate takes a site off the air for every visitor at once, usually on a weekend, and automatic renewal fails quietly when DNS or hosting changes.
• No mixed content: every image, script and stylesheet loaded over HTTPS. Why: one http:// image in a page removes the padlock and can block the resource.

How to check an SSL certificate for a website

• Click the padlock in the browser, then the certificate details. Why: it shows the issuer, the domains covered and the expiry date in ten seconds, which answers most questions.
• Load the site with http:// typed explicitly, and with and without www. Why: all four versions should land on the same https:// address; if one does not, the redirect or the certificate is incomplete.
• Run the domain through a public SSL test (Qualys SSL Labs is the usual one). Why: it grades the server's configuration, flags old protocol versions still enabled, and shows whether the certificate chain is complete, which the padlock alone does not.

Which security headers should a website send?

Security headers are a few lines the server adds to every response that tell the browser what the site does and does not allow. They cost nothing, take an hour to set up, and close whole categories of attack. Most small business sites send none of them.

• Strict-Transport-Security (HSTS). Why: it tells the browser to use HTTPS for this domain for the next year even if someone types http://, which stops a class of interception on public WiFi.
• Content-Security-Policy, in report only mode to start. Why: it lists where scripts may load from, so an injected script from an unknown domain does not run; start in report mode because a strict policy breaks embedded maps and chat widgets until it is tuned.
• X-Content-Type-Options: nosniff. Why: stops the browser guessing a file's type, which is how an uploaded "image" gets executed as a script.
• X-Frame-Options, or the frame-ancestors rule in the policy above. Why: stops another site embedding your pages inside an invisible frame to trick visitors into clicking.

Check them with a free scanner such as securityheaders.com, which marks each header present or missing. Add HSTS only after HTTPS is complete everywhere, because it cannot be undone quickly, and be careful with the includeSubDomains option if any subdomain still runs on plain HTTP.

How should backups work, and why restore one?

A backup you have never restored is a hope, not a backup. Sites we have seen lose data usually had backups; they had either stopped silently months earlier or covered the files and not the database.

• Files and database both backed up, on a schedule. Why: a site is both; a backup of one without the other restores a broken site.
• Stored somewhere other than the hosting server. Why: when the server is compromised or the account is suspended, backups on the same machine go with it.
• Daily for a site that takes enquiries or orders, weekly for a brochure site. Why: the schedule is the maximum amount of work you will lose.
• Retention of at least 30 days, not just the last copy. Why: an infection is often found weeks after it happened, and the last copy is already infected.
• Restored once, to a staging copy, and the result checked. Why: this is the only way to know the backup works and how long a restore takes; do it at handover and again once a year.

Read what a hosting plan means by "daily backups". On a shared host it often means one copy, overwritten daily, on the same machine. The maintenance cost article linked from this piece lists what a yearly plan should cover.

How do you protect the admin login?

The admin login is the door. Most small business site breaches are not clever; someone tried a password that leaked from another site, or "admin" with the company name and 123, and it worked.

• One account per person, no shared admin login. Why: when someone leaves, you remove their account rather than change a password everyone knows.
• Passwords of 14 characters or more, from a password manager, different from every other login. Why: a leaked password from any other site is tried against yours within days.
• Two factor authentication on every admin account. Why: it makes a stolen password useless on its own, and it is free on every modern platform.
• Login attempts limited, with a lockout after five or so failures. Why: it turns a million guesses into five.
• Every credential in the client's own name, listed in one place, with the developer's access removable. Why: when you change developers you should be able to remove the old one in five minutes without losing access to anything yourself. This is the item most owners discover they cannot do on the day they need to.

How do you stop form spam without losing real enquiries?

Every contact form on the public web gets spam within days of going live, and the results range from a nuisance to a blacklisted domain.

• Server side validation of every field, not just in the browser. Why: bots do not run your JavaScript; anything checked only in the browser is not checked.
• A CAPTCHA or an equivalent challenge on public forms. Why: it removes most automated submissions; the tick box version is enough for a contact form and does not punish real visitors.
• Form submissions stored in the database as well as emailed. Why: email delivery fails, and an enquiry that only existed as an email is gone.
• Outgoing mail sent through an authenticated service with SPF, DKIM and DMARC records set. Why: without them your enquiry emails land in spam and anyone can send mail that looks like it came from your domain. Check this first if enquiries "stopped coming"; usually they stopped arriving.

What is on a PHP website security checklist?

Most custom sites in India run on PHP and MySQL, including ours. Framework or no framework, the same handful of habits stop the same handful of attacks.

• Every database query uses prepared statements. Why: it makes SQL injection, still the most common attack on custom PHP sites, impossible in that query.
• Every value printed into a page is escaped for HTML. Why: it stops a comment or a product name someone typed from running as a script in the next visitor's browser.
• File uploads checked by type and size, renamed, and stored outside the web root or served through a script. Why: an uploaded file that can be executed is a full compromise.
• A supported PHP version, updated within a few months of a release. Why: old versions stop getting security fixes; PHP 7 has been out of support since the end of 2022.
• Error display off in production, logging on. Why: a raw error message tells an attacker the file paths, the database name and the library versions.
• Configuration files with credentials outside the web root and out of version control. Why: a config file that can be downloaded is a database that can be downloaded.
• Directory listing off, and no phpinfo, .git, backup zips or old copies reachable from the web. Why: these are the first things a scanner looks for, and they are found on a surprising number of live sites.

What are the two checks after every developer change?

A site is most often broken by the people maintaining it, not by attackers. Two checks after every change catch most of it, and they take five minutes.

• Load the homepage, one inner page and the contact form over HTTPS in a private window and confirm the padlock, the redirects, and that the form still submits and arrives. Why: the most common regressions are a redirect loop, a lost certificate after a hosting change, and a form that silently stopped sending.
• Run the security headers scan and the PageSpeed check again and compare with the last result. Why: a change that removes a header or adds 2 MB of script is visible here and nowhere else, and the person who made the change is still available to fix it.

What does keeping a website secure cost?

Most of the checklist is free: the certificate, the headers, two factor authentication. What costs money is hosting that does off site backups with retention and keeps PHP current, roughly 3,000 to 15,000 rupees a year for shared hosting in India, where the bottom of the range shares a server with hundreds of sites and keeps one backup copy and the top gives you your own resources; and a maintenance plan covering updates, checked backups and the monthly look, roughly 1,000 to 10,000 a month, where a brochure site needs the bottom and a store with daily orders the top. A paid certificate, if you want one, adds roughly 1,000 to 10,000 a year.

Questions

Is a free SSL certificate as secure as a paid one?

Yes. Both encrypt the connection with the same methods and both show the padlock. A paid certificate adds a warranty and, for some types, the organisation's name in the certificate details. For a small business website the free certificate, renewed automatically, is the right choice.

How often should a small business website be backed up?

Daily if it takes enquiries or orders, weekly if it is a brochure site that rarely changes, and always before any developer change. Keep at least 30 days of copies somewhere other than the hosting server, and restore one to a test copy at least once a year.

How do I know if my website has been hacked?

The usual signs are a warning next to your result in Google or in Search Console, pages you did not create appearing in search, redirects to other sites from your pages, a spam warning from your email provider, or the hosting company suspending the account. Search Console's security issues report is the first place to look.