How to keep an old PHP 5 or PHP 7 website online safely in 2026

Old PHP does not mean an old server

Keeping an old PHP website online safely has less to do with the code than with what surrounds it. Separate the old application from everything else, keep everything that is not the old application completely current, and shrink both what the site can reach and what can reach it. Done properly, an old site becomes a contained thing with a small blast radius rather than a soft spot on a busy shared server.

This is the point most people miss. PHP is one component. The operating system, the web server, the TLS library and the database all have their own release cycles, and there is no technical reason a site on PHP 5.6 needs a 2015 operating system underneath it. Frozen application, current everything else.

The web server in front matters most. When a current nginx or Apache handles the connection, modern software speaks TLS to the internet, deals with the certificate and parses the incoming request. Your old PHP never touches the network directly. So the first question for any host offering to keep your old site running is not about PHP at all: ask what the operating system is and when it was last patched. If the whole machine is as old as the site, walk away.

One site, one user, no neighbours

The real danger with old code on ordinary shared hosting is the company it keeps: hundreds of accounts on one machine, files often readable across accounts, and PHP processes running as the same user for everybody. One compromised site becomes everybody's problem, and the site running unpatched code gets picked first.

Containment means the old site runs as its own system user, in its own PHP process pool, restricted with open_basedir so the code cannot read its way out of its own directory. On a site with real value attached, its own container or small server is cleaner still, and rolling it back to a known good state becomes a five minute job instead of an evening.

The test to apply: if this site were fully compromised tomorrow, what else would the attacker have? On a well arranged legacy setup the honest answer is "that site and nothing else". On cheap shared hosting nobody can tell you.

Take away what the code never uses

Most old PHP applications use a fraction of what PHP can do. The rest is capability sitting there for someone else's benefit.

• Switch off the functions that run system commands unless the application genuinely needs them. Most brochure sites and plenty of bespoke systems never call one.
• Stop PHP fetching and including files from remote addresses. Old code rarely wants this and injected code almost always does.
• Make the upload directory unable to execute PHP at the web server level, so an uploaded file is just a file.
• Give the code the narrowest write permissions that let it work. Plenty of old sites have everything writable because that was the quickest fix ten years ago.
• Delete the leftovers: old installers, a stray copy of phpMyAdmin, backup zips in the web root, a folder called old or test. Every one of them is reachable.

If the site is finished and only exists to be read, make the file tree read-only and give the database user select rights and nothing more. An archive that cannot change cannot be changed by anyone else either.

Watch outgoing traffic and limit the database

A web application firewall in front of an old site is worth having, and we put one there as standard. It is pattern matching, though, and it will not catch everything aimed at code nobody has patched in years.

The other direction is where old sites give themselves away. Once something has got in, nearly everything it wants to do involves outbound connections: sending spam, calling home, mining, or being rented out as a relay. A site that should only ever talk to a payment gateway and a courier API has no business connecting anywhere else, and limiting where it can reach turns a compromise into a nuisance. Old applications also change rarely, so an alert on any PHP file appearing or changing when nobody deployed anything is nearly always real.

Old code and SQL injection go together, so limit what a successful injection could do. Old sites routinely connect with an account holding every privilege, because whoever set it up in 2011 used the root login and it worked. The application needs to read and write rows. It very seldom needs to create or drop tables, and never needs to read files from disk. Cutting that account back is an hour's work. Keep the database server itself current, and check the site afterwards, because newer releases are stricter about sloppy queries.

Hold a copy you own, and do the jobs only you can do

Backups need to live somewhere the site cannot reach, with enough history to go back past a compromise nobody spotted for a fortnight. The legacy-specific job is different: get the source code into your own hands, in version control, with a note of the PHP version, database version, extensions, cron jobs and every external service it talks to. On an old bespoke system that usually lives in one person's head, and that person left in 2019. With it, you can move hosts, get another developer to quote, or rebuild.

We can isolate the site, patch around it, watch it and back it up. The rest stays yours:

• Deciding what data the site should still hold. Ten years of customer records is ten years of liability.
• Turning off forms, exports and login areas nobody has used in years.
• Auditing who has an account: former staff, former developers, former agencies.
• Keeping card details off the server by using a gateway's hosted payment page.

When we would tell you no

If a site is already compromised, it gets cleaned before it moves, not after. If it stores card numbers in its own database, that stops before anything else happens. And if a system holds sensitive personal data and the code cannot be contained well enough, we will say the risk is too high and talk to you about replacing it. Our guide to rebuilding versus re-hosting an old system covers that decision.

Everything else, we can generally take. Our legacy PHP hosting exists because hosting companies abandon old sites long before the businesses running on them do, and an old OpenCart shop falls under the same arrangement, with the shop-specific jobs written up separately. Send us the web address and what you know about the code, or ring 01623 650333. Out of hours and at weekends, Olly, our director, picks up problems himself. dijihost Complete Hosting starts at £1 a day + VAT, and a contained legacy setup is priced on what it actually takes.

Related