Running a site
HTTPS, backups and updates, explained
No hosting choice is safe against everything. Here is what the padlock covers, where real risks usually sit for each kind of site, and a short routine for backups and accounts.
“Is my website secure?” has no single answer, because security is about particular threats. A better question is: what could go wrong for a site like mine, and what covers it? This note separates three things people lump together, HTTPS, updates and backups, and then compares a few common kinds of site.
What HTTPS does
HTTPS is the padlock in the browser. It uses Transport Layer Security (TLS) to give a connection three properties: encryption, so others on the network cannot read what is sent; integrity, so it cannot be changed on the way without detection; and authentication, so the browser can check it is talking to the server for that domain. Together these defend against someone sitting between the visitor and your site, for example on shared public Wi-Fi.
It does not do everything:
- It does not protect a page that loads parts over plain HTTP. A secure page that loads an image or script over HTTP leaves that part open to tampering. Browsers may upgrade or block such requests, but it is still a mistake to leave them.
- The first visit can be exposed. If someone types your address without “https” and the site does not enforce it, the very first request can be intercepted. A setting called HSTS reduces this.
- A certificate proves control of a domain, not that the business is honest. Let’s Encrypt, for instance, issues a certificate after checking that the requester controls the domain. A scam site can have the padlock.
- It does not protect a server or an account that has been broken into, and a poorly configured server can weaken the connection.
Many hosts issue and renew certificates automatically. Check that yours renews, because an expired certificate makes browsers show a warning to visitors.
Updates
Software that is out of date is a common way sites are broken into. OWASP, a respected non-profit that lists the most common web risks, names “Vulnerable and Outdated Components” and “Security Misconfiguration” among its categories in its 2021 edition, along with weak login handling. A site with no software to update has less to go wrong in this way, and a site built on a content system with plugins has more.
Backups
A backup is a copy kept somewhere other than the place that could fail. WordPress’s own hardening guide recommends regular backups including the database, snapshots of the whole installation kept in a trusted place, and keeping some old enough to show the site before an unnoticed break-in. Two further points apply to any kind of site: keep the copy outside the account that hosts the site, and test a restore at least once, because an untested backup is a hope.
Three kinds of site, three sets of risks
This comparison is judgement, not a ranking.
| Kind of site | Where the risk mostly sits | What needs doing |
|---|---|---|
| A static, frontend-only site | The hosting account, the domain account and any third-party scripts. There is no database or login on the site itself to attack. | Strong sign-ins on the accounts, a copy of the site files, renewal reminders. |
| A content system such as WordPress | The core software, plugins and themes, admin logins, and file permissions. | Regular updates, removal of unused plugins, two-step sign-in, backups of files and database. |
| A hosted website builder | The platform’s own security, which you depend on, and your account sign-in. | A strong sign-in, and knowing what you can export if you leave. |
A static site is not “unhackable”. Its risks are fewer and sit elsewhere, mostly in the accounts that control it. A content system gives editors more freedom and costs more attention.
What the host covers and what you do
Hosting companies describe a shared responsibility. Vercel’s documentation, for example, says that deployments are served over HTTPS with automatically generated certificates, and that a platform-wide firewall with DDoS mitigation is on for all customers. That covers the platform. It does not cover your passwords, who has access to your account, or what you publish. Whichever host you choose, ask what it covers and what is left to you.
A short routine
- Use a unique, long password for the domain registrar and the hosting account, and turn on two-step sign-in.
- Keep a copy of the site files and content somewhere that is not the host’s account.
- Note the renewal dates for the domain and any paid hosting, and set reminders.
- If the site uses a content system, update it on a schedule and remove what you do not use.
- Check once a quarter that the padlock appears on every page and that the contact routes work.
For who should hold each of those accounts, see who owns your website, domain and hosting.