Overview
The Cloud APIM Threat Protection Suite is an Otoroshi admin extension that adds threat protection to the gateway: a web application firewall speaking ModSecurity SecLang with the OWASP Core Rule Set embedded, ip reputation fed by threat intelligence feeds, CrowdSec and the public routing table, bot and AI-crawler control with an embedded challenge, behavioural detection of what no single request shows, response protection for what leaves the backend, and API security built on the API's own OpenAPI contract — with a decision fabric that makes all those detectors act as one, and Threat Studio, one console to arm and watch them.
It runs entirely on the JVM, inside the Otoroshi process. There is no native library to install, no sidecar, and no second daemon to operate.
Why it sits in the gateway
A standalone WAF sees bytes. This one sits inside an API gateway, which means it already knows the route, the consumer, the apikey and the backend response — and it reuses Otoroshi's entities, admin API, analytics exporters and vault references instead of inventing its own.
The decision fabric
Detectors do not each decide on their own. They contribute signals to a shared score, and one
component turns that score into one graded action — log, challenge, throttle, tarpit, deny
or ban — with cluster-wide bans, a cross-request memory, incident correlation and alerting behind
it.
That arrangement is what makes the rest deployable: a false positive costs a log line at score 45 instead of a broken customer at 403. It is also why there is a single preset plugin: the chain is position-sensitive, and the preset makes the order structural rather than documented.
→ How the fabric works · The preset plugin
The detection modules
WAF
A JVM implementation of the ModSecurity SecLang rule language, with the OWASP CRS v4 bundled. It inspects the request line, headers, cookies, arguments and body, and optionally the backend response.
The engine passes 100% of the CRS v4 regression suite.
IP reputation
Scores the caller before the request is parsed, from three kinds of source: threat feeds (public blocklists, cloud provider ranges, Tor exit nodes — fourteen curated ones in the catalog), CrowdSec decisions streamed from a Local API, and ASN classification from the public routing table.
Lookups hit a sorted in-memory range index; nothing blocking happens on the request path.
Bots and challenges
Twenty-seven known crawler signatures, verified by forward-confirmed reverse DNS rather than
trusted — a forged Googlebot becomes a demonstrated lie. Per-category rules over AI, search, SEO
and monitoring crawlers, with a matching robots.txt generated from them, plus honeypot paths
that catch a scanner with almost no false-positive risk.
The challenge action is served by an embedded proof of work — no third party, no external
call — or by a vendor widget, with European providers among the presets.
Behaviour and abuse
Some attacks leave nothing a rule engine can see: credential stuffing is well-formed HTTP with a wrong password, and a scraper reading the whole catalogue never sends a malformed request. Fail2ban counts failed responses per caller and bans the repeat offenders cluster-wide; the login guard sees credential stuffing, password spraying and likely account takeovers; the traffic guard learns each route's usual traffic and scores a surge away from it; the object guard sees enumeration and walks through identifiers per consumer, and budgets the distinct objects each one reads.
→ Fail2ban · Login guard · Traffic guard · Object guard
Uploads and responses
Every uploaded file is judged by its bytes rather than its name — disguised scripts and executables, polyglots, archive bombs, zip slips — and can go to a clamd or ICAP antivirus before the upload completes. On the way back, the error leakage guard replaces stack traces and debug pages with a neutral error, and the sensitive data guard masks card numbers, IBANs, national identifiers and secrets in place, each checked the way its issuer would.
API security
What only a gateway holding the API's contract can do. Every request is checked against the route's OpenAPI 3.0 or 3.1 contract — paths, methods, parameters and bodies — monitored or enforced. What the contract sees becomes reports: endpoints nobody documented that the backend still answers, operations nobody calls any more, fields the backend returns that the contract never mentions, and which credential each endpoint actually checks.
Where each piece runs
| Stage | What runs | Cost |
|---|---|---|
| Before routing | Honeypots and the global validators — covers traffic matching no route at all | A path lookup |
| Access validation | Standing bans, bot verification, IP reputation, fail2ban's own bans, the traffic guard | Node-local map reads and a binary search over merged ranges |
| Request | The API contract, SecLang phases 1, 2 and 5 — URI, headers, cookies, args, body — the upload, login and object guards, then the threat response acts on the score | Proportional to the ruleset and the body size |
| Response | SecLang phases 3, 4 and 5; failed statuses and logins counted; the error leakage and sensitive data guards | Only what is switched on |
The cheap checks run first on purpose: a caller already known to be hostile is refused for the price of a map lookup, without the rule engine ever seeing the request.
What ships in the box
| Entities | Fourteen: WafConfig, WafRuleset, ThreatPolicy, ThreatFeed, AsnDatabase, GeoDatabase, CrowdSecBouncer, BotPolicy, ChallengeProvider, HoneypotPolicy, AlertRule, MalwareScanner, RuleFeed, ApiContract — full CRUD, admin API, import/export, Kubernetes CRDs |
| Route plugins | WAF · IP reputation · Threat gate · Threat response · Bot guard · Fail2ban · Traffic guard · API contract · Upload guard · Login guard · Object guard · Error leakage guard · Sensitive data guard · the preset that lays them down in the right order, and a global preset that lays it over a fleet |
| Global plugins | Three incoming-request validators — honeypot, WAF and IP reputation — evaluated before routing (see the note) |
| Threat Studio | One console organised by workspace: what each set of routes runs, what it is armed to do, its traffic, its incidents and its APIs |
| Admin UI | One Threat Protection section, opening on an overview that says what to do next on this install: every entity above, and a Bans & incidents console with evidence, an allowlist and an incident state a team can work |
| Analytics | Nine event types, routable through any Otoroshi data exporter — including one normalised ECS-shaped CloudApimSecurityEvent, and its OCSF form for a SIEM |
| Alerting | Alert rules: one message per attacker, ban or burst to Slack, Teams, PagerDuty or a webhook |
| Rule feeds | Signed rule packs, checked by the local engine before they are installed |
| Console | A route posture view that needs nothing, plus thirty-five analytics queries and a seeded dashboard when the user-analytics exporter is configured |
| Tuning | A false-positive assistant that turns an observed match into an exclusion, having run it against your configuration first, and a learning mode that measures a window and says what arming would cost |
Design rules
These hold everywhere in the extension, and they explain most of the API shape:
- Nothing blocking on the request path. Feed refreshes, DNS lookups and CrowdSec syncs run on a scheduler. Lookups touch only in-memory structures.
- A failed refresh never removes protection. If a feed stops responding, the previous snapshot keeps serving and the error is surfaced in the UI — silently losing coverage is worse than a visible failure.
- Every external dependency fails open, and the fail-open decision is itself an event, so a degraded WAF is visible rather than discovered later.
- Monitoring mode is the default posture. Every module can score and report without denying, so you can measure the false-positive cost before arming anything.
Next
- Install — download the jar, enable the extension
- What a complete deployment needs — a redis for shared state, a postgres for analytics, and which features are silently degraded without them
- Quickstart — a protected route in about ten minutes
- Protecting a route, end to end — the long version: every entity, in the order that works, and how to arm it without breaking traffic
- Threat Studio — the console: workspaces, arming, analytics, incidents, APIs
- Security console — reading the events back, and which routes are actually protected
- Tuning — how to get from monitoring to blocking without breaking traffic
- Tuning assistant — the same work, from the admin UI, with every exclusion proven before it is saved
- Learning mode — measure a window, then decide about arming with evidence instead of nerve