API Security in Ecommerce: What CTOs Get Wrong

Most ecommerce CTOs we talk to have a reasonable handle on their frontend security posture. WAF in place, DDoS protection sorted, bot management on the roadmap. The conversation gets uncomfortable when it turns to APIs.

It’s not that they’re unaware. They know APIs need securing. The attack surface is just bigger than it looks, the tooling caught up later than it did on the web application side, and most API programmes have gaps nobody’s had time to close. Then on top of that, AI shopping agents have started hitting ecommerce APIs in volume over the last year, and that has changed what “normal” traffic even means.

So this post is about those gaps — the ones we keep finding, and what the agent shift has done to the picture.

Why APIs are the target now

Ecommerce platforms have shifted heavily toward API-first architectures over the last five years. Headless commerce, mobile apps, third-party integrations, microservices. All of it runs on APIs. Wallarm now puts APIs at roughly 83% of all web traffic, and the OWASP API Security Top 10 exists because attackers noticed the shift before most defenders did.

A well-designed API is predictable, documented, and consistent. Useful for developers. Also useful if you’re trying to abuse it systematically. APIs expose business logic directly (pricing, inventory, account data, payment flows) in a way that traditional web applications partially obscured behind server-rendered HTML.

And unlike a slow website, a misbehaving API tends to fail quietly. Users see an error message. The security team sees nothing until someone goes looking in the logs.

The newer wrinkle: AI shopping agents on ChatGPT, Gemini, Microsoft Copilot, and Perplexity are completing real purchases for real consumers now. eMarketer put AI-platform-driven retail spend at around $20.9 billion for 2026, roughly 4x the 2025 figure. That traffic doesn’t behave like a human browser session. It hits APIs directly, at machine speed, often through emerging protocols, and a lot of the assumptions defences were built on — volumetric thresholds, browser fingerprints, plausible session timing — apply differently or not at all.

The mistakes that keep coming up

Treating authentication as the whole problem

“We have OAuth 2.0 and JWT tokens.” Good. That’s not sufficient.

Authentication tells you who is making the request. It doesn’t tell you whether what they’re doing is legitimate. An authenticated user (or an attacker with a valid token) can still:

• Call endpoints they shouldn’t have access to
• Access another user’s data by manipulating an ID in the request — broken object-level authorisation, or BOLA (OWASP API1:2023, and by a wide margin the most common API vulnerability we find)
• Perform actions their role shouldn’t permit — broken function-level authorisation (OWASP API5:2023)

BOLA is particularly common in ecommerce because order IDs, customer IDs, and product IDs tend to be sequential or predictable. If your /api/orders/12345 endpoint returns order data for any authenticated user — not only the one who placed that order — authentication isn’t going to save you. Salt Security and OWASP both put BOLA at around 40% of API attacks, and Wallarm’s 2026 API ThreatStats report shows authorisation failures still dominating disclosed breaches.

We see this in live production ecommerce APIs more often than we’d like. The Trello breach in 2024 exposed roughly 15 million user records through exactly this pattern: an unauthenticated developer endpoint that accepted email lookups. The fix is usually straightforward once you find it. Finding every endpoint where the check is missing is the actual work.

No rate limiting at the API layer

Rate limiting at the CDN or WAF level catches volumetric attacks. It doesn’t catch low-and-slow abuse of specific API endpoints.

An attacker enumerating customer accounts doesn’t need to hammer your API. A few requests per second, spread across a rotating pool of residential proxies, against your /api/users/{id} endpoint will quietly walk through your customer database over hours or days without tripping a single volumetric threshold. Credential stuffing now accounts for over 30% of API attacks, and the operators behind it know exactly how to stay under static thresholds.

The same applies to price scraping, inventory monitoring, and authentication-endpoint abuse. These attacks are designed to look like normal API usage, and without endpoint-specific rate limiting and behavioural anomaly detection, they largely succeed.

This problem gets worse with agent traffic. An AI shopping agent making 200 product lookups in two minutes does roughly what a scraper does, except it’s a legitimate buyer’s assistant. The behavioural signal you’d normally use to flag the scraper now flags a customer. There isn’t a clean answer to that one yet.

Shadow APIs

Shadow APIs are endpoints that exist in your production environment but aren’t in your current inventory. They build up over time. Old versions that weren’t decommissioned properly. Third-party integrations that added their own endpoints. Internal tooling that got exposed. Developer convenience routes that never got cleaned up. OWASP tracks this as Improper Inventory Management (API9:2023), which is one of the more consistently underrated risks on the list.

