I Found a Property Management System in Kenya Exposing Tenant Data Without Authentication

It Started with a Simple Favour

I was catching up with a friend recently. He mentioned he was having trouble downloading his rent statement from his property management portal. Something wasn't loading right.

"Can I have a look?" I asked. He sent me a link.

I clicked it. No login screen. No authentication prompt. No "enter your password" page.

Just his full name, phone number, unit number, and every rent payment he's made since January 2023. Six pages of financial history. Open to anyone with the URL.

No session token. No cookie validation. Nothing standing between that data and the open internet.

What Debug Mode on Production Means

I grabbed the base URL myself to check what else was exposed. What came back was worse.

The system was running in debug mode on a production server. If you're not a developer, here's what that means in plain English:

Debug mode is something developers turn on during development to help them find bugs. It shows detailed error messages, file paths, code line numbers, and server configuration. It should never be left on when real users are accessing the system.

What was exposed:

• Full server file paths — showing exactly where the application code lives on the server
• Framework version and dependencies — telling attackers exactly what software is running
• Internal controller logic with line numbers — a map of how the application works
• Server environment data — configuration details that should be secret
• Cookie and session information — data that could be used to impersonate users

This is the equivalent of a bank leaving its vault blueprints, alarm codes, and guard schedules pinned to the front door.

Known CVEs: Publicly Documented Exploits

Once I could see the framework version, I checked it against the CVE database (Common Vulnerabilities and Exposures). This is a public registry where security researchers document known flaws in software.

The version running on this system had multiple known vulnerabilities. Not theoretical risks. Documented exploits with step-by-step instructions available online.

An attacker doesn't need to be creative or skilled. They just need to:

1. Visit the error page (publicly accessible)
2. Read the framework version
3. Search the CVE database for that version
4. Follow the published exploit guide

This is not hacking in the movie sense. This is reading publicly available documentation and following instructions. A university student could do it in an afternoon.

The M-Pesa Daraja Risk

Here's where it gets genuinely dangerous.

This system collects rent via M-Pesa Paybill. That means somewhere in the code, there's a Daraja API integration. Consumer keys, consumer secrets, callback URLs, and transaction processing logic.

With the level of exposure I was seeing — debug mode, no access control, outdated dependencies — an attacker with patience could potentially:

• Access API credentials — consumer key and secret used to authenticate with Safaricom
• Intercept callback URLs — redirect payment confirmations to their own server
• Manipulate transaction records — mark payments as received when they weren't, or redirect funds
• Harvest phone numbers — M-Pesa is tied to phone numbers, which are tied to money

The M-Pesa Daraja API itself is secure. Safaricom built it well. But if the software integrating with it is this exposed, the security of the API becomes irrelevant. It's like having an armoured truck deliver cash to a building with no doors.

Why I Chose Ethics Over Opportunity

I'm going to be honest. Looking at that system, I could see multiple ways to exploit it. The authentication gap alone meant tenant records were accessible. The debug mode exposure meant the server architecture was readable. The outdated dependencies meant known exploits were applicable.

I'm not going to pretend the thought didn't cross my mind. The system was essentially open.

But that's not who I am. I closed the tabs.

Instead, I wrote an email to the company explaining exactly what I found and how to fix it. I gave them specific steps:

• Disable debug mode immediately
• Add authentication to all tenant-facing URLs
• Update the framework to patch known CVEs
• Audit their Daraja API credential storage
• Implement role-based access control

I hope they fix it.

If they don't, my next email goes to the Office of the Data Protection Commissioner (ODPC). Because this isn't just bad engineering — it's a violation of the Kenya Data Protection Act, 2019.

What the Law Says: KDPA 2019

The Kenya Data Protection Act (2019) requires anyone who collects personal data to:

• Implement appropriate security measures to protect personal data (Section 41)
• Notify the Commissioner within 72 hours of becoming aware of a breach (Section 43)
• Ensure data is not accessible to unauthorized persons (Section 42)

A system that exposes tenant names, phone numbers, and payment history without any authentication is in clear violation. The ODPC has the power to issue enforcement notices and fines up to KES 5 million or 1% of annual turnover.

If you're a landlord using software that handles tenant data, you're the data controller under the law. Your provider's negligence is your liability.

How to Audit Your Current Property Management Software

Whether you built your system, bought it, or use a SaaS platform, ask these questions:

1. Authentication

• Can anyone access tenant data without logging in?
• Are tenant statement URLs guessable or sequential?
• Is there multi-factor authentication available?

2. Error Handling

• What happens when you visit a wrong URL on the system?
• Does the error page show technical details, file paths, or code?
• If it shows a "pretty" error page, you're probably fine. If it shows code — red flag.

3. Software Updates

• When was the last security update?
• Is the system actively maintained?
• Ask your provider: "What framework version are you running?"

4. Access Control

• Can your caretaker see financial data they shouldn't?
• Can a tenant see another tenant's information?
• Is there an audit log showing who accessed what?

5. Payment Security

• How are M-Pesa API credentials stored?
• Are callback URLs validated?
• Is payment data encrypted at rest?

How HomeManager Handles Security

When I built HomeManager, security wasn't an afterthought or a feature to add later. It was a design principle from day one. Because I've seen what happens when it's not.

Security Measure	What It Means
Zero access without authentication	Every URL, every endpoint, every piece of data requires a valid login session. No exceptions.
AES-256 encryption at rest	All data stored in the database is encrypted. Even if someone got the hard drive, they couldn't read it.
TLS 1.3 in transit	All data moving between your browser and our servers is encrypted with the latest transport protocol.
Role-based access control (25 permissions)	Owners, managers, accountants, caretakers, and maintenance staff each see only what they need.
Full audit trail	Every action is logged — who did what, when, from which IP address. Immutable record.
Continuous dependency patching	No known CVEs in our stack. Dependencies monitored and updated regularly.
M-Pesa integration secured end-to-end	API credentials encrypted, callback URLs validated, transaction data never exposed in logs.
AWS infrastructure	Hosted on Amazon Web Services with automated backups, auto-scaling, and 99.9% uptime.
KDPA 2019 compliant	Built in compliance with Kenya's Data Protection Act from the ground up.

The Bottom Line

Your tenants trust you with their personal data — names, phone numbers, ID numbers, payment history, lease details. That trust has a legal name now: the Kenya Data Protection Act.

If the software handling that data can't answer basic security questions, you don't have a tech problem. You have a liability problem.

Ask your current provider: "What happens when someone types in the wrong URL?"

If you don't like the answer — or if they can't give you one — it might be time to switch to something built with security as a foundation, not a feature.