Open banking APIs with poor architecture are particularly vulnerable to DDoS attacks, user session hijacking, and secret leaks.
Below, we examine key architectural vulnerabilities and propose technical mitigation measures, including methods for protecting logs and transaction history.
Risks of Open APIs: What to Consider When Architecting
The first is DDoS attacks, which overload server and network resources, rendering the API unavailable to clients and third-party services. Which API architecture is most vulnerable to DDoS attacks and requires hardening?
- If there is no rate limiting or throttling at the client, IP, or API key level, even legitimate high-frequency traffic (e.g., ~1000 RPS per endpoint) can exhaust server resources (CPU, connection pool, thread pool) and cause denial of service.
- A non-scalable architecture without load balancing between containers/VMs. For example, 1 server + 1 load balancer without autoscaling.
- The lack of filtering and attack detection mechanisms, such as firewalls, WAFs, and IDS/IPS, means that suspicious traffic is not detected or blocked at the network (L3/L4) and application (L7) layers.
- All endpoints are processed with equal priority. A DDoS attack on a less critical endpoint could degrade the performance of the entire system.
- Lack of monitoring and automated response systems such as real-time DDoS detection, alerts, load management, and rate-based blocking.
The second type of risk is the hijacking of user sessions to gain unauthorized access to a user’s account. It’s important to consider how sessions are stored and transmitted.
Which architecture is most vulnerable?
- In the absence of mandatory HTTPS or the use of a weak TLS configuration (outdated TLS versions, insecure cipher suites, lack of HSTS), session data can be intercepted through MITM attacks.
- Use long-lived access tokens or session cookies without rotation or server invalidation upon logout. If compromised, a stolen token provides the attacker with long-term access.
- Incorrect configuration of session cookies (lack of Secure, HttpOnly, SameSite), which increases the risk of session theft or compromise through XSS and related attacks.
- The lack of contextual or risk-based session verification (IP range, User-Agent, device fingerprint) and additional validation mechanisms for changing environments. As a result, a stolen token can be used on another device.
The third type of risk is the leakage of secrets (API keys, access tokens), which allows requests to be made on behalf of a legitimate client or service, bypassing identity-based authentication mechanisms.
The most vulnerable architectureshave the following characteristics:
- Storing API keys and tokens in source code, public repositories or client-side (JavaScript, mobile apps), as well as environment variables without isolation and access control. In this case, any leak leads to a compromise of secrets.
- Lack of centralized secrets management (Vault, AWS Secrets Manager, GCP Secret Manager), including access control, auditing, versioning, and secret rotation.
- Using keys without a TTL, without scope/permission restrictions, and without binding to a specific service/workload identity. In this case, a leak leads to prolonged and widespread access to the system.
- Direct use of API keys without a proxy or mediator layer (e.g., backend-to-frontend, token exchange via STS or OAuth). This complicates the rapid revocation, rotation, and restriction of a compromised key, increasing the leak’s blast radius.
Security Architecture: From OAuth 2.0 to mTLS
To make the API architecture more resilient to DDoS attacks, the following mechanisms can be implemented:
- Rate limiting and throttling. Configure request rate limits (requests per second/requests per minute) at the client, IP, or API key level. Implementation is possible at the API Gateway level (e.g., Kong, Apigee, NGINX) and at the service level (defense-in-depth). Redis or in-memory counters are typically used for RPS counting. Token Bucket or Leaky Bucket algorithms provide smooth load limiting, preventing server resource exhaustion.
- Autoscaling and load balancing. Horizontal scaling of services and dynamic request balancing ensure API resilience as load increases. Scaling is achieved through the automatic addition of containers or VMs (Kubernetes HPA/VPA, AWS Auto Scaling) based on CPU, memory, or custom metrics. Load balancers (NGINX, HAProxy, Envoy) are used to distribute traffic, ensuring even distribution of requests across instances.
- WAF and L7 filtering of abnormal traffic. Implementation is possible via cloud-based or built-in WAFs (AWS WAF, Cloudflare, NGINX ModSecurity). Configuration includes OWASP Top 10 rules, rate-based blocking, and custom signatures. Integration with logging and SIEM allows for the detection of suspicious patterns and automatic response to recurring threats.
- Prioritization of critical endpoints. This is implemented through priority queues at the API Gateway (Kong, Apigee), NGINX, or service bus level. Critical operations are assigned a high weight and an increased rate limit, while secondary endpoints are limited using throttling or rate-based blocking. In Kubernetes, QoS classes and request priority can be used for pods to ensure that resources are allocated to critical services when CPU or memory is overloaded.
To protect the API from session hijacking, you can implement the following mechanisms:
- OAuth 2.0 and short-lived tokens. Implemented via an identity provider (Keycloak, Auth0, Okta) with support for short-lived access tokens and refresh tokens. Refresh tokens must be stored in secure server storage (e.g., Redis with AES-256 encryption or a SQL database with encrypted columns) and issued through a secure backend endpoint.
- Secure cookies and SameSite attributes. HttpOnly and Secure cookies are often used to store session tokens. These restrict access from JavaScript and transmit data only over HTTPS. The SameSite attribute (strict/lax) prevents CSRF-like attacks. Secure cookies are configured at the API Gateway or web server level (e.g., NGINX, Express, FastAPI).
- TLS 1.2/1.3 for all connections. TLS is configured at the ingress or load balancer level with automatic certificate renewal via ACME (Let’s Encrypt). Certificate and hostname verification is mandatory on the client side. It is recommended to enable only secure cipher suites (e.g., AES-GCM, ChaCha20-Poly1305) and disable legacy protocols and weak algorithms.
To prevent API key leaks, the following measures are recommended:
- mTLS. Mutual TLS authentication between the client and server is recommended, with client certificate verification on the API Gateway or ingress (NGINX, Envoy, Kong). Certificates should be stored in a secure vault (HSM, Vault) and validated via CRL or OCSP to prevent the use of compromised keys.
- Key storage in Vault/HSM. API keys and secrets can be stored in HashiCorp Vault, AWS Secrets Manager, or an HSM with device-level encryption and access via RBAC or policy. Keys can be accessed via an API with audit logging for transaction tracking.
- Regular key rotation. Keys can be automatically generated and changed using Vault’s built-in mechanisms or scripts, with service configuration updates via the CI/CD pipeline. Old keys should be immediately invalidated.
Mitigating these vulnerabilities requires more than just implementing a single security protocol; it demands a secure API architecture that integrates defense-in-depth principles.
This includes mandatory mTLS for service-to-service communication, robust rate limiting at the gateway level, and automated secret rotation.
By treating security as a foundational requirement rather than a peripheral feature, financial institutions can build trust with third-party integrators while maintaining complete control over their sensitive data pipelines.
Technical measures to ensure log integrity
The integrity of transaction logs/history in banking APIs is critical for reliable auditing.
Using robust security mechanisms allows for rapid detection of fraudulent transactions, restoration of the sequence of events in the event of failures, and compliance with regulatory requirements.
The most popular options are:
- Blockchain (DLT), where every API event/transaction log entry is written to a distributed, immutable chain. Pros: This method provides the highest level of security and tamper-proofing, enables distributed auditing without a single point of failure, and maximizes historical verifiability. Load: High, requires DevOps/Infrastructure support, requires network node organization, consensus, and scalability management; API integration requires adaptation.
- Digital signatures and HMAC (each record is signed with a cryptographic key). Fast, easy to integrate, minimal overhead. Technical risks: keys must be stored in a secure vault (HSM/Vault), rotated periodically, and key access events must be logged.
- WORM storage: Write Once, Read Many (logs are written to immutable storage, preventing modifications/deletions). Easy to integrate. Technical risk: access control and integrity monitoring are required; scalability at large volumes require sharding or cloud solutions with WORM (e.g., S3 Object Lock).