The numbers are bad however you measure them. Wallarm’s research across thousands of customer deployments finds the average enterprise has roughly 3x more APIs than the team realises, with shadow APIs making up around 40% of total exposure. Other industry analyses put the share of undocumented endpoints somewhere between 20% and 50%, depending on how you count zombie versions and AI-generated endpoints. The honest read is that whatever you think your number is, it’s probably low.

Some of those endpoints have weaker authentication. Some have no authentication at all. Some expose data that the current API design explicitly tries to protect. The 2024–2025 Stripe legacy-endpoint card-testing campaigns are a useful example of why “deprecated” doesn’t equal “not exploitable” — attackers ran large-scale skimming through endpoints that should have been turned off years earlier.

You can’t secure what you can’t see, which is the boring truth that makes continuous API discovery a precondition for everything else. Most ecommerce security programmes skip this step because it’s unglamorous and the findings are uncomfortable.

Trusting internal traffic

The assumption that traffic from inside the network perimeter is safe has been wrong for a long time. In a microservices architecture it’s catastrophically wrong.

Internal APIs (the ones your services use to talk to each other) tend to be less rigorously secured than external-facing ones. No authentication between services. Shared static secrets that nobody rotates. Network policies permissive enough that any service can call any other service. We see one or more of these on most engagements.

It matters because lateral movement in a compromised environment travels through internal APIs. If an attacker gets a foothold somewhere — vulnerability, compromised credential, supply chain — weak internal API security is what turns that foothold into a breach. For an ecommerce platform handling payment data, zero trust for service-to-service calls is the baseline. Mutual TLS, signed and scoped tokens, deny-by-default network policies. None of it is exotic; teams just don’t get to it because it always feels like there’s a fire that’s more pressing.

API versioning that creates security debt

“We’ll deprecate v1 once v2 is stable.” Three years later, v1 is still serving 15% of production traffic because of one integration nobody wanted to update.

Old API versions accumulate security debt. They miss patches that went into newer versions. They sometimes implement authentication differently. The input validation tends to be weaker because it was written to older standards. And once a version is officially “deprecated,” it gets less security attention, not more.

What helps: an active list of versions in production with traffic shares against each, a known consumer for each version, and a hard end-of-life date you actually commit to. The migration work to move a client off v1 is almost always smaller than the risk of leaving v1 alive forever, and the conversation is much easier when the EOL was set the day v2 shipped rather than two years later.

Not having a model for agent traffic

The new one. Most ecommerce API programmes were designed for two kinds of clients: your own frontends, and trusted third-party integrations. AI shopping agents fit neither category. They authenticate on behalf of a user, they make decisions, they batch requests, and a growing share of them call your APIs through emerging protocols (MCP, Universal Commerce Protocol, A2A) that your existing controls weren’t tuned for.

Wallarm’s Q3 2025 ThreatStats report logged a 57% quarter-on-quarter rise in AI-related API vulnerabilities. One pattern keeps recurring: when an LLM agent calls downstream APIs on behalf of a user, object-level authorisation checks are often skipped. The agent has a valid token, the request looks fine, and the user-id check that should be enforcing BOLA isn’t there. So API1:2023 has a fresh attack surface in 2026 that didn’t exist when the list was written.

Worth asking your team: have we actually decided how agent traffic is treated? If the answer is no, agents are getting through on rules built for human users.

What good API security actually looks like

Visibility comes first; you can’t protect endpoints you don’t know exist. Controls come next, and only some of them are technical — a per-endpoint rate limit is technical, a deprecation deadline is mostly cultural. And then you need someone whose actual job description includes enforcing both. Tools without an owner produce alerts that nobody triages.

Continuous API discovery and inventory

Know what you have before you try to secure anything. Run automated discovery against your production traffic, identify every endpoint being called, every parameter pattern, every response structure, and treat it as a continuous job rather than an audit. APIs change too quickly for snapshot inventories to stay useful. AI code assistants have made this worse — they’re embedding third-party calls into production code at a pace traditional inventory workflows can’t keep up with.

That gives you a baseline. Anything in production but not in your inventory is a shadow API to investigate. Anything in your inventory but not in your documentation is, at minimum, a documentation gap, and quite possibly a security one too.

Authorisation that goes beyond authentication

For every endpoint, the question worth asking is: which users should be able to call this, with which parameters, and whose data should come back? Then enforce that at the code level, and test it explicitly rather than assuming the framework is doing it for you.

