API security in modern banking: common vulnerabilities and fixes

Modern banking systems are API-first. The mobile app, the web portal, third-party fintech integrations, the payment processor connection and the agent network interface all communicate through APIs. That makes the API layer one of the most exposed attack surfaces in a bank, and one of the most often under-tested.

This article covers the API vulnerabilities that come up most often in East African banking environments, how attackers exploit them, and what a proper API security assessment looks like. Our framework is the OWASP API Security Top 10, the standard reference for API security risks.

Why banking APIs are high-risk

APIs in banking environments carry exceptional risk because:

• They execute high-value operations: fund transfers, account changes, loan disbursements
• They aggregate sensitive data: full account details, transaction history, customer personal data
• They are reachable from the internet through mobile apps and partner integrations
• They are often built and deployed faster than they are secured, so new endpoints ship before anyone reviews their authorisation logic
• A single flaw affects every client at once: a weakness in the mobile app API is also a weakness in the web portal and in any third-party integration that calls the same endpoint

The OWASP API Security Top 10

The OWASP API Security Top 10 (2023) lists the most serious API security risks. The eight below are the ones most relevant to banking, and the ones that come up most often in banking API assessments.

API1: Broken Object Level Authorization (BOLA)

BOLA is the most common critical finding in banking APIs. The API lets a user reach objects they do not own, such as accounts or transactions, by changing an identifier in the request.

GET /api/v1/accounts/123456/transactions
Authorization: Bearer <user_A_token>

> Returns user A's transactions (correct)

GET /api/v1/accounts/123457/transactions
Authorization: Bearer <user_A_token>

> Returns user B's transactions (BOLA vulnerability)

In a bank, BOLA can expose the balances, full transaction histories, beneficiary lists and personal information of every customer. It is one of the most frequent findings in banking APIs that have never been tested.

API2: Broken Authentication

This covers weak session token generation, missing token expiry, insecure token storage and authentication flows that can be bypassed. In a banking app, broken authentication can lead to full account takeover without the attacker ever knowing the customer's password.

API3: Broken Object Property Level Authorization

The API returns more properties than it should. A customer profile endpoint, for example, returns admin flags, internal credit scores or references to other customers' linked accounts, none of which the requesting user has any business seeing.

API4: Unrestricted Resource Consumption

Missing rate limits on API endpoints allow automated attacks. In banking, that means:

• PIN brute-forcing (a 4-digit PIN has only 10,000 combinations)
• Account enumeration by phone number
• OTP brute-forcing
• Fee probing at scale (working out which transactions attract fees)

API5: Broken Function Level Authorization (BFLA)

Ordinary user accounts can call admin or privileged functions simply by knowing the endpoint URL. In previous engagements, our lead tester has found banking APIs where a customer could call endpoints built for bank staff: resetting other customers' PINs, raising transaction limits or approving pending transactions.

API6: Unrestricted Access to Sensitive Business Flows

Business flows such as loan applications, fund transfers or account opening can be automated at scale, bypassing the friction they were designed with. This enables automated loan farming, mass account opening for fraud networks, and circumvention of cooling-off periods meant to prevent fraud.

API7: Server Side Request Forgery (SSRF)

Banking APIs that fetch data from internal services or third-party integrations can be abused to reach internal resources. The attacker supplies a crafted URL, the server-side code fetches it, and the request lands on internal microservices, cloud metadata endpoints or private network resources that should never be reachable from outside.

API8: Security Misconfiguration

This covers default configurations, unnecessary HTTP methods left enabled, verbose error messages that reveal internal stack traces, missing security headers, and cross-origin resource sharing (CORS) policies that let any origin call the API. These issues are common in banking APIs and hand an attacker a great deal of reconnaissance.

Real vulnerabilities from banking API assessments

These examples come from our lead tester's earlier banking API assessments. Details have been anonymised.

Account takeover via PIN reset BOLA

The PIN reset flow accepted a phone number and a new PIN. The API did not check that the authenticated session matched the phone number being reset, so any logged-in user could reset any customer's PIN by supplying a different number.

Transaction replay enabling double-credits

Completed transactions could be replayed by resending the identical POST request. The API had no idempotency keys, so each replay was processed as a new transaction and the credit was multiplied.

IDOR on beneficiary management

The endpoint DELETE /api/beneficiaries/{id} deleted a beneficiary by ID without checking ownership, a classic insecure direct object reference (IDOR). Iterating through IDs allowed deletion of any customer's saved beneficiaries, a significant denial of service against other customers' payment flows.

Internal admin endpoints exposed

An endpoint documented only in internal API specifications (/api/admin/adjustBalance) was reachable by authenticated ordinary users and accepted the same JSON Web Tokens (JWTs) issued to customers. It allowed arbitrary balance adjustments.

Authentication and authorisation flaws

Authorisation and authentication are separate problems. Authentication asks "who are you?"; authorisation asks "what are you allowed to do?" Banking APIs often get authentication right (you must be logged in) and authorisation wrong (once logged in, you can do things you should not be able to).

The patterns we look for:

• Horizontal privilege escalation: user A reaching user B's data at the same privilege level
• Vertical privilege escalation: an ordinary user reaching admin functions
• Missing authorisation checks on state-changing operations (PATCH, PUT, DELETE)
• JWT algorithm attacks, such as the alg: none bypass
• Token scope that is not enforced at the endpoint

How we conduct API security testing

Our API security assessments follow the same seven steps:

1. API discovery and mapping: enumerate every endpoint, parameter and authentication flow, working from the documentation you provide and from active discovery.
2. Authentication testing: test token generation, expiry and rotation, and every authentication flow, including OTP, PIN and biometric.
3. Authorisation testing: for every endpoint, attempt access from accounts at different privilege levels, covering both horizontal (BOLA) and vertical (BFLA) authorisation.
4. Business logic testing: map transaction flows and test for bypass conditions, race conditions and replay.
5. Input validation: test for injection, mass assignment and parameter pollution.
6. Rate limiting and enumeration: test every sensitive endpoint for missing rate limits.
7. Security headers and configuration: review CORS, the content security policy and the TLS configuration.

Remediating API vulnerabilities

The remediations that make the biggest difference for banking APIs:

• Enforce object-level authorisation on every endpoint: never trust a user-supplied identifier without checking ownership against the authenticated session
• Rate-limit every authentication and sensitive endpoint: use a dedicated rate-limiting layer rather than application-level logic
• Use idempotency keys for state-changing operations: they stop transaction replay
• Restrict HTTP methods: if an endpoint only supports GET, disable POST, PUT and DELETE
• Minimise data exposure: return only the fields the client needs
• Use an API gateway: centralise authentication, rate limiting and logging in one place

For more on where API security fits in your wider security programme, see our guides on mobile banking security assessment and mobile money security testing. For scope, methodology and deliverables, see our API penetration testing service page and our broader penetration testing services.

How we can help

IMIZI Cyber provides manual penetration testing for banks, fintechs, telecoms, government and healthcare institutions across Africa, including the banking and fintech APIs behind their channels. Our engagements follow recognised offensive-security methodology and end in evidence-led reporting that a board and a regulator can both act on. Our testing is led by an OSCP-credentialled practitioner whose engagement history includes a Tier-1 Nordic bank red team and a pan-African banking group. The most serious findings in a bank usually sit in the API layer, so API testing is at the centre of every banking assessment we scope. If your APIs have never been tested for BOLA, transaction replay and the rest of the OWASP API Security Top 10, see our API penetration testing service page or contact us to scope an assessment.