The OWASP API Security Top 10 is not a checklist for the engineering team. It is a structured account of how financial APIs fail in production — through broken object-level authorisation, excessive data exposure, unrestricted resource consumption, and function-level access failures that no firewall rule catches because they exploit legitimate API behaviour. Most Saudi banks running open banking APIs have invested in perimeter WAF rules that catch SQL injection and XSS patterns from the web application era. Almost none have invested in API-specific controls that address the failure modes that actually affect REST and GraphQL services. The distinction matters because the OWASP API Top 10 risks are architectural, not syntactic: they cannot be caught by pattern matching on HTTP request bodies.
A web application firewall positioned in front of the API gateway provides genuine value against a specific subset of those risks: volumetric attacks, known exploit patterns, geographic anomalies, and credential stuffing at the authentication endpoint. It provides little or no protection against broken object-level authorisation (an authenticated user accessing another user’s accounts), excessive data exposure (an endpoint returning 200 fields when the consumer needs 5), or broken function-level authorisation (a TPP calling a payment initiation endpoint that should be restricted to bank-internal orchestrators). Those risks require API design changes, schema validation at the gateway, and authorisation policy enforcement at the application layer.
What SAMA’s cyber security framework demands
SAMA’s Cyber Security Framework classifies API security as a Tier 1 control domain. The examination question is not “do you have a WAF?” — it is “can you demonstrate that your open banking APIs enforce object-level authorisation for every resource, that your payment initiation endpoints are restricted to authorised callers, and that your API traffic is monitored for behavioural anomalies rather than just signature matches?” A WAF alone cannot answer those questions. A WAF combined with Kong’s OPA plugin for object-level policy, a schema validation stage that rejects responses exceeding declared field limits, and an anomaly detection layer that flags deviation from normal TPP call patterns — that answers the examination question completely.
The PDPL dimension is distinct. APIs that return account data must not expose more personal data than the active consent scope permits. This is not a WAF rule; it is an application-layer enforcement that must be implemented at the field selection level. But the WAF provides the audit trail: every API call logged with the caller identity, the endpoint, the response code, and the response size gives the platform the evidence base to detect over-exposure before PDPL does.
A WAF that protects your APIs from the 2015 threat model while leaving your 2026 OWASP API Top 10 exposure unaddressed is security theatre, not security architecture.
The two commitments leadership must make
The first commitment is to treat API security as a product requirement, not a deployment configuration. Broken object-level authorisation cannot be fixed by adding a WAF rule; it requires the API design to include a resource ownership check on every endpoint. Excessive data exposure cannot be fixed by a response filter at the WAF; it requires the API contract to specify the exact fields returned under each consent scope, enforced at the schema validation layer. These are decisions about how APIs are designed and reviewed, not decisions about what infrastructure sits in front of them. Every new API endpoint entering the bank’s API catalogue should pass an OWASP API Top 10 review before going live — with a named security architect accountable for sign-off.
The second commitment is to fund behavioural anomaly detection alongside signature-based WAF rules. The attack patterns that target modern bank APIs are not in signature databases: they are legitimate-looking API calls that systematically enumerate resources, extract data fields that should not be visible, or probe rate limits to find bypasses. Detecting those patterns requires a baseline of normal TPP behaviour per API endpoint, an alerting layer that flags deviations, and an on-call process that can investigate and block a TPP within minutes. Building that capability requires investment in API observability, machine learning models trained on legitimate traffic, and a security operations function that treats API anomalies with the same urgency as perimeter alerts.
For the engineering depth behind this decision — ModSecurity CRS tuning for API traffic, Kong OPA plugin configuration, OWASP API Top 10 mitigation patterns, schema validation at the gateway, and the production checklist — see the companion Lab article: API Security: API WAF and OWASP API Top 10.