83%
carry XSS exposure — no Content-Security-Policy, or one defeated by unsafe-inline.
The State of App Security · Africa
We mapped and passively scanned 618 public applications belonging to 347 African banks, fintechs, payment companies, crypto exchanges and insurers across 21 African countries. One browser-style request each. No logins, no probing, no institution named.
By the numbers
Finding 01 — The inversion
On the edge — a recognizable WAF or CDN out front — the fintechs win easily. On the application itself — the actual defenses in the app — it flips. The newest, fastest companies lean on a CDN and ship the app almost bare. The banks did the opposite.
Crypto — the most-attacked category on earth — is the only one that defends both layers: highest edge adoption, lowest exposure. Everyone else picked one, or neither.
Finding 02 — Susceptibility
Measured passively, from missing or defeated defenses — never by attacking. A quarter of the apps that send a Content-Security-Policy weaken it with unsafe-inline, which defeats its XSS protection, so a naive "has a CSP" check would score them safe. This one does not. Share of all 618 apps exposed to each attack:
Finding 03 — The estate everyone under-serves
A third of these institutions now publish a public developer API — 145 developer and API-doc surfaces in all. On the newest fintechs the API ships before the app does.
None of what this report measures — not a single header, not the CDN, not the certificate — touches the risk that has moved to the center of the industry. The attacks that break an API are broken object-level authorization, broken function-level authorization, and business-logic abuse: a request that is perfectly well formed and simply should not have been allowed. There is no header for that. There is no CDN rule for it. A signature-matching WAF cannot see it, because there is no signature for "you asked for an account that is not yours."
The uncomfortable part
Nothing here required special access. No exploit, no login, no permission. Just the response a server hands to any browser that asks. Every institution in this report was mapped that way — and so is yours. The only question the data leaves open is where yours lands on the spectrum.
What actually closes the gap
A CSP stops a class of injection. A CDN filters known-bad traffic. Neither knows that this user should not be able to read that account, or that a refund should never exceed the original charge. That judgment lives in your app's own logic — so the defense has to learn your app's normal behavior and block the deviation. That is positive security, and it is what Nemesis builds.
Learns each app and API's normal behavior and blocks the deviations — the IDOR, BOLA, broken auth and business-logic abuse a signature WAF and a header checklist never see.
Explore Omniguard → Positive securityWhy deny-by-default beats block-the-known-bad, in one line of code — observe first, fail-open, every block delivered with proof.
See how it works →Method & ethics
One browser-style GET plus a TLS handshake per asset. We read response headers, cookies, CORS, TLS state, and the page's own markup. No authentication, no path probing, no payloads, no exploitation.
Every URL passed liveness (with retries) and an identity check — including TLS-certificate confirmation — before scanning. The scanner is validated against known-good and known-weak controls.
"Weak to X" means the defense against X is missing or defeated, inferred from the public response. We never attacked anyone to find out.
No institution is identified as exposed, here or anywhere. A list of which bank has the weakest headers is the opposite of helpful, and building it is not the point.
Scope: public homepages, login landings, and developer docs of financial institutions, gathered from public sources. Figures reflect the latest validated snapshot and may move by a percentage point between runs as live infrastructure changes. Security teams: scan your own estate, or reach out for the methodology.