Legacy PHP security checklist

Forty checks you can put to your developer, your host or yourself. Every "no" or "don't know" is a finding.

You don't need to be technical to use this. Read each line, and answer yes, no or don't know. "Don't know" counts as a finding, because if nobody knows, nobody is managing it.

This isn't a penetration test or a certification, and a perfect score doesn't prove you're safe. It's a fast way to see where the gaps are.

Book a free conversation Legacy System Assessment, from £2,500

1. Supported software

Your PHP version still receives security fixes. Check it
Your framework or CMS version is supported. (For example Laravel, Symfony, WordPress, Drupal.)
Your database version is supported.
Your server's operating system is supported.
Plugins, themes and packages are current, with none abandoned.
Someone checks dependencies for known vulnerabilities on a regular basis. (In Composer projects, composer audit does this.)
There's a list of everything the application depends on.

2. Access and accounts

Everyone with admin access has their own named login. No shared accounts.
Multi-factor authentication is on for admin areas, hosting, email, the domain registrar and server access.
Passwords are strong and not reused. A password manager is in use.
Accounts of people who've left have been removed, including former developers and agencies.
Each person has only the access they need.
You know who has access to the server, the database and the code.
Login pages limit repeated guesses.

3. The application itself

Passwords are stored using a modern hashing method, not MD5, SHA-1 or plain text.
Database queries are protected against injection.
User input is cleaned before it's shown, to prevent script injection (cross-site scripting).
Forms are protected against forged requests (CSRF).
File uploads are restricted by type and size, and can't be run as code.
People can only see their own data. Changing a number in a URL doesn't show someone else's record.
Error details and debug mode are off in the live site.
Passwords, keys and secrets aren't stored in the code or in public repositories.

Security audit and fixes

4. The server and hosting

The site runs over HTTPS only, with a valid certificate that renews automatically.
A firewall is in place, and only the ports that are needed are open.
The database isn't reachable from the public internet.
Server access is by key or protected login, not weak passwords.
Sensitive files can't be downloaded from the web, such as configuration files, backups and version-control folders.
Directory listings are turned off.
Test pages and information pages (such as phpinfo()) have been removed.
File permissions are sensible, and the application isn't running with more rights than it needs.

5. Backups and recovery

Backups exist for both files and database.
They're stored somewhere other than the live server.
Someone has actually restored one, and it worked.
You know how long recovery would take, and what you'd lose.
Backups are protected from tampering and unauthorised access.

6. Monitoring and process

Errors and unusual activity are logged, and someone looks.
You'd be told if the site went down, or if files changed unexpectedly.
There's a routine for applying security updates, with a named person.
There's a plan for a breach, including who to tell. What to do if hacked
The application and servers are documented, so the knowledge isn't in one person's head. Documentation

How to read your score

Count your no and don't know answers.

Result	What it suggests	Next step
0 - 5	A well-managed system	Keep a regular review. Maintain it
6 - 15	Real gaps, likely fixable in stages	An assessment will prioritise them. Legacy System Assessment
16 and above	Significant exposure, often a sign nobody is looking after the system	Start with the highest-risk items now, and consider a takeover

Not all findings are equal. An unsupported PHP version, no multi-factor authentication on admin access, and untested backups matter far more than a missing directory-listing setting. Prioritising is the real work.

What to fix first

If you do only a few things:

Upgrade anything unsupported. PHP upgrades
Add multi-factor authentication to admin, hosting, email and server access.
Remove accounts that shouldn't exist.
Make sure backups exist, are stored elsewhere, and restore.
Close the obvious holes: exposed files, debug mode, test pages.
Set up monitoring and a patching routine. Ongoing care

Why it matters beyond hacking

Customers, insurers and auditors ask these questions. Cyber Essentials and insurer questionnaires
UK GDPR expects appropriate security for personal data. Whether yours is appropriate is a legal question for your adviser. Data protection and security
A breach is expensive: downtime, clean-up, reporting and lost trust.

Frequently asked questions

Is this a penetration test?

No. It's a self-check. A penetration test attacks a running system. My assessment reviews code, configuration and architecture. Security audit

I answered "don't know" a lot. Is that bad?

It's useful. It shows you where nobody has visibility. That's the first thing to fix.

Can you fix what the checklist finds?

Yes. I prioritise the findings, fix them with tests and a staged rollout, and give you a record of what changed.

Do I need to answer every question myself?

No. Many are best answered by your developer or host. Asking them is itself a useful test.

Will you need access to my live data?

Usually not. Most of the work is on code, configuration and servers. How I handle access

Tell me what you've inherited.

Send me your results, even if most are "don't know". I'll tell you what matters most, and what I'd do first.

Book a free conversation Legacy System Assessment, from £2,500