For ecommerce, the high-risk endpoints are predictable: order history, customer profile, payment methods, account details. That’s where to spend time first. Object-level authorisation — confirming the requesting user owns the resource they’re requesting — has to be present on all of them.

Automated BOLA and BFLA tests in CI are the most reliable defence we’ve seen. They’re tedious to write, but one of them catching a vulnerability in staging is worth significantly more than a penetration test catching the same thing in production three months later.

If you allow AI agent traffic, the same checks need to fire when the caller is an agent acting on behalf of a user. A valid token is not the same thing as authorisation to perform a specific action, and that distinction has been one of the most reliably-broken things we’ve seen in 2025–2026 agent integrations.

Endpoint-specific rate limiting and behavioural baselines

Rate limits at the WAF level are a starting point. You also need limits configured per endpoint, tuned to what normal usage actually looks like.

Normal usage of your authentication endpoint might be 5 requests per minute per IP. Normal usage of your product search endpoint might be 60. The same threshold applied to both will either be too permissive on auth or too restrictive on search. Per-endpoint limits require more configuration work, but they’re the only way to catch low-and-slow abuse reliably.

Akamai’s API Security product (the rebranded Noname Security platform, acquired in June 2024) sits at the layer above this. It builds behavioural baselines per endpoint from real traffic, then flags requests that deviate. An authentication request at 2am from an IP that’s never appeared before, using a user agent that doesn’t match any of your mobile or web clients, that makes 200 calls in ten minutes — that looks exactly like what it is, even when no individual call would trip a static rate limit. For what it’s worth, Gartner’s 2026 Peer Insights Voice of the Customer report named Akamai the only Customers’ Choice in API Protection (93% recommendation rate). Eknix is an Akamai partner, so take that with the appropriate salt; the customer reviews are public if you want to check.

Schema validation

Define what valid requests to each endpoint look like — expected parameters, types, formats, value ranges — and reject anything that doesn’t match at the edge before it reaches your application.

It’s not glamorous work. It does eliminate an entire class of injection attacks and meaningfully raises the cost of automated fuzzing. An attacker probing your API for injection vulnerabilities first has to figure out what a valid request even looks like, and with schema validation at the edge, that probing happens in front of a control that’s logging and rate-limiting everything it rejects.

A proper deprecation policy

This part is governance, not tooling. Write down when old API versions get turned off. Tell integration partners with enough lead time. Then actually turn them off.

Without a deprecation policy, you’re accumulating security debt with every release. The older a version gets, the harder it is to shut down, because more integrations come to depend on it. The right time to define end-of-life for an API version is when you ship the next one, not three years later when you’re trying to justify the migration work to finance.

A practical starting point

If your API security programme is early-stage or overdue for a review, here’s a rough order to work in.

Run an API discovery scan. No real progress until you have an inventory you trust. The vendors that come up most in 2026 Gartner reviews are Akamai API Security, Salt Security, Wallarm, Traceable, and Imperva. If budget is the issue, careful analysis of gateway logs will at least tell you what’s in production today.

Pull your OWASP API Top 10 coverage. Walk each item, assess your current controls honestly. The three most commonly unaddressed in our reviews are API1 (BOLA), API8 (security misconfiguration), and API9 (improper inventory management). Start with whichever scares you most.

Test BOLA manually on your highest-risk endpoints. Log in as user A, get the resource IDs for user B’s orders or payment methods, and try to access them as A. If you can, you have a production vulnerability and nothing else on this list is more urgent.

Audit your API version inventory. What versions are live? What’s the traffic split? When does v1 die? If you can’t answer those in ten minutes, there’s no usable inventory.

Look at how your services authenticate to each other. “They’re on the same network” isn’t an answer. Mutual TLS, signed JWTs, or some equivalent should be in there somewhere.

Decide your agent policy. Is AI agent traffic allowed? At which endpoints, with what rate limits, with what authentication? “We haven’t thought about it” means agents are already getting through on rules written for human users.

Most of these gaps aren’t there because anyone made bad decisions. API security tooling and practices matured later than API adoption, and the attack surface grew faster than most security roadmaps anticipated. The teams we work with that have a good posture aren’t better-resourced than the ones that don’t. They mostly just got ahead of their inventory early, before the shadow API count got out of hand. Anyone starting now has an extra layer to think about, because the agent traffic shift isn’t going to slow down for them.

If you want an independent review of your ecommerce API security posture, Eknix works with CTOs and CISOs to find the gaps and put together a remediation plan that fits the engineering reality rather than the ideal one. We’re not going to hand you a 200-page report and disappear.