9 October 2026 · 14 min read
Website security is the set of habits and settings that stop other people from reading, changing or breaking your website without permission. For a small business that usually comes down to a short list of unglamorous jobs: encrypt the connection, protect the logins, keep software up to date, keep working backups, and know what to do when something goes wrong. Most break-ins exploit one of these being skipped, not a clever new trick.
This guide is written in two layers. The first half is a checklist anyone who owns or manages a website can work through, with no coding. The second half is for the developer or agency that builds and runs it, and covers TLS, security headers, cookies and the OWASP Top 10. Read the part that fits you, or both.
One honest note before we start. SREmonitor is a monitoring product, not a security scanner. It does not look for vulnerabilities or malware, and later in this guide we explain exactly where monitoring helps and where you need other tools.
Security failures on ordinary websites tend to come from a handful of causes, and the industry's own ranking of them is a useful map. The OWASP Top 10 is the best-known list of web application risks. Its 2025 edition puts broken access control first, security misconfiguration second and a new category, software supply chain failures, third. In plain English, the top three read like this:
Notice what these have in common. None needs a genius attacker. Much attack traffic is automated and checks every site it can reach for known weaknesses, so the size of your business is not much protection. A small site that is easy to break gets broken, and one with the basics in place is a worse target than the next one along.
You do not need to understand the technology to do these. You need to know they exist, ask the person who manages your site whether each is done, and check the answer.
HTTPS encrypts the connection between your visitor and your site, so passwords and form data cannot be read in transit. Browsers label sites without it as not secure. Most hosts now provide it free, so there is no reason to run without it.
The part owners miss is renewal. A certificate that expires makes browsers show a full-page warning, and for most visitors that is the same as the site being down. Certificates are also getting shorter. Under rules agreed by browsers and certificate authorities, the maximum lifetime of a publicly trusted certificate fell to 200 days on 15 March 2026, drops to 100 days on 15 March 2027 and to 47 days on 15 March 2029. Short lifetimes are only workable if renewal is automatic, so confirm yours is. If your host or certificate provider handles this for you, ask how it will warn you if renewal ever fails.
Stolen or guessed passwords remain one of the easiest ways in. Guidance from the UK National Cyber Security Centre (NCSC) and the Information Commissioner's Office (ICO), plus standard good practice, comes down to this:
Your email account deserves special care, because almost every other account can be reset through it. Your domain registrar matters too. Whoever controls your domain controls where your website and your email point.
Software has bugs, and some bugs are security holes. When a fix is released, the hole becomes public knowledge, and attackers race to use it on sites that have not updated yet. That is why the NCSC's malware guidance tells organisations to install security updates promptly, especially on anything facing the internet.
If your site runs on a content management system such as WordPress, this covers the core software, your theme and every plugin. Switch on automatic updates where you can, delete plugins and themes you no longer use, and be wary of abandoned ones that no longer receive fixes. Every extra plugin is extra code that someone has to keep patched.
Backups turn a disaster into an inconvenience. The NCSC and the ICO both advise keeping regular backups in a separate place from the system they protect, ideally offline or offsite so that an attacker who gets in cannot also delete them, and testing that you can actually restore from them. A backup you have never restored is a hope, not a plan. Ask your host what is backed up, how often, where the copies live, and how long a restore would take.
An editor who writes blog posts does not need to be an administrator. The ICO's advice is to limit access so people see only what their role requires, and to remove access promptly when someone leaves. That includes freelancers, agencies and former staff. Review who has a login to your site, your hosting and your domain at least twice a year.
Many attacks do not touch your website at all. They trick a person into handing over a password. Unexpected pressure to act fast, odd wording, or a request for payment or login details should make you stop and check with the sender another way. A fake message that appears to come from your host or domain registrar is a classic route to taking over a site.
Data you do not hold cannot be stolen. The ICO advises deleting personal data you no longer need. This also lines up with data protection law, which expects you to keep personal data only as long as necessary. Look at what your site collects in forms and accounts and ask whether you need all of it and for how long. Our compliance monitoring guide covers the privacy side of this in more detail.
Decide now who does what if your site is hacked: who to call, how to take the site offline, where the clean backup is, and who needs to be told. In the UK, if an incident involves personal data and meets the threshold, you must report it to the ICO within 72 hours of becoming aware of it. That clock is short, so write down the contact details and the steps before you need them.
If you build or run websites, the checklist above still applies, and so does a layer of technical controls. These are the ones with the best return, drawing on Mozilla's web security guidelines.
HTTP response headers tell the browser how strictly to treat your pages. They are cheap to add and block whole categories of attack. Mozilla marks Strict-Transport-Security and X-Frame-Options as mandatory for all websites, Content-Security-Policy as mandatory for new sites, and the other two as recommended. The effort varies a lot.
| Header | Recommended setting | What it does |
|---|---|---|
| Strict-Transport-Security | max-age=63072000 (two years). Mozilla's minimum is six months. | Tells browsers to use HTTPS only for your site, which defeats downgrade attacks. Test before adding includeSubDomains or preload, because they are hard to undo. |
| Content-Security-Policy | Start restrictive and add only the sources you need. Use the Report-Only version first to see what would break. | Controls which scripts, styles and other resources a page may load, which limits the damage from injected scripts. Mozilla rates it high benefit but high effort. |
| X-Frame-Options | DENY, or SAMEORIGIN if your site frames itself | Stops other sites from embedding yours in a hidden frame to trick clicks (clickjacking). Pair it with the CSP frame-ancestors directive. |
| X-Content-Type-Options | nosniff | Stops browsers guessing that a file is a script or stylesheet. Make sure every file has the correct content type. |
| Referrer-Policy | strict-origin-when-cross-origin, or stricter | Limits how much of your page address is passed to other sites when visitors click away. |
Add a Permissions-Policy header as well, to switch off browser features your site does not use, such as the camera, microphone and location. Start with the HSTS, framing and content-type headers, which are low effort, and treat Content-Security-Policy as a project, not a quick fix.
__Host- prefix and keep session lifetimes short.The 2025 list is a handy review checklist for any custom application. Here it is in plain English, with the most useful habit for each.
| Risk | What it means | A good habit |
|---|---|---|
| A01 Broken Access Control | Users can act outside their permissions. Server-side request forgery now sits under this heading. | Check permissions on the server for every request. Deny by default. |
| A02 Security Misconfiguration | Insecure defaults, open services, verbose errors, missing hardening. | Keep configuration in code, review it, and use one hardened baseline for every environment. |
| A03 Software Supply Chain Failures | A dependency or build step you rely on is vulnerable or compromised. New in 2025. | Pin and review dependencies, scan them automatically, and remove what you do not use. |
| A04 Cryptographic Failures | Sensitive data is unprotected in transit or at rest, or weak cryptography is used. | Use HTTPS everywhere, standard libraries and strong password hashing. Do not invent your own. |
| A05 Injection | Untrusted input is run as a command or query, as with SQL injection and cross-site scripting. | Use parameterised queries and context-aware output escaping. Validate input. |
| A06 Insecure Design | The design itself lacks a needed control, so no amount of careful coding fixes it. | Think about abuse cases early, such as what happens if someone scripts this form a million times. |
| A07 Authentication Failures | Weak login, session or password-reset handling. | Support MFA, rate-limit login attempts and protect reset flows. |
| A08 Software or Data Integrity Failures | Code or data is trusted without checking it has not been altered. | Verify signatures and sources for updates, packages and serialised data. |
| A09 Security Logging and Alerting Failures | Attacks and failures go unnoticed because nothing is logged or nobody is alerted. | Log security events, protect the logs and alert a human to the ones that matter. |
| A10 Mishandling of Exceptional Conditions | Errors and unexpected states are handled badly, leading to leaks or insecure fallbacks. New in 2025. | Fail closed. Handle errors on purpose, and never show stack traces to users. |
Cyber Essentials is the UK government-backed scheme that gives organisations a recognised baseline. It organises the basics into five technical themes: firewalls, secure configuration, security update management, user access control and malware protection. Look at them next to this guide and you will see the same ideas. Certification can be a requirement for some public sector and larger customer contracts, so it is worth knowing about if you sell to those buyers.
Prevention is only half of security. The other half is noticing quickly when something is wrong, which is why logging and alerting appears on the OWASP list at all. Monitoring does not stop an attack, but it shortens the time between a problem starting and a person knowing about it.
Here is what an uptime and performance monitor can do for you, and the limits:
What SREmonitor does not do: it does not scan your site for vulnerabilities, detect malware, check your security headers, watch for defacement or block attacks. For those jobs, use the tools and practices in this guide: updates, backups, MFA, a firewall or WAF, dependency scanning and, for higher-risk sites, a professional security test. Treat monitoring as the smoke alarm that tells you something is wrong, not the lock on the door.
No. HTTPS protects data in transit, so it is necessary but it is only one control. A site can use HTTPS and still run an outdated plugin, have a weak admin password or have no backups. Think of it as the starting point.
Yes. Much hostile traffic is automated and probes every site it can find for known weaknesses, without caring whose it is. Small sites are not singled out, but they are not skipped either, and they often have less protection.
Apply security updates as soon as you reasonably can, and turn on automatic updates where they are safe to use. For a content management system, a quick weekly check of core, themes and plugins is a sensible minimum, with critical fixes applied within days.
Change the passwords for your hosting, admin and email accounts from a clean device, and take the site offline or into maintenance mode if you can. Contact your host, restore from a known-good backup, and find and fix how the attacker got in, or they will return. If personal data may have been exposed, note the time you became aware, because the 72-hour limit for reporting to the ICO runs from then, and get advice promptly.
For a brochure site, the checklist above covers most of the risk. If you handle payments, health data, large amounts of personal data or run a custom web application, a penetration test from a reputable provider is a good investment, and some customers will ask for one.
Guidance read in October 2026. Standards and rules change, so check the originals before relying on a detail.
More from the blog
Want this monitored automatically instead of checked by hand?
SREmonitor checks uptime, Core Web Vitals, and compliance on a schedule, and only alerts you when something has actually broken.
Start Monitoring Free →