Web Security for Zambian Businesses: What Actually Gets Exploited

Security advice for small businesses usually arrives as a list of everything that could theoretically go wrong. That is not actionable, and it produces a predictable outcome: nothing is done, because there is no obvious place to start.

So this is narrower. These are the weaknesses that actually get exploited in small and mid-sized business systems, roughly in the order they are worth your attention.

1. Credentials, by a wide margin

Most compromises are not clever. Someone reuses a password, that password appears in a breach of an unrelated service, and it is tried against everything else. No exploit, no vulnerability, just a valid login.

What actually helps, in order:

• Multi-factor authentication on email first. Email is the master key: it resets every other password you own. If you do one thing from this article, do this one.
• MFA on anything financial or administrative. Banking, mobile money portals, the admin account of your own systems.
• A password manager. The reason people reuse passwords is that remembering unique ones is impossible. Solve the cause.
• Remove access when people leave. Keep a list of what each role can reach. Dormant accounts of departed staff are a recurring finding, and nobody discovers them until they are used.

Prefer an authenticator app over SMS where you have the choice. SIM swap fraud is not theoretical in this region, and SMS is the weakest of the second factors, though it is still enormously better than no second factor at all.

2. Unpatched dependencies

The application code most teams write is a small fraction of what actually runs. The rest is frameworks and libraries, and vulnerabilities in those are published, catalogued and trivially scannable by anyone looking for targets.

The exposure is not that a vulnerability exists. It is the gap between disclosure and your patching it, during which the problem is public knowledge.

Practically: run automated dependency scanning in your pipeline, patch anything with a known exploit promptly, and most usefully of all, carry fewer dependencies. Every library you do not install is one you never have to patch. This is a real argument for boring, small stacks that has nothing to do with elegance.

3. Backups nobody has restored

Ransomware turns a security incident into a business continuity event, and the only thing that reliably decides the outcome is whether you can restore.

The failure is almost never "we had no backups". It is one of:

• The backups were on a network share the ransomware also encrypted.
• They had been silently failing for months and nobody checked.
• They restore the database but not the configuration needed to make it useful.
• Nobody had ever tried, so the restore took four days of improvisation.

Keep one copy offline or otherwise immutable, and test a restore on a schedule. An untested backup is a belief, not a control. The test is also the only way to discover your real recovery time before you need it.

4. Everything in one account

A common pattern: one shared administrator login, used by four people, for everything. It cannot be revoked without disrupting everyone, and an audit log that says "admin" tells you nothing about who did what.

Individual accounts with roles are not bureaucracy. They are what makes both revocation and investigation possible.

5. Application-level mistakes

Lower down the list than people expect, because frameworks now prevent most of the classics, but only if you use them as intended.

• SQL injection is solved by parameterised queries. It reappears when someone concatenates a string for a dynamic search or an ORDER BY.
• Cross-site scripting is solved by contextual auto-escaping. It reappears via the escape hatch: innerHTML, dangerouslySetInnerHTML, |safe.
• Broken access control is the one frameworks do not solve. Checking that a user is logged in is not checking that this user may see that record. Changing an ID in a URL to reach someone else's data is among the most commonly found real flaws, and it is entirely application-specific logic.
• Secrets in the repository. API keys committed to git are found by automated scanners quickly. Treat any committed secret as compromised and rotate it. Deleting the commit does not help once it has been pushed.

Headers worth setting

Cheap, and they close whole categories of attack. This site sets:

• Content-Security-Policy, the single most valuable. A strict policy means an injected script has nowhere to load from, which downgrades many XSS findings from critical to inert. It also forces you to notice how much third-party code you are running.
• Strict-Transport-Security. HTTPS is not optional on any site handling a login.
• X-Content-Type-Options: nosniff and X-Frame-Options: DENY, covering content-type confusion and clickjacking, one line each.
• Referrer-Policy, which stops full URLs leaking to third parties.

You can check what your site currently sends with curl -I https://yourdomain. It takes a minute and the result is often instructive.

The regulatory dimension

Zambia's Data Protection Act No. 3 of 2021 places obligations on organisations handling personal data: lawful basis, safeguards, and breach handling. If you hold customer records, employee data or payment information, this applies to you regardless of size.

The practical implication is that a breach is no longer only a technical and reputational problem. Two things follow that are far easier to prepare in advance than during an incident: knowing what personal data you hold and where, and having a decided procedure for who is told and when if it is exposed.

We are software engineers rather than lawyers, and the specifics of compliance are worth a professional conversation. But most of the technical groundwork is the same work as the security controls above.

A realistic starting order

1. MFA on email, today.
2. Verify a backup restores. Actually run it.
3. Individual accounts; delete dormant ones.
4. Dependency scanning in the build.
5. Security headers, starting with CSP.
6. An access-control review of your own application. Try reaching another user's record by changing an ID.

The first three cost almost nothing and address the most common causes of real incidents. Perfect security is not the goal and is not available; not being the easiest target, and being able to recover when something does happen, is achievable.

If you would like a review of a system you already run, get in touch.