How To Increase The Security of Your Content Management System (CMS).

KEEPING YOUR CMS SECURE IN 2026

I first wrote this post back in May 2022, and the advice in it aged the way most security advice does: some of it held up, and some of it became actively bad. A couple of the plugins I recommended then are no longer maintained, and pointing you at an abandoned security plugin is worse than pointing you at nothing. So this is a full refresh, based on what I actually do on the Umbraco and WordPress sites I look after today.

One thing has not changed: attackers do not care how big you are. Most attacks are automated. Bots scan the entire internet for known vulnerabilities, default login pages and unpatched software, and they will find your site whether you are a multinational or a one-person shop. Sometimes the goal is money, sometimes it is spam links, and sometimes your server simply becomes a launchpad for attacking someone else. What has changed is that the defences that stop the vast majority of these attacks are now well understood and mostly free, so there is very little excuse for skipping them.

KEEP THE CMS AND ITS PACKAGES PATCHED

This is the single highest-value thing you can do. Most successful CMS compromises exploit a vulnerability that already had a patch available; the site owner just had not applied it. Apply security patches as soon as they are released, and that means the whole stack: the CMS itself, every package or plugin, the underlying runtime (.NET for Umbraco, PHP for WordPress) and the server operating system.

Just as important is knowing your version's support dates. Umbraco 13 loses security support on 14 December 2026. After that date, any newly discovered vulnerability in v13 stays unpatched on your live site forever, so if you are on 13 you should be planning the move to Umbraco 17, the current long-term support release, now rather than in a December panic. The same logic applies to WordPress: an out-of-date core or an abandoned theme is an open door, no matter how good the rest of your setup is.

TURN ON TWO-FACTOR AUTHENTICATION EVERYWHERE

In 2022 I spent several paragraphs on brute force and dictionary attacks. The honest 2026 answer to both is two-factor authentication. Credential lists from other breaches are constantly replayed against login pages, and a strong password alone no longer guarantees anything if that password has leaked from somewhere else.

Enable 2FA on the CMS backoffice (Umbraco supports it, as does WordPress), and, just as importantly, on the accounts around the site: your hosting control panel, your domain registrar, your DNS provider and your email. An attacker who controls your DNS or email owns your website without ever touching the CMS. Use an authenticator app or a passkey rather than SMS where you can. Strong, unique passwords from a password manager still matter; ten or more characters with a mix of letters, numbers and symbols remains the sensible baseline.

GIVE ACCOUNTS THE LEAST PRIVILEGE THEY NEED

Every CMS worth using has user roles and permissions, so use them. Content editors do not need administrator rights, and most sites I inherit have far more admin accounts than they have administrators. Each extra admin account is another set of credentials that can be phished or leaked.

Give each person their own named account, grant the minimum access their job needs, and review the user list a couple of times a year. Remove accounts for people who have left, and remove agency or developer accounts that are no longer active. This one costs nothing and takes twenty minutes.

HTTPS EVERYWHERE, WITH HSTS

In 2022, SSL certificates were something you bought. In 2026 they are free from Let's Encrypt or bundled with your hosting, so there is no reason for any page of your site to be served over plain HTTP. HTTPS prevents anyone sitting between your visitor and your server from reading or modifying the traffic, including login credentials.

Go one step further and enable HSTS (HTTP Strict Transport Security) with a long max-age. This tells browsers to refuse insecure connections to your site entirely, which closes the gap where a visitor's very first request could still go over HTTP.

SET SECURITY HEADERS

Security headers are a cheap, high-value layer that most sites still do not set. The two I would prioritise:

• Content-Security-Policy (CSP): controls which scripts, styles and other resources the browser is allowed to load, which blunts cross-site scripting and the injection of malicious scripts. Start with a report-only policy, review what it flags, then enforce it.
• X-Content-Type-Options: nosniff: stops browsers guessing file types, which prevents a class of attacks where an uploaded file is executed as something it should not be.

Add Referrer-Policy and a frame-ancestors rule (to stop your site being loaded inside someone else's page) while you are there. A free scan at securityheaders.com will grade your site in seconds and show you exactly what is missing.

AUTOMATE YOUR DEPENDENCY SCANNING

Modern websites are mostly other people's code: NuGet packages, npm packages, plugins and themes. New vulnerabilities in those dependencies are published every week, and you want to hear about them from a scanner, not from an attacker.

If your site's code lives in source control, turn on automated dependency scanning. GitHub's Dependabot alerts are free and take minutes to enable, and equivalents exist for every platform. For .NET projects, restoring packages will also warn you about known-vulnerable versions. The point is that the checking happens automatically, every day, without anyone having to remember.

BACKUPS YOU HAVE ACTUALLY RESTORED

A backup you have never restored is a hope, not a plan. Automate backups of both the database and the media files, keep copies somewhere separate from the web server itself, and then, crucially, test them by actually performing a restore. Do it at least a couple of times a year. The moment you discover your backups do not restore should never be the moment you need them, and if the worst does happen, a clean, tested backup turns a disaster into an inconvenience.

CHOOSE MAINTAINED PACKAGES, NOT ABANDONED PLUGINS

The original version of this post recommended specific plugins for hiding your login page. I am deliberately not doing that again. Some of those tools are no longer maintained, and hiding the login URL was always security through obscurity: mildly useful against lazy bots, useless against anything targeted. Rely on 2FA, lockouts and patching instead.

The broader lesson is about plugins generally. Most CMS extensions are written by third parties, and every one you install is code you now depend on. Before adding anything, check when it was last updated, whether it supports the current CMS version, and whether the maintainer is responsive. Prefer a small number of well-maintained packages over a large number of convenient ones, audit what you already run, and remove anything you no longer use. An abandoned plugin does not just stop improving; it becomes the weakest link in your site.

STILL WORTH DOING

A few things from the original post remain good practice. Use the login lockout mechanisms built into Umbraco and WordPress, which throttle repeated failed attempts. If your team can work with it, restrict access to the backoffice (/umbraco, /wp-admin) by IP address or put it behind a VPN; with more people working from changing locations this suits some teams and not others, so treat it as an option rather than a rule. And putting a web application firewall such as Cloudflare in front of the site filters out a large amount of automated hostile traffic before it ever reaches you.

TOP SECURITY TIPS FOR 2026

• Patch the CMS, its packages and the underlying runtime promptly, and know your version's end-of-support date. Umbraco 13 loses security support on 14 December 2026, so plan the upgrade to Umbraco 17 LTS now.
• Enable two-factor authentication on the backoffice, hosting, domain, DNS and email accounts.
• Give every user the minimum permissions they need, and remove old accounts.
• Serve everything over HTTPS and enable HSTS.
• Set security headers, starting with Content-Security-Policy and X-Content-Type-Options.
• Turn on automated dependency scanning so vulnerable packages are flagged the day they are published.
• Automate your backups, store them off the server, and test them by restoring.
• Only install packages that are actively maintained, and remove any you no longer use.

Should you need any help securing or upgrading your own website, please don't hesitate to get in touch with me.