From BOLA To Triggering Refunds: How Attackers Exploit API Logic Flaws

Ivan Novikov, CEO of Wallarm, explains how organizations can detect new or novel API calls, sudden spikes in errors, and logins coming from new countries before they escalate into compromise. 

Novikov, a security researcher and entrepreneur with deep expertise in web and API security, has helped Wallarm in building open-source tools and researching emerging attack techniques.

He also discussed how to reduce false positives in machine learning-based protection, strengthen token mechanisms, and stop Broken Object Level Authorization (BOLA), along with hidden field manipulation. 

Novikov shared insights on securing GraphQL queries and keeping baselines accurate by auto-generating protections from API specifications. 

Vishwa: Many organizations are aware that third-party Application Programming Interfaces (APIs) are a risk, but few have a clear strategy for monitoring them. What indicators should they prioritize to spot misuse or compromise? 

Ivan: New or novel API calls are the first sign of fire, for example, partners touching endpoints that were never shared with them. Organizations should also watch out for sudden spikes in errors or traffic, which can signal that someone is poking at the doors. 

Logins or tokens coming from new countries or unknown networks are also a red flag. Another behavior to watch for is unusually big, fast data pulls that look like a download, not normal business. If real traffic doesn’t match your API specification, treat it like a break-in attempt.

Vishwa: Machine learning-based API protection can generate false positives. What tuning approaches help reduce noise without introducing blind spots?

Ivan: Actively blocking attacks is important, but you can start in observe-only mode so the system learns your normal traffic patterns first. Tuning alerts by endpoint and business risk instead of ‘one rule for all’ can help ensure that security teams aren’t overwhelmed by chasing false positives. 

Ideally, systems should leverage human expertise by letting analysts mark alerts as “good” or “bad” so the model learns fast. When you’re ready to actively block attacks, start surgically by enabling blocking for a small slice first and measuring impact.

Vishwa: API abuse increasingly exploits authentication and token mechanisms. What controls are most effective at guarding against this layer of attack?

Ivan: The biggest impact comes from making tokens short-lived and then alerting on any reuse, even once. Also, bind tokens to a device or session so an attacker can’t replay them elsewhere. 

For the movement of money or the export of data, an extra verification is required. You can also add smart rate limits per user and per action to stop bursts. Don’t forget to validate every token detail and rotate keys quickly.

Vishwa: As APIs become the backbone of digital services, what exploitable logic vulnerabilities are you observing that evade traditional input validation?

Ivan: In classic Broken Object Level Authorization (BOLA) attacks, attackers rotate through IDs to peek at another customer’s data. By manipulating hidden fields, an attacker can change prices, roles, or discounts without you seeing it. 

We also see attackers skipping application logic steps to trigger refunds, credits, or shipments out of order. Rapid, repeated API calls can drain inventory or stack coupons for free value. Addressing these business logic flaws requires implementing strict permission checks, server-side steps, and fair limits tied to business rules. 

The OWASP Business Logic Abuse Top 10 is a great way to learn about business logic abuse without tying it to a specific technology.

Vishwa: How has the shift toward GraphQL and RESTful architectures changed your approach to anomaly detection in API traffic?

Ivan: Let’s be clear, the shift towards REST has already happened. It’s practically legacy technology at this point, and is used in the majority of APIs. 

GraphQL is the second most popular API protocol, but it is still poorly understood from a security perspective. 

With GraphQL, users can request “everything at once,” so it’s important to cap how big a query can be, limit the number of batched queries, and block introspection queries in production. Additionally, applications should only allow saved, approved queries in production. 

REST remains simpler; make sure the method and path are performing the right action. Applications should enforce authentication on every request and authorization for specific objects and functions, not just requests. 

For both styles, monitor response shape, list sizes, and unusual delays. Score behavior by operation or route so signals stay clean and comparable.

Vishwa: API platforms evolve rapidly; how do you maintain accurate detection baselines across continuous deployment cycles?

Ivan: The best process is to treat your API specification as the single source of truth and to auto-generate protections from that specification every time you release. This kind of positive security, i.e., only allowing known-good traffic, requires a mature development and security organization, but is very effective. 

Replaying real attack traffic in a safe environment can help identify vulnerabilities without putting production at risk. Employ best practice releases by deploying in stages and rolling back fast if risk goes up. Version your baselines with each release so you always know what has changed.

Vishwa: With API-level attacks on the rise, what cybersecurity tools and solutions would you recommend for API security?

Ivan: Tools that protect APIs and grow with you (OSS-first):

• Start schema-first: Publish OpenAPI/GraphQL SDL and enforce it at the edge with API Firewall (OSS) as a contract-checking reverse proxy that blocks spec violations.
• Run a lightweight OSS stack: Envoy/Kong/Traefik for gateway, OPA/Rego for authZ, JWT validation with local JWKS, mTLS, and per-route/per-tenant rate limits—keep rules in Git for version control.
• Shift-left in CI: Lint with Spectral, validate with openapi-cli, fuzz with Schemathesis, and add OWASP ZAP baseline; fail the build on schema drift or broken contracts.
• Watch everything: OpenTelemetry traces, Prometheus metrics, Jaeger/Tempo for tracing, and OpenSearch/Elastic for logs with alerts on error spikes, latency, and unusual payload sizes.
• When coverage is solid and runbooks are working, layer in enterprise API security/WAAP for behavior analytics, bot/fraud controls, and monetization—choose one that ingests your schemas and telemetry so it snaps onto the OSS foundation cleanly.