Cybersecurity Basics Every New Kenyan Developer Should Know

Imagine you build a chama app. Members log in, record contributions, and check balances. One member uses the same password for your app and their M-Pesa account. You stored passwords in plain text. Someone accesses your database. Now they have a password that might unlock an M-Pesa account.

This is not a hypothetical. It happens. And when it happens, the developer is responsible.

Security is not a feature you add later. It is a practice you follow from the first line of code. The basics are not hard. They are habits. Learn them once and they become automatic.

When a user creates an account, you receive their password. You need to store it so you can verify it when they log in. But you must never store the actual password.

Instead, you hash it. Hashing runs the password through a one-way mathematical function that produces a fixed-length string. "mypassword123" becomes something like "$2b$10$xJ3kE...". The important property: you cannot reverse the hash to get the original password. Even if someone steals your database, they get hashes, not passwords.

When the user logs in, you hash the password they enter and compare it to the stored hash. If they match, the password is correct. You never see or store the actual password after initial hashing.

Use bcrypt or argon2. Both are available as npm packages for Node.js and pip packages for Python. They are industry standard. Do not use MD5 or SHA-256 for passwords. They are fast, which is bad for password hashing because attackers can try billions of guesses per second.

HTTP sends data in plain text. Anyone on the same network (a Wi-Fi hotspot at Java House, a shared network at a co-working space) can see everything: login credentials, personal data, payment information.

HTTPS encrypts the connection between the browser and your server. Even if someone intercepts the traffic, they see scrambled data. It is the difference between passing a note in plain sight and sealing it in an envelope.

Every modern hosting provider (Vercel, Netlify, Railway) gives you HTTPS for free. There is no excuse for running an app over plain HTTP in 2026. If you use a custom domain, set up SSL certificates through Let's Encrypt (free) or your hosting provider's built-in SSL.

SQL injection. If your app takes user input and inserts it directly into a database query, an attacker can type SQL commands instead of normal input and manipulate your database. Delete records. Dump your user table. Change account balances. This is one of the oldest and most common web attacks, and it is completely preventable.

The fix: never build SQL queries by concatenating strings with user input. Use parameterised queries or an ORM (like Prisma, Sequelize, or SQLAlchemy) that handles escaping for you.

Cross-site scripting (XSS). If your app displays user input on a page without escaping it, an attacker can inject JavaScript that runs in other users' browsers. Steal cookies. Redirect to phishing pages. Modern frameworks like React escape output by default, but if you use dangerouslySetInnerHTML or build templates manually, you are exposed.

The fix: escape all user input before rendering it in HTML. Use your framework's built-in protections. Never trust user input.

General principle. Treat every piece of data from the user as potentially malicious. Validate that it matches expected formats (is this actually an email? is this a number within range?). Sanitise it before storing or displaying.

Your Node.js app might use 200 npm packages. Each package is code written by someone else. If one of those packages has a security vulnerability, your app has a security vulnerability.

Run npm audit regularly. It tells you which packages have known vulnerabilities and suggests updates. Run npm update to apply safe updates. For major version changes, test before upgrading.

GitHub's Dependabot does this automatically. Enable it on your repositories. It creates pull requests when it finds vulnerable dependencies. Review and merge them.

This is not busywork. Some of the biggest security breaches in history happened because a company did not update a library with a known vulnerability for months. The fix was available. They just did not apply it.

Your database password, your M-Pesa API consumer key, your JWT secret, your email API key. These are secrets. They live in environment variables, not in your code.

Create a .env file for local development. Add .env to your .gitignore file so Git never tracks it. On your hosting provider, set environment variables through the dashboard.

If you accidentally commit a secret to GitHub, changing the .env file is not enough. The secret is in your Git history. Anyone who clones the repository can see it. You need to rotate the key (generate a new one) immediately and use a tool like git filter-branch or BFG Repo-Cleaner to remove it from history.

Bots scan public GitHub repositories constantly, looking for exposed API keys. If you commit an AWS key, expect unauthorised charges on your account within hours. This is not a theoretical risk. It happens every day.

At McTaba, security practices are woven into every project, not taught as a separate module. You hash passwords from your first app with user accounts. You use HTTPS from your first deployment. You learn to validate input, manage environment variables, and handle M-Pesa credentials securely.

When you build 8 production-grade apps, security becomes a habit, not a checklist. That is the goal. Secure code should feel as natural as writing a function.