The 2026 API attack surface
Every Malaysian bank, every licensed digital bank, every e-money issuer, every PayNet participant, every BNPL platform, every government digital service — they all run on APIs. The web and mobile UIs are thin shells over a sprawling REST and GraphQL backend that handles the actual money movement, identity verification and customer data. APIs have quietly become the dominant attack surface in financial services, and the OWASP API Security Top 10 (2023 edition) is the canonical reference for how that surface gets exploited.
The 2023 edition reorganised the 2019 list materially: BOLA (Broken Object Level Authorization) remained at #1, BOPLA (Broken Object Property Level Authorization) was introduced consolidating mass-assignment and excessive-data-exposure, and unrestricted resource consumption picked up the throttling and rate-limiting concerns. We work through all ten in order below.
API1:2023 — Broken Object Level Authorization (BOLA)
The single most reliable API vulnerability in our Malaysian fintech caseload. The pattern: an API endpoint accepts an object identifier in the URL or body (account ID, transaction ID, user ID, document ID) and serves the object without verifying that the authenticated user is authorised to access that specific object. Switch the integer in the URL from your account ID to your neighbour's account ID and you read their balance.
We see BOLA in two flavours. First, classic IDOR — sequential integer IDs allow trivial enumeration. Second, even with UUIDs, BOLA exists when the authorisation check is missing entirely; an attacker who learns one valid UUID (from a referrer leak, shared link, support ticket screenshot) accesses that object. Fix: every endpoint that accepts an object identifier must enforce a check that the authenticated principal owns or has been granted access to that object. Tested by routine pentest with two accounts and the simple substitution test.
API2:2023 — Broken Authentication
The classic and still-prevalent set: missing rate-limiting on login endpoints (credential stuffing trivial), JWT verification flaws (none algorithm, weak secret, kid header injection), refresh-token reuse, password-reset flows that leak tokens via referer or accept any email and respond identically (good — prevents user enumeration) but fail to invalidate the prior reset link. In Malaysian retail banking we see this most often in mobile-banking JWT implementations where the signing key is hardcoded in the mobile app or where the algorithm is not pinned server-side.
API3:2023 — Broken Object Property Level Authorization (BOPLA)
The new (2023) consolidated category covering mass assignment and excessive data exposure. Mass assignment: PATCH /api/users/me accepts arbitrary JSON properties and the server binds them all to the user model — including the ‘role’ field, which the API was never supposed to let the user modify. Excessive exposure: the GET /api/transactions response includes internal fields (compliance flags, fraud-engine scores, KYC-tier numbers) that the UI never displays but a curl client receives. Fix: explicit field-level read and write allow-lists per endpoint, never relying on the UI to filter.
API4:2023 — Unrestricted Resource Consumption
The denial-of-service category, expanded in 2023 to include resource-amplification (an API call that triggers expensive backend work — a search across all accounts, an export of the full transaction history, a regex evaluation against attacker-controlled input) and the cost-amplification specific to cloud APIs (calls that trigger SMS sends, paid third-party API calls, large S3 reads). For Malaysian fintechs this also includes OTP-flood attacks against mobile-number verification endpoints that bill SMS at sender rate.
API5:2023 — Broken Function Level Authorization
Function-level authorisation = the user can call administrative endpoints they should not. Classic case: /api/users/{id} supports GET, PATCH, DELETE — and the developer remembered to enforce auth on GET (BOLA) but forgot DELETE accepts unauthenticated traffic from any administrative subnet that turns out to also include the customer-facing edge. The 2023 evolution emphasises that role-based access control (RBAC) must be enforced per-endpoint, not just for ‘admin endpoints’ broadly.
API6:2023 — Unrestricted Access to Sensitive Business Flows
New in 2023 and meaningful in Malaysian e-commerce and BNPL: a business flow the API exposes (sign-up, promotional voucher claim, ‘refer-a-friend’ bonus, BNPL credit-limit increase) does not enforce limits beyond the per-request technical authorisation. An attacker scripts the flow at scale — claim 10,000 voucher codes, sign up 10,000 fake accounts to trigger sign-up bonuses, run 100 BNPL applications across stolen identities. The fix is rate-limiting, anti-automation (CAPTCHA, device fingerprinting), business-flow-aware fraud rules, not just token-level auth.
API7:2023 — Server Side Request Forgery (SSRF)
The cloud-era SSRF: an API accepts a user-supplied URL (webhook configuration, profile-image-from-URL, document-import-from-URL, link-preview generation) and the backend dutifully fetches that URL — including, dangerously, internal URLs (169.254.169.254 metadata endpoints, internal Kubernetes service IPs, internal databases). On AWS, IMDSv1 SSRF is a one-shot path to instance credentials and from there to whatever IAM role the workload holds. Fix: deny-list internal IP ranges, enforce IMDSv2 cluster-wide, validate URLs server-side, prefer signed-URL or upload patterns over URL-fetch patterns.
API8:2023 — Security Misconfiguration
The catch-all: open CORS that allows any origin, missing security headers, default error responses leaking stack traces and SQL queries, debug endpoints exposed in production, outdated framework versions with known CVEs, sample API documentation pages exposed at /swagger or /api-docs without auth. In Malaysian regulated entities we routinely find Spring Boot Actuator endpoints exposed to the internet — /env leaks every environment variable including database credentials, /heapdump downloads the full JVM heap.
API9:2023 — Improper Inventory Management
The shadow-API problem. The API-gateway team controls the documented API surface. Meanwhile the development team has spun up a v2 endpoint on a different subdomain to test mobile-app changes, an internal partner-API on a different port, a deprecated v1 endpoint that nobody decommissioned, a staging environment with production data exposed via a permissive firewall rule. None of these appear in the API gateway inventory; none receive the same security controls. Fix: API discovery scanning, gateway-enforced traffic, deprecation policy, single source of truth for API inventory.
API10:2023 — Unsafe Consumption of APIs
The weakest-third-party problem. Your API consumes a third-party API (KYC vendor, payment provider, fraud-screening service) and trusts the response without validation. The third party gets compromised; they return a malicious response; your application processes it as trusted input and is now compromised too. Fix: validate third-party responses against expected schemas, treat third-party APIs as untrusted boundaries, log and alert on response anomalies.
A real Malaysian fintech case (anonymised)
On a recent intelligence-led pentest of a Malaysian licensed digital bank (anonymised), the highest-impact finding chained API1 (BOLA on the loan-application endpoint), API3 (BOPLA exposing internal credit-decision metadata in the response), and API9 (a v1 endpoint on a development subdomain that authenticated against the same identity provider as production but applied weaker authorisation logic). The combination would have allowed an authenticated retail customer to read every active loan application across the customer base, with internal credit-decision metadata, in under an hour of automated enumeration. Findings remediated; verification re-test passed.
Tooling: Burp Pro, Postman, OWASP ZAP
Our API pentest engagements run a mixed toolchain. Burp Suite Professional remains the workhorse — Repeater for manual exploitation, Intruder for parameter fuzzing, the Logger++ extension for capturing the full session, the Autorize extension for two-account BOLA testing at scale. Postman is excellent for working with documented OpenAPI specs and building reusable request collections. OWASP ZAP fills the open-source slot — particularly its automated active scanner against well-defined endpoints. For GraphQL specifically, InQL and graphw00f. For mobile-app-driven APIs, Frida and Objection on the client side combined with Burp on the wire (see also our mobile banking pentest article).
Methodology-wise, OWASP API Security Project documentation (the Top 10 plus the test cases in the API Security Cheat Sheet) is the baseline. PCI DSS v4.0 requirement 6.4.x added explicit API-protection language relevant for Malaysian PCI-scope organisations.
BNM RMiT API guidance
BNM RMiT does not yet contain prescriptive API-specific paragraphs (the Open API specifications under the BNM Open API initiative are a separate workstream). Effective coverage falls under paragraph 10 (information assets and security controls), paragraph 10.49 (penetration testing), and paragraph 11 (cyber resilience). For licensed financial institutions, API pentesting is now a mandatory line-item in any annual pentest scope — examiners will ask, and a scope without explicit API coverage is not a credible scope. See our API penetration testing service and our intelligence-led penetration testing service for end-to-end coverage.
For execution: see our API penetration testing service, intelligence-led penetration testing, and our RMiT compliance practice.