A01
Broken access control
The most common issue we encounter: a cashier role that can open the refunds screen, an API endpoint that trusts a user ID from the request instead of the session, a branch manager who can see another branch's payroll.
What it looks like
A user simply changes a value in the request — or in the URL — and is shown data or an action that should never have been available to their role.
Check first
Map every role to every screen and endpoint, and test what happens when a low-privilege user calls a high-privilege function directly.
Authorization must be decided server-side
- Cashier session requests a refund
- Server checks the role against refund policy
- Decision: permitted or denied
- Denied request never reaches the refund function
A02
Cryptographic failures
Customer PINs, M-Pesa credentials or database backups stored or transmitted without proper protection.
What it looks like
An integration key committed to a repository, a database backup left in a reachable folder, or a service that still accepts plain HTTP.
Check first
Confirm sensitive data is encrypted in transit (TLS) and at rest, and that no secrets live in source code, logs or front-end bundles.
A03
Injection
Untrusted input — a product name, a phone number, a callback payload — reaching a database query, a report generator or a system command.
What it looks like
A search or report field concatenated straight into SQL, or a filename handed to a shell command without validation.
Check first
Parameterized queries everywhere, and strict validation on anything arriving from payment callbacks.
The safe path
- Untrusted input
- Validation at the boundary
- Parameterized query
- Database
A04
Insecure design
Security missing from the requirements themselves: no threat model for the payment flow, no abuse cases for discount or refund logic.
What it looks like
A feature that works exactly as specified, where the specification never asked what an attacker would try.
Check first
Before code is written, ask how each money-moving feature could be misused — and write the answer into the acceptance criteria.
A05
Security misconfiguration
Debug endpoints left enabled, default admin passwords on routers and servers, verbose error pages leaking stack traces.
What it looks like
A staging setting carried into production, or a framework error page that returns internal paths to the browser.
Check first
A hardening checklist applied identically to staging and production, with defaults changed everywhere.
A06
Vulnerable and outdated components
The JavaScript libraries, POS plugins and server packages a business system accumulates over the years.
What it looks like
A dependency added years ago, still shipped to the browser, carrying a publicly disclosed flaw that was never tracked.
Check first
An inventory of third-party components with a routine for reviewing disclosed vulnerabilities and updating on a schedule.
A07
Identification and authentication failures
Weak password policies, session tokens that never expire, missing limits on login attempts.
What it looks like
Unlimited attempts against a staff or admin login, and a session that stays valid long after the user should have signed out.
Check first
Lockout and rate-limiting on authentication endpoints, sensible session lifetimes, and multi-factor authentication on administrative accounts.
A08
Software and data integrity failures
Updates applied without verification, or payment status accepted from an unverified callback.
What it looks like
An order marked paid because a request said so, rather than because the payment provider's own confirmation was verified.
Check first
Verify the integrity of updates and third-party data before acting on it — especially payment confirmations.
Treating a payment callback as unverified input
- Payment callback arrives
- Verify source and signature
- Validate the payload against the expected schema
- Check the transaction state we recorded
- Reconcile, then mark the order paid
- A client-side "paid" flag alone is never proof
A09
Security logging and monitoring failures
A breach discovered months later because nobody logged administrative actions or reviewed them.
What it looks like
Logs that record successful logins but not role changes, refunds or configuration edits — the actions worth watching.
Check first
Audit trails on money movement, access changes and configuration edits — plus someone actually reviewing them.
A10
Server-side request forgery (SSRF)
A feature that fetches a remote URL — an integration webhook, an image import — tricked into reaching internal services.
What it looks like
A webhook URL field that accepts any destination, so the server can be pointed at internal metadata or admin services.
Check first
Allow-lists for outbound destinations and no direct passthrough of user-supplied URLs to server-side requests.