Where API Breaches Actually Start
Most of the API incidents we get called in to investigate have nothing to do with a clever, novel exploit. They start somewhere far more boring. A single route that skipped an authorization check. An admin endpoint that was rate limited everywhere except the one path a developer added in a hurry before a release. A logging pipeline that captured everything the security team needed, except on the two services that mattered during the breach window. The attacker did not break the cryptography or reverse-engineer a token format. They found the one door where a control that was present everywhere else happened to be missing.
That pattern is why the OWASP API Security Top 10 reads the way it does. The 2023 revision puts Broken Object Level Authorization (API1) at the top, followed by Broken Authentication (API2) and Broken Object Property Level Authorization (API3). None of those are exotic. They are failures of consistency: a control that the team clearly understood, implemented, and tested on most of the surface area, but not all of it. In regulated sectors, where a single unauthorized read of cardholder data or subscriber records turns into a reportable event, that inconsistency is the whole risk.
The controls involved share an awkward property. Authentication, authorization, rate limiting, input validation, and audit logging do not belong to any single endpoint. They are not features a product owner asks for. Nobody writes a user story that says "when I request another customer's invoice, reject me." These concerns cut across every route the API exposes, and they are invisible when they work and expensive when they are absent. Getting them applied uniformly, on every route, in every service, is the actual engineering problem. This article is about how we approach that in banking, telecom, and critical national infrastructure environments, where "mostly enforced" is not an acceptable posture.
The Controls That No Endpoint Owns
Before deciding where to enforce these controls, it helps to be precise about what each one does and where it tends to fail in practice. The failure modes are more instructive than the definitions.
Authentication and authorization
Authentication answers who is calling. Authorization answers whether that caller is allowed to touch this specific object. Teams tend to get authentication right, because it is centralized by design: an OAuth 2.0 authorization server issues a token, the API validates it, and the plumbing is shared. OpenID Connect on top of OAuth 2.0 handles identity, and for service-to-service traffic mutual TLS gives both sides a verified identity at the transport layer.
Authorization is where the damage happens. A valid token proves identity, not entitlement. When an endpoint accepts GET /accounts/{id}/statements and trusts the id in the path without checking that the authenticated caller actually owns that account, you have Broken Object Level Authorization. The request is authenticated, the token is genuine, and the caller walks out with someone else's statements. We see this most often on endpoints added late, after the authorization pattern was established but before it became muscle memory. Object-level checks have to live close to the data, because only the service holding the record knows who is allowed to see it. That makes them hard to centralize, which is exactly why they get missed.
Rate limiting and resource protection
Rate limiting is usually framed as a performance measure. From a security standpoint it is an abuse control. It slows credential-stuffing runs against login routes, blunts enumeration attacks that walk through sequential identifiers, and caps the blast radius when a leaked key gets picked up by a bot. OWASP tracks this as API4, Unrestricted Resource Consumption, and the consumption in question is not only CPU. It is also the SMS costs on a one-time-password endpoint, the third-party API bill behind a search route, and the database load an unbounded query can generate.
The common implementations are the token bucket and the sliding window. Both are well understood. The mistake is rarely the algorithm. It is scope: a global limit that protects the aggregate but lets one tenant exhaust a shared pool, or a per-IP limit that a distributed botnet sails straight through because every request comes from a different address. In multi-tenant systems, limits need a tenant and identity dimension, not just an IP, or a single abusive customer degrades service for everyone else on the platform.
Input validation and schema enforcement
Every injection class in the book starts with input the application trusted when it should not have. The durable defense is not a clever filter that tries to spot malicious strings. It is positive validation: define what a valid request looks like and reject everything else. An OpenAPI specification with strict JSON Schema for each request body gives you that contract, and a gateway or framework can enforce it before a single line of business logic runs. Reject unknown fields, enforce types and ranges, cap array and string lengths, and you have closed off a large share of the payload-based attack surface before it reaches your code.
Validation also protects the data layer in ways teams underestimate. Length caps stop the memory-exhaustion variant of resource consumption. Type enforcement stops the type-confusion tricks that slip past ORMs. In payment and telecom systems we treat schema validation as a security control with a compliance consequence, not a nicety, because a malformed request that reaches a billing or provisioning service can corrupt state that is genuinely painful to unwind.
Logging, audit trails, and observability
When an incident happens, the logs are the difference between a two-hour investigation and a two-week one. They are also, in most regulated frameworks, a hard requirement rather than an operational preference. The problem is that logging is the control teams most often implement inconsistently, because it produces no visible benefit until the day you desperately need it.
What matters is uniformity and structure. Every request should carry a correlation ID that follows it across service boundaries, so a single customer action can be reconstructed end to end. Logs should be structured, not free text, so a SIEM such as Microsoft Sentinel, Splunk, or Elastic can actually query them. Authentication failures, authorization denials, and rate-limit rejections need to be captured as security events, not buried in debug noise. And sensitive fields, tokens, full card numbers, national ID numbers, have to be redacted at the source, because a log store that quietly accumulates cardholder data becomes an in-scope system nobody planned for.
Uniform Enforcement Is the Hard Part
Once you accept that these controls cut across the whole API, the design question stops being "how do I build rate limiting" and becomes "where do I enforce it so that no route can accidentally skip it." There are three layers where enforcement can live, and mature architectures use all three deliberately rather than defaulting to one.
The edge gateway is the first line. An API gateway such as Kong, Apigee, AWS API Gateway, or Azure API Management sits in front of every service and can enforce authentication, coarse rate limits, and schema validation for every route by default. The strength of the gateway is precisely that it is unavoidable. Traffic cannot reach a service without passing through it, so a control configured there cannot be forgotten on a new endpoint. The limit is that the gateway does not know your data. It cannot decide whether this caller owns that account.
The service mesh is the second layer. A mesh such as Istio or Linkerd gives you mutual TLS between every service and a place to enforce identity-aware policy without changing application code. This is where zero-trust between internal services becomes practical: even east-west traffic inside the cluster is authenticated and encrypted, so a compromised service cannot freely impersonate others.
The application is the third layer, and it is the only place object-level authorization can truly live. The service that owns the data is the only component that knows the ownership rules. The realistic pattern is defense in depth: the gateway guarantees the baseline is present everywhere, the mesh handles identity and encryption in transit, and the application enforces the fine-grained rules that depend on business context. When we audit an API estate, the finding is almost never "there is no authorization." It is "authorization exists in the services that remembered to add it," and the remediation is a policy that makes the baseline structural rather than a matter of developer discipline.
Where Each Control Belongs
The table below is close to the reference we hand teams when we help them draw the line between platform-enforced and service-enforced controls. The guiding rule is simple: push a control as far toward the edge as it can go without losing the context it needs to be correct.
ControlPrimary enforcement pointWhy it lives thereOWASP API reference
Authentication (token validation)
API gateway
Unavoidable at the edge; shared across all routes
API2
Object-level authorization
Application service
Only the data owner knows the ownership rules
API1
Service-to-service identity
Service mesh (mTLS)
Verified identity for internal, east-west traffic
API2
Coarse rate limiting
API gateway
Cheap, global abuse protection before traffic fans out
API4
Per-tenant / per-user limits
Application or gateway with identity context
Needs the caller's identity, not just an IP
API4
Schema / input validation
Gateway, reinforced in the service
Reject malformed input before business logic runs
API6
Audit and security logging
Every layer, aggregated to a SIEM
Reconstruct any action end to end
API9
The Compliance Dimension Teams Underestimate
In a regulated environment these controls are not optional engineering hygiene. They map directly onto obligations that an auditor will test. Treating them as security-only work, disconnected from compliance, is how organizations end up rebuilding the same control twice: once for the security team and once, months later, for the assessor.
Under PCI-DSS v4.0, an API that touches cardholder data inherits real requirements. Requirement 8 governs authentication and identity. Requirement 6.2 covers secure development and protection against common attack classes, which is where input validation earns its keep. Requirement 10 mandates logging and monitoring of access to cardholder data and the systems around it, with enough detail to reconstruct events. Each of the cross-cutting concerns above lines up with a clause an assessor will ask you to evidence.
ISO 27001 approaches the same ground through its Annex A controls on access control, logging, and secure development, and expects you to show the controls operate consistently rather than existing on paper. The NIST Cybersecurity Framework frames it across functions: authentication and authorization sit under Protect, audit logging and monitoring feed Detect, and the whole exercise depends on first knowing your API inventory under Identify. CIS Benchmarks give you the concrete hardening baselines for the gateways, container platforms, and operating systems these APIs run on. The value of holding this map in your head while you design is that one well-placed control satisfies a security objective and a compliance clause at the same time, which is a far cheaper position than discovering the gap during an assessment.
The API inventory point deserves emphasis, because it is where most compliance gaps originate. You cannot enforce a control uniformly across an estate you have not fully catalogued. Shadow APIs, deprecated versions still accepting traffic, and internal endpoints exposed by a misconfigured route are the assets that fail an audit and, more often, cause the breach. An accurate, continuously updated inventory is the unglamorous foundation the entire control set rests on.
A Practical Checklist for Hardening an API Estate
When we run an API security review, the work follows a fairly consistent order. The list below is a condensed version teams can use to self-assess before bringing in an external assessment.
- Build a complete inventory of every API and version currently serving traffic, including internal and partner-facing endpoints. Nothing else is trustworthy until this exists.
- Confirm authentication is enforced at the gateway for every route by default, with any unauthenticated endpoint being a deliberate, documented exception.
- Test object-level authorization directly: with a valid token for one account, attempt to read and modify another account's objects. Do this per resource type, not once.
- Verify rate limits carry an identity or tenant dimension, and that sensitive routes such as login, password reset, and OTP have their own stricter limits.
- Enforce request validation from an OpenAPI schema, rejecting unknown fields and capping lengths, and confirm the same rules apply on internal routes, not just public ones.
- Check that logs are structured, carry correlation IDs across services, capture security events, and redact secrets and regulated data at the source.
- Confirm those logs reach a SIEM with alerting on authentication failures, authorization denials, and rate-limit breaches, and that retention meets your regulatory obligation.
- Enable mutual TLS for service-to-service traffic so a single compromised service cannot impersonate its neighbours.
- Map each control to the specific PCI-DSS, ISO 27001, or NIST CSF requirement it satisfies, so security and compliance evidence come from the same source.
The order matters. Inventory first, because coverage is meaningless without it. Authorization testing early, because it is the highest-impact and most commonly missed control. Logging and SIEM integration before you consider the work done, because the day you need them is not the day to discover they were incomplete.
How Aydahwa Enterprise Can Help
We work with banks, telecom operators, and critical national infrastructure providers whose APIs carry data where a single unauthorized read is a reportable event. That context shapes how we run API security engagements: we treat authentication, authorization, rate limiting, validation, and logging as one connected control set, and we map each control to the PCI-DSS, ISO 27001, and NIST CSF obligations it satisfies so the same work serves both the security and the audit. Our team holds credentials including ISO 27001, PCI-DSS, and Microsoft Cybersecurity Architect Expert, and we harden the underlying platforms to CIS Benchmarks rather than leaving the gateway and cluster configuration as an afterthought.
If you are responsible for an API estate and are not certain the baseline controls are enforced on every route, that uncertainty is the finding. A structured review resolves it. You can start with our free cybersecurity self-assessment or work through the cybersecurity readiness checklist to gauge where you stand. When you are ready for hands-on work, our cybersecurity services cover API and application security reviews, and our cloud security and migration practice handles the gateway, mesh, and platform hardening that these controls depend on. To discuss a specific environment, get in touch and we will scope it against your sector's regulatory requirements.
