TYPO3 Security: The Measures With Real Effect

Securing TYPO3: What Actually Protects You

TYPO3 is regarded as a secure system, and it has earned that: there is a security team that publishes vulnerabilities in a coordinated way. That very openness shifts the responsibility to the uncomfortable place, though: to whoever runs the site.

The entry points are known

Attacks on TYPO3 installations rarely use spectacular vulnerabilities. They use known holes in out-of-date installations, in the core or in extensions; weak backend accounts; and server environments that are not current themselves.

That is good news, because all three can be closed with manageable effort. It is also uncomfortable, because it means anyone affected usually failed to do something rather than missed something.

What actually works

Stay current. By far the biggest lever. A supported version receives security fixes; an expired one does not. What that means in detail is set out under LTS and in the version overview.

Keep the extension list short. Every installed extension is additional attack surface and additional update effort. What is not needed should be removed rather than disabled.

A second factor in the backend. A stolen password alone is then not enough. For accounts with administrative rights that should be the normal case.

Grant permissions sparingly. Not everyone needs administrative rights. An editor who only maintains their own area only needs access there, and does less damage if the worst happens.

Serve everything encrypted. Obvious, and worth double-checking: backend access and forms have to run over HTTPS too, not just the home page.

Backups you can actually restore. A backup only counts as one once it has been restored at least once. We check that rather than assume it.

What brings little

Some measures reassure more than they protect. Hiding the backend behind a secret address does not replace a strong account; addresses get around and turn up in logs.

The same goes for security extensions that mostly produce notifications. If nobody reads them, they are an extra component with no benefit, and one more thing that wants keeping current.

Prepare for the bad day

The question is not only how to prevent an incident but what happens when one occurs. Who has access to the server and the hosting? Where do the backups sit? Who decides whether the site goes offline?

Answering those questions once, calmly, takes half an hour. Answering them during an incident costs the time you do not have then. What ongoing care covers is set out under TYPO3 maintenance.

What to do when it has happened anyway is set out step by step under TYPO3 compromised.

Common questions

How do we hear about vulnerabilities?

The TYPO3 Security Team publishes advisories for the core and for extensions through official channels. Anyone running an installation should be subscribed to those channels, or have engaged somebody who is.

The flip side matters: publication also makes public what an attacker can look for. The time between the advisory and the fix going in is therefore the decisive window.

Is updating once a year enough?

No. Security-relevant updates belong in promptly, not on an annual cycle. The rest can be bundled.

The useful split is: critical fixes at once, everything else in planned waves. That keeps the effort predictable without leaving an open window open for months.

We have been hacked. What now?

First, do not overwrite anything. The reflex to restore a backup immediately destroys the evidence, and if the cause stays unknown, the restored installation is compromised again shortly afterwards.

A sensible order: preserve the state, lock the accounts and change the passwords, find the entry point, then clean up or rebuild cleanly. Only after that, close the hole it came through.