API Security Under DORA: Protecting Open Banking in the Age of Operational Resilience
The Open Banking Attack Surface
The Payment Services Directive 2 (PSD2) mandated that European banks open their payment and account data to licensed third-party providers through APIs. This was transformative for competition and innovation. It was also transformative for the attack surface.
A mid-sized European bank today exposes between 200 and 500 APIs externally — account information, payment initiation, card management, lending decisioning, KYC verification, and fraud scoring. Each API is a contractual obligation, a technical integration point, and a potential attack vector. Internally, the same bank operates thousands more APIs connecting microservices, core banking modules, data warehouses, and compliance systems.
DORA arrived into this reality. The regulation does not contain the word "API" — but APIs are the primary mechanism through which ICT systems communicate, third parties integrate, and critical functions operate. When DORA Art. 9 requires "the security of data transfers," it means API security. When Art. 28 requires management of ICT third-party risk, it means managing the third parties consuming and providing APIs.
Industry data from ENISA and financial sector ISACs confirms that API-specific attacks against European financial institutions have grown dramatically since PSD2's Strong Customer Authentication deadline. Credential stuffing, broken object-level authorization (BOLA), mass assignment, and injection attacks account for the majority of successful API compromises.
DORA Article Mapping to API Security
Art. 9: The Security Foundation
Art. 9's protection and prevention requirements translate directly to API security controls:
| Art. 9 Requirement | API Security Control | Implementation |
|---|---|---|
| Authentication and access control (9(4)(a)) | OAuth 2.0 / OpenID Connect, API key management, mTLS | Identity verification for every API call |
| Network security management (9(4)(b)) | API gateway, WAF, DDoS protection, rate limiting | Network-level API protection |
| Data protection (9(4)(c)) | Request/response encryption, data masking, field-level access | Payload security |
| Logging and monitoring (9(4)(d)) | API access logs, anomaly detection, usage analytics | Visibility and detection |
| Security of data transfers (9(4)(e)) | TLS 1.2+, certificate pinning, payload signing | Transport security |
Art. 28: Third-Party API Risk
Art. 28 requires that financial entities manage ICT third-party risk, including "contractual arrangements on the use of ICT services." Every API consumed from or exposed to a third party is an ICT service arrangement subject to Art. 28. The register of information must include API integrations — not just cloud hosting contracts.
This creates a classification challenge. A bank consuming market data through a vendor's REST API, exposing account data to a fintech through PSD2 APIs, and using a cloud provider's managed database service through their API — each is a distinct third-party ICT relationship requiring documented risk assessment, contractual provisions per Art. 30, and exit strategies per Art. 28(8).
Art. 11: Continuity and Recovery for APIs
Art. 11 requires business continuity policies that cover "arrangements to ensure the continuity of the financial entity's critical or important functions." APIs that serve critical functions must have:
- Defined RTOs and RPOs reflecting the criticality of the downstream consumers
- Failover mechanisms (multi-region deployment, circuit breakers, fallback endpoints)
- Degradation strategies (what partial functionality can be maintained when the full API is unavailable?)
The OWASP API Security Top 10 Through a DORA Lens
The OWASP API Security Top 10 (2023) maps to DORA requirements with surprising precision. Each vulnerability class represents a failure mode that, in a financial institution, could constitute a DORA-reportable incident under Art. 17-23.
| OWASP API Risk | DORA Article | Regulatory Consequence |
|---|---|---|
| API1: Broken Object Level Authorization | Art. 9(4)(a) — access control | Unauthorized data access → potential data breach incident |
| API2: Broken Authentication | Art. 9(4)(a) — authentication | Account takeover → critical incident |
| API3: Broken Object Property Level Authorization | Art. 9(4)(c) — data protection | Mass data exposure → regulatory notification |
| API4: Unrestricted Resource Consumption | Art. 7 — capacity and reliability | DoS / degraded service → availability incident |
| API5: Broken Function Level Authorization | Art. 9(4)(a) — access control | Privilege escalation → security breach |
| API6: Unrestricted Access to Sensitive Business Flows | Art. 9(2) — protection policies | Business logic abuse → fraud / financial loss |
| API7: Server Side Request Forgery | Art. 9(4)(b) — network security | Internal network exposure → lateral movement |
| API8: Security Misconfiguration | Art. 7 — reliable ICT systems | Exposed debug endpoints → information disclosure |
| API9: Improper Inventory Management | Art. 8 — asset identification | Shadow APIs → unmanaged attack surface |
| API10: Unsafe Consumption of APIs | Art. 28 — third-party risk | Vendor API compromise → supply chain attack |
OWASP API9 (Improper Inventory Management) and DORA Art. 8 (asset identification) deserve special attention. Shadow APIs — endpoints that exist in production but are not documented in the API inventory — represent unmanaged ICT assets. They violate Art. 8's identification requirements and create attack surface that cannot be protected because it is unknown.
API Security Architecture for DORA Compliance
Layer 1: Gateway and Edge Security
The API gateway is the enforcement point for DORA Art. 9 security policies. Every API request must pass through centralized security controls before reaching internal services.
Authentication: OAuth 2.0 with OpenID Connect for user-context APIs. Mutual TLS (mTLS) for service-to-service and critical third-party integrations. API keys for low-sensitivity informational endpoints — but never as the sole authentication mechanism for data-bearing APIs.
Rate limiting: Essential for Art. 7 reliability and capacity management. Rate limits must be calibrated per consumer, per endpoint, and per time window. A fintech partner authorized for 1,000 account inquiries per minute should not be able to execute 10,000 — whether by accident or by compromise.
Input validation: Every API request parameter must be validated against the expected schema before reaching business logic. Reject malformed requests at the edge, not in the database layer.
Layer 2: Authorization and Access Control
Authorization determines what a validated identity can access. For DORA compliance, this extends beyond simple role-based access control (RBAC) to include:
- Scope-based access: OAuth scopes that limit what data an API consumer can request (e.g., read-only account balance vs. full transaction history)
- Consent-driven access: PSD2 mandates explicit customer consent for account access. This consent is a DORA-relevant access control — it determines whether a data transfer is authorized.
- Contextual access: IP allowlists, geolocation restrictions, and time-of-day policies that limit when and from where APIs can be consumed
Layer 3: Runtime Protection
Runtime protection detects and blocks attacks in progress. This includes:
- Web Application Firewall (WAF) rules tuned for API traffic patterns (JSON/XML injection, parameter tampering, mass assignment)
- Bot detection to distinguish legitimate API consumers from automated attack tools
- Anomaly detection that baselines normal API usage patterns and alerts on deviations (sudden volume spikes, unusual data access patterns, new consumer IPs)
Layer 4: Monitoring and Incident Detection
DORA Art. 10 detection requirements are particularly critical for APIs because of their high transaction volume and external exposure. API monitoring must cover:
- Access logs with correlation IDs linking requests across internal services
- Usage analytics that identify consumption patterns per consumer, endpoint, and time period
- Error rate monitoring that detects degradation before it becomes an outage
- Security event correlation that connects API anomalies to broader attack patterns
API Inventory: The Foundation No One Talks About
Before securing APIs, you must know what APIs exist. Art. 8 requires identification and classification of all ICT assets supporting business functions. APIs are ICT assets. They must appear in the asset register with:
| API Attribute | DORA Requirement | Source |
|---|---|---|
| Endpoint URL and version | Art. 8 — identification | API gateway configuration |
| Owner and maintainer | Art. 8 — ownership | Development team records |
| Criticality classification | Art. 8 — classification | BIA-derived from consuming business function |
| Consumer list (internal + external) | Art. 28 — third-party register | API gateway analytics |
| Data classification of payloads | Art. 9(4)(c) — data protection | Data governance assessment |
| Authentication mechanism | Art. 9(4)(a) — access control | API gateway configuration |
| Rate limits and SLAs | Art. 7 — capacity | API gateway policies |
| Dependencies (downstream services, databases) | Art. 8 — dependency mapping | Architecture documentation |
A surprising number of financial institutions cannot answer the question: "How many APIs do you expose externally, and who consumes each one?" Shadow APIs — legacy endpoints, development-time APIs accidentally exposed to production, undocumented internal services accessible from partner networks — are pervasive. API discovery tools that analyze network traffic to find undocumented endpoints are essential for Art. 8 compliance.
Third-Party API Risk Management
DORA Art. 28 applies equally to APIs consumed from third parties. A bank that consumes market data from Bloomberg, credit scoring from Experian, sanctions screening from a specialized vendor, and cloud infrastructure APIs from AWS — each is an ICT third-party relationship with API-specific risks:
Availability risk: What happens when a third-party API goes down? Is there a fallback? What is the SLA, and does the bank's continuity plan account for API unavailability?
Security risk: Does the third-party API enforce mutual authentication? Is data encrypted in transit and at rest on the vendor's side? Does the vendor's API security posture match the bank's requirements?
Data residency risk: Where does data sent to a third-party API reside? Does the API process data in jurisdictions compatible with the bank's data governance requirements?
Concentration risk: How many critical functions depend on a single third-party API provider? The concentration risk analysis must include API dependencies.
Testing API Resilience Under DORA
Art. 24-27 require digital operational resilience testing. For APIs, this includes:
- Load testing: Can the API maintain its SLA under peak transaction volumes? What is the degradation profile under stress?
- Chaos testing: How does the API behave when a downstream dependency fails? Does the circuit breaker activate correctly?
- Security testing: Penetration testing specifically targeting API endpoints — BOLA, authentication bypass, injection, mass assignment
- Recovery testing: Can the API be restored within its RTO after a complete failure? Are API configurations (gateway policies, certificates, secrets) recoverable?
- Third-party failover testing: If a consumed API becomes unavailable, does the institution's fallback mechanism activate correctly?
Key Takeaways
- Every API is an ICT asset subject to DORA Art. 8 identification, Art. 9 protection, and Art. 10 detection requirements. Include APIs in the asset register.
- PSD2 APIs create Art. 28 obligations. Third-party API consumers and providers must be managed as ICT third-party relationships with contractual provisions per Art. 30.
- The OWASP API Security Top 10 maps to DORA articles. Each API vulnerability class represents a potential DORA-reportable incident.
- Shadow APIs violate Art. 8. Invest in API discovery before API security — you cannot protect what you cannot see.
- API resilience testing (load, chaos, security, recovery, third-party failover) is required under Art. 24-27 for APIs supporting critical functions.
- Rate limiting and circuit breakers are not just good engineering — they are Art. 7 capacity management and Art. 11 continuity requirements.
Resume en francais
PSD2 a impose l'ouverture des API bancaires aux tiers ; DORA doit desormais assurer leur protection. Les institutions financieres europeennes exposent des centaines d'API a des fintechs, agregateurs et partenaires — chacune constituant un actif TIC soumis a l'article 8 (identification), l'article 9 (protection) et l'article 10 (detection). Les attaques ciblent specifiquement les API financieres avec des techniques comme le BOLA, le bourrage d'identifiants et l'injection. Le top 10 OWASP API Security se cartographie directement sur les articles DORA : chaque vulnerabilite API represente un incident potentiellement reportable. Ce guide propose une architecture de securite API en quatre couches (passerelle, autorisation, protection temps reel, surveillance) alignee sur DORA, et insiste sur l'inventaire API comme prerequis — les API fantomes violent l'article 8 et creent une surface d'attaque invisible. La gestion des risques tiers (Art. 28) doit inclure toutes les API consommees aupres de fournisseurs externes, avec des tests de resilience (charge, chaos, securite, basculement) conformes aux articles 24-27.