API Security in Layers: Why Signature Filtering Misses BOLA

Picture an organization with a WAF, a valid TLS certificate and a yearly penetration test that still finds its customer data on a public forum. The logs show nothing suspicious. The attacker simply changed the order number in the mobile app's API, one value at a time, and read other people's orders. That is where API security differs from classic web security: the attack looks like normal traffic, and there is no signature to match.

Why APIs became the main target

Mobile apps, customer portals, partner integrations and internal dashboards all run on APIs, and every API is a direct path to data. Akamai's research found that about 29% of web attacks target APIs directly. Many teams also lack a complete inventory, so old versions and endpoints built for temporary projects stay online.

The issues that show up most often in real projects:

• Broken object level authorization (BOLA): no ownership check on the requested object
• Tokens that never expire, or API keys embedded in a mobile app
• Endpoints that return the full record and leave filtering to the client
• No rate limiting
• A forgotten v1 that never received the v2 fixes

Filtering helps only with a positive model

A signature-based filter catches known attack patterns, but a request that only swaps an ID looks legitimate to it. The real gain comes from a positive security model: the filter loads the OpenAPI contract and rejects any request that does not match it. Rate limits per token (not only per IP) and JWT validation belong on the same requirements list.

Test from the inside and fix identity

BOLA and other logic flaws are found only by testing the API itself. Dynamic scanning (DAST) driven by the OpenAPI file, interactive sensors (IAST) that see the code path, and both wired into CI/CD replace a yearly test with feedback on every release. Standardizing authentication on OAuth 2.0/OIDC, keeping token lifetimes short and putting a gateway in front of services shrink the attack surface further.

A practical 90-day order: first month, inventory every API and assign an owner; second month, scan and fix BOLA and authentication flaws; third month, enforce the schema, add per-token rate limits and retire old versions.

The full article, with details on each layer and the 90-day roadmap, is here: API Security: Why a WAF Alone Is Not Enough and How to Stack the Layers

— Kazem Mortazavi, independent network-security consultant