The API gateway as a security boundary
In a microservices architecture, dozens of services communicate over the network. Exposing each service directly to the internet means each one must independently handle authentication, rate limiting, TLS termination, and input validation. That is duplication, inconsistency, and a massive attack surface.
An API gateway centralises these cross-cutting concerns. External traffic enters through the gateway, which enforces security policies before routing requests to internal services. Kong, AWS API Gateway, and NGINX Plus are the most common choices for Nigerian fintech teams. The gateway becomes your single ingress point — and your most important security control.
But centralisation creates a single point of failure. If the gateway is misconfigured — bypassed routes, missing auth checks, overly permissive CORS — every service behind it is exposed. We see this pattern regularly in our API security assessments.
JWT validation at the gateway
The gateway should validate JWTs before forwarding requests to backend services. This means the individual microservices do not need to implement their own JWT validation logic — they receive pre-authenticated requests with user identity information in forwarded headers.
What the gateway must check
- Signature verification. Validate the JWT signature using the correct public key (RS256/ES256) or shared secret (HS256). Reject tokens with algorithm confusion — never allow
alg: none. - Expiry and issued-at claims. Reject expired tokens. Validate
iatto catch tokens issued suspiciously far in the past. - Issuer and audience claims. Ensure
issmatches your auth server andaudmatches the intended API. Without audience validation, a token issued for your admin panel can be used against your payment API. - Scope/role claims. Enforce coarse-grained access control at the gateway level. A read-only API key should not reach your write endpoints.
Kong implements this through the JWT plugin, AWS API Gateway through Lambda authorizers or Cognito integration, and NGINX through the auth_jwt module. Regardless of the platform, the logic must reject the request at the gateway, not pass it through to a service that might forget to check.
For a deeper look at authentication vulnerabilities in fintech APIs, see our authentication security service and the BOLA fix guide.
Gateway bypass through direct service access
The most dangerous misconfiguration we find is backend services that are directly reachable on the network — via public IP, misconfigured load balancer, or exposed Kubernetes NodePort. The gateway enforces authentication and rate limiting, but an attacker who discovers the direct service endpoint bypasses all of it. Backend services must be network-unreachable from outside the private network. Use Security Groups, network policies, or firewall rules to enforce this at the infrastructure level.
Rate limiting: protect business logic
Rate limiting at the gateway protects your services from abuse, brute-force attacks, and denial-of-service. But generic rate limiting (100 requests per second per IP) is not enough for fintech. You need differentiated rate limits based on the endpoint's sensitivity and business context.
Authentication endpoints
Login, OTP verification, and password reset should have aggressive limits (5–10 requests per minute per IP/user). These are the primary targets for brute-force and credential stuffing attacks.
Transaction endpoints
Payment initiation and transfer endpoints need rate limits tuned to legitimate usage patterns. A user initiating 50 transfers per minute is either a bot or compromised. Flag and throttle accordingly.
Read-heavy endpoints
Balance checks and transaction history can tolerate higher limits but still need caps to prevent scraping and enumeration attacks.
Implement rate limiting by user ID (from the validated JWT), not just IP address. IP-based limits are easily bypassed with rotating proxies. User-based limits catch abusive accounts regardless of their network path. Our rate limiting deep-dive covers implementation patterns for Paystack and Flutterwave integrations.
Request transformation and validation
The gateway can strip, rewrite, or validate request components before they reach backend services. This creates a sanitisation layer that reduces the attack surface of every downstream service.
- Strip unexpected headers. Remove headers that could be used for injection or spoofing (e.g.,
X-Forwarded-Forfrom untrusted clients). - Enforce content types. If an endpoint expects
application/json, reject requests with other content types before they reach the service. - Validate request body size. Set maximum payload sizes at the gateway to prevent resource exhaustion attacks against downstream services.
- Add internal headers. Inject authenticated user identity (user ID, roles) into headers for backend services, so services do not need to parse and validate JWTs themselves.
mTLS between services: zero trust internally
The gateway secures the north-south boundary (external to internal). But east-west traffic (service to service) is equally important. If an attacker compromises one service, they can impersonate any other service in an unencrypted internal network.
Mutual TLS (mTLS) ensures that both sides of every internal connection verify each other's identity via certificates. Your payment service will only accept connections from services with valid, trusted certificates — not from an attacker's pod that has moved laterally through the network.
Implementing mTLS manually (certificate generation, rotation, distribution) is operationally painful. This is where service meshes become valuable.
Service mesh security: Istio and Linkerd
A service mesh like Istio or Linkerd injects a sidecar proxy alongside every service. The sidecar handles mTLS transparently — your application code does not change. Beyond encryption, the mesh provides:
- Authorization policies. Define which services can call which endpoints. Your user-facing API can call the payment service, but the notification service cannot — enforced by the mesh, not by trust.
- Observability. Every request is logged with latency, status code, source, and destination. Anomalous traffic patterns (sudden spikes from an unusual service) become visible.
- Traffic encryption. mTLS is enabled mesh-wide with a single configuration. Certificate rotation is automatic.
- Fault injection and circuit breaking. Test how your services behave when dependencies fail — critical for financial systems where a cascading failure can cause double-charges or lost transactions.
For microservices security in fintech, the combination of an API gateway (north-south) and a service mesh (east-west) provides defense in depth that no single tool can match.
Designing or reviewing your microservices security architecture? We can help.
Book an Architecture Security ReviewGateway security checklist
- Validate JWTs at the gateway — signature, expiry, issuer, audience, and scopes.
- Enforce differentiated rate limits by endpoint sensitivity and user identity.
- Ensure backend services are not directly reachable from the internet.
- Strip and sanitise headers at the gateway before forwarding.
- Enforce request body size limits and content type validation.
- Implement mTLS for all service-to-service communication.
- Use a service mesh (Istio/Linkerd) for transparent mTLS and authorization policies.
- Log all gateway decisions (allowed, rate-limited, rejected) for forensic analysis.
This architecture applies whether you are running on Kubernetes, ECS, or bare EC2. The patterns are the same; only the tooling differs. Review our fintech security checklist for a complete set of controls across your stack.
Related reading
Blog: Microservices security for fintech · Zero trust for fintech startups · The most dangerous API vulnerability
Guides: OWASP for fintech · Fintech security checklist · Web app pentest guide
Services: API security · Secure architecture review · Penetration testing