Your data is not ours to mishandle.
That sentence sits at the top of every internal conversation we have before writing a single line of code for a new application. Not as a slogan. As a constraint — the kind that shapes decisions before the architecture is drawn, before the database schema is designed, before the first API endpoint is defined.
Every system we build — whether a mobile app running on an Android phone in Kampala or a web platform accessed from a browser in Nairobi — is designed with security as a foundational requirement. Not a feature to add later. Not a checklist item before go-live. A structural property of the system itself.
This article explains, in plain terms, the specific measures we apply across all our applications.
Why Security Cannot Be an Afterthought
Many software teams treat security as something to bolt on after features are built. This is a serious mistake — and an expensive one to undo.
Vulnerabilities introduced at the architecture stage are extraordinarily difficult to fix once a system is in production. A missing authentication check on an API endpoint. A database query that concatenates user-supplied strings. A session token that never expires. Each takes 30 minutes to introduce and months to find, fix, and recover from.
We take the opposite approach. Before a line of code is written, our team establishes the security architecture: how data will be stored, how it will travel, who will have access, and what happens when something goes wrong. Our products — Maduuka, Aqar, our Pharmacy and Restaurant Management systems, Longhorn ERP — are all built on this foundation.
Encrypted Data in Transit
All data moving between our applications and their servers travels over HTTPS with TLS 1.2 or higher. If someone intercepts the network traffic — through a public Wi-Fi access point, for example — they see only encrypted, unreadable bytes.
We enforce this without exception. HTTP connections redirect to HTTPS automatically. For our Android applications, we apply certificate pinning on high-sensitivity endpoints. The app will only communicate with servers presenting the correct, verified certificate — not any certificate that happens to be valid.
Encrypted Data at Rest
Sensitive information stored on device is held in encrypted storage. On Android, we use EncryptedSharedPreferences for credentials and session tokens. For databases containing particularly sensitive records, we apply Room encryption via SQLCipher.
On the server side, sensitive fields — national identification numbers, financial records, health data — are encrypted at the column level, separate from standard application-level access controls. If someone obtained a raw database dump, they would not be able to read those fields. Encryption keys are managed through secure key stores and are never embedded in source code.
Authentication and Session Management
We implement authentication carefully, with no shortcuts.
- Passwords are never stored in plain text. We use bcrypt with a work factor calibrated to be computationally expensive for attackers whilst remaining fast enough for legitimate users.
- Sessions are issued as cryptographically signed tokens with short expiry windows. Idle sessions are invalidated automatically.
- Multi-factor authentication is available and recommended for all administrative accounts — particularly for users with financial or inventory access in Maduuka and Longhorn ERP.
- Role-based access control (RBAC) ensures every user sees only what their role permits. A cashier cannot access payroll. A branch manager cannot modify system-wide settings. A user cannot escalate their own permissions.
Protection Against Common Web Vulnerabilities
Our PHP and JavaScript code is written with the OWASP Top 10 in mind at every step.
SQL Injection
Prevented through prepared statements and parameterised queries throughout. We do not construct SQL by concatenating user-supplied strings — ever.
Cross-Site Scripting (XSS)
Blocked by escaping all output rendered in the browser. User input is validated at the server boundary before processing and escaped before display.
Cross-Site Request Forgery (CSRF)
Applied to all state-changing requests through synchronised token patterns.
File Uploads
Validated for MIME type, file size, and content — not just extension. Uploaded files are stored outside the web root and served through controlled handlers. A malicious upload cannot execute directly through the web server.
Secure API Design
Our REST APIs are designed on the principle of least privilege: every endpoint exposes only what is necessary and nothing more.
API keys and JWT tokens carry expiry claims and scope restrictions. A token issued for the mobile app cannot be used to call administrative API endpoints. All API requests from our mobile applications are authenticated — there are no public endpoints that return sensitive records.
Rate limiting is applied to sensitive endpoints — authentication, password reset, and data export — to prevent brute force and enumeration attacks. We log all API activity for audit purposes: who accessed what and when, without logging the sensitive data itself.
Multi-Tenant Data Isolation
Several of our platforms — Maduuka, Aqar, our Pharmacy Management system — serve multiple client organisations from a shared infrastructure. In these environments, strict tenant isolation is non-negotiable.
Every database query is scoped to the authenticated tenant's identifier. It is architecturally impossible for one tenant's query to return another tenant's records — not merely because of application logic checks, but because the query construction physically cannot cross tenant boundaries. The tenant identifier is not a filter applied after the fact. It is part of the query itself.
Tenant data isolation is verified during code review and tested explicitly before any multi-tenant feature is released.
Dependency and Supply Chain Security
Third-party libraries introduce risk when not managed carefully. We maintain an updated inventory of all dependencies across our projects and monitor for published vulnerabilities. Libraries that are no longer maintained or carry known unpatched vulnerabilities are replaced.
Our servers run minimal installations — only the packages required for the application are present. Unused services, ports, and accounts are removed. A server that runs only what it needs has a dramatically smaller attack surface than one with a full stack of optional services left at default settings.
Security in the Development Process
Security is not reviewed only at the end of a project. It is part of every stage.
Code reviews include a security checklist covering input validation, output encoding, authentication flows, and data handling. Our team follows documented secure coding standards for PHP, Android/Kotlin, and JavaScript.
New features that handle personal data are subject to a privacy impact review before implementation begins. If a new feature on Aqar will store tenant contact records or financial history, that review happens before the feature is coded — not after. We conduct periodic security audits of our own platforms using structured checklists covering configuration, authentication, authorisation, and injection vulnerabilities.
Incident Response Readiness
No system is entirely immune to incidents. What matters is how quickly and effectively an incident is contained and resolved.
We maintain documented incident response procedures for our hosted platforms, covering:
- → Detection — through structured application and server logging that surfaces anomalous patterns
- → Containment — specific steps for credential compromise, unauthorised access, and data exposure scenarios
- → Communication — protocols for notifying affected clients promptly
- → Post-incident review — to close the vulnerability and prevent recurrence
Our clients are not left to discover a problem on their own.
9 Security Measures Applied to Every Build
What This Means for You
When you commission a system from us, you are receiving software built on security principles — not software that happens to have security features added later.
We document the security measures applied to each system we deliver. You will know precisely what protections are in place. You can answer questions from your own clients, auditors, and regulators with confidence because you have the documentation to back it up.
Security is not a competitive differentiator for us. It is a basic professional standard. Every organisation that works with our software — from a pharmacy system in Mbarara to a property agency in Nairobi — deserves software that handles their data with care.
Published by the Chwezi Core Systems development team. Last reviewed March 2026.
Chwezi Core Systems
Technology, Business & Security Consultants — Kampala, Uganda
We design, build, and support enterprise software, mobile applications, and security infrastructure for organisations across East Africa. Our products include Maduuka (POS and bookkeeping), Aqar (property management), and Longhorn ERP.