Securing a Self-Hosted Business App — The Short List, and What You Can Safely Ignore

Search for how to secure a self-hosted application and you will find a checklist with forty items on it, most of which assume you have a firewall you control, a SIEM, and somebody whose job this is.

You have a cPanel login and a business to run. This is the short list.

And because a list of things to do is only half of it, this guide also names what you can safely ignore at this scale. A checklist you abandon at item nine protects nothing.

The five that actually matter

1 — HTTPS, and force it (5 minutes)

Without it, every login and every record travels in plain text across whatever network your staff are on.

In cPanel, SSL/TLS Status issues a free certificate — most hosts auto-enable this now. Then find Force HTTPS Redirect under Domains and turn it on.

Turn it on before you enter real data, not after. A certificate that exists but is not enforced is a certificate that does nothing — the browser will happily use the plain-text version if something links to it.

2 — A password manager, and no shared logins (15 minutes, and this is the one)

The realistic way a small business system gets breached is not an exploit. It is a reused password. The admin password to your rota system is the same one somebody used on a forum that leaked in 2021, and the attack is somebody typing it in.

• A unique, generated password for the app's admin account.
• In a password manager, not a spreadsheet called passwords.xlsx.
• Individual accounts per person, never a shared admin login. Not for security theatre — because when somebody leaves, you need to remove one account rather than change one password and tell four people the new one.

If you do exactly one thing from this article, do this one. It costs nothing and it addresses the actual threat.

3 — Keep PHP current (10 minutes, twice a year)

In cPanel's MultiPHP Manager, keep your PHP on a version that still receives security support. Hosts often leave old accounts on old versions indefinitely — they will not move you, and they will not tell you.

Put a calendar reminder twice a year to look. That is the entire maintenance burden for most small PHP apps, and it is the one people skip because nothing visibly breaks when they do.

4 — Apply the app's updates (varies)

When the vendor ships an update, apply it. This is what you are buying when a product includes an update window — not new features, but the ability to close a hole somebody else found.

Before you update, take a database dump. (See the backup guide — an update is the most predictable moment you will need one.)

5 — Know what the app can reach (one thought, once)

Prefer software with a small surface. Several of the tools we sell make a point of this in their own FAQs — no payment processing, no file uploads, no external API calls, no member logins.

That is not modesty; it is architecture. A tool that stores no card data cannot leak card data. A tool with no public login page has no public login page to attack. When choosing between two products, "what does this one not do?" is a legitimate security question and almost nobody asks it.

What you can safely ignore at this scale

This section exists because generic checklists cause more harm through abandonment than through omission.

A Web Application Firewall. Useful at scale, meaningful ongoing tuning, and a common source of "why has the app stopped working." Your host may run one already; you do not need to buy one.

Intrusion detection, SIEM, log aggregation. These exist so somebody can watch them. If nobody is going to read the alerts, an alerting system is a subscription that makes you feel safer.

Penetration testing. Genuinely valuable and genuinely expensive. For a rota system on shared hosting, the money is better spent on the password manager and an off-site backup.

Hardening guides written for VPS or Kubernetes. SSH key policies, kernel parameters, container isolation, fail2ban tuning — on shared hosting you do not control any of it, and your host already does most of it. Skipping this is not negligence; it is correctly identifying whose job it is.

Two-factor authentication on every app. Genuinely valuable where it exists — but a small self-hosted PHP app may not offer it, and that is not by itself a reason to reject the app. Put 2FA on the things that gate everything else: your email, your password manager, your hosting account, and your domain registrar. Those four are the actual keys to the kingdom.

The four accounts that matter more than the app

This is the part most security advice buries, and it is the part that decides your outcome.

Your self-hosted app is protected by things that are not the app:

1. Your domain registrar — lose this and someone can point your domain anywhere.
2. Your hosting account — the app, the database and the backups all live inside it.
3. Your email — because it resets the other three.
4. Your password manager.

Put strong unique passwords and 2FA on those four today. A perfectly hardened application inside a hosting account secured by a reused password is not secure — it is convenient.

If something does go wrong

In order:

1. Change the passwords on the four accounts above, from a device you trust.
2. Take a backup of the current state before changing anything else — you may need to know what happened.
3. Restore from a backup you know predates the problem (which requires knowing when your backups are from — hence dated filenames).
4. Tell your host. They see this daily, they have logs you do not, and they are on your side.
5. If personal data may have been exposed, you may have a legal notification duty with a deadline measured in days. That is a question for someone qualified, immediately — not a thing to research over a weekend.

The short version

Five things: HTTPS forced · unique passwords in a manager, individual accounts · PHP kept current · vendor updates applied · prefer software with a small surface.

Four accounts matter more than the app: registrar, host, email, password manager. 2FA on all four.

And ignore, without guilt: WAFs, SIEM, pen tests, and hardening guides written for infrastructure you do not control.

Security advice that does not fit the situation gets abandoned, and an abandoned checklist protects nothing. This one fits on a page because it is meant to be finished.

---

Next steps

• Installing a PHP app on cPanel — the click path
• Your backup is not a backup until you have restored it
• Self-hosted software by category
• What this list looks like already done: every app in the catalog ships login rate-limiting, TOTP two-factor and one-click backups as standard — Invora is a representative example

This is general guidance for small PHP applications on shared hosting, not a substitute for professional advice about your specific obligations. If you handle health data, card data, or large volumes of personal data, your requirements are higher than this page and you should get help.