Protection

A firewall in front of your API does not know your API. It has to learn what normal traffic looks like, be tuned when it gets that wrong, and it still cannot tell you whether a request was one this particular caller was allowed to make.

Protection works from things that are already known: the contract you published, and the identity of the caller. It needs no learning period because the contract is the definition of valid.

Two Layers

What the contract permits

Your OpenAPI specification already declares what each operation accepts — the content type, which fields are required, each property’s type and format, and its length bounds. Those declarations become an enforced policy on the operation.

A request is checked against them before it reaches your service: valid JSON, the right shape, required fields present and not null, and each property conforming to its declared type, format and bounds. merge-patch requests are understood as partial by design rather than treated as missing required fields.

This is a positive model — the permitted set is defined, and anything outside it is invalid rather than suspicious. There is nothing to train and nothing to tune, and it is correct from the first request, because it derives from the contract rather than from observed traffic.

What no request should contain

Alongside contract validation, requests are scanned for the classes of payload that are never legitimate regardless of the contract:

Rule	Guards against
SQL injection	Statement fragments smuggled through parameters
Cross-site scripting	Script payloads intended for a downstream browser
Path traversal	Attempts to escape an intended path
Command injection	Shell metacharacters reaching an executing context
LDAP injection	Filter manipulation in directory queries

Rules and scan targets — headers, query, body — are configured per operation, so a file-upload endpoint and a search endpoint need not be scanned identically. Headers known to carry attacker-controlled values are scanned; the rest are not, which keeps the work proportionate.

Pattern evaluation fails closed: if a rule cannot complete in time, the request is rejected rather than admitted unchecked.

Why It Runs After Authentication

Both layers are better for knowing who is calling.

The contract policy is per operation, and which operations a caller may reach at all is already settled by security. So validation applies to a request that has been established as one this caller was entitled to make — rather than to anonymous traffic whose intent can only be guessed at.

And every violation is recorded against an identity rather than an address. A pattern match from a known subscriber is a different event from the same match by an unauthenticated stranger, and only the first is actionable. Those events feed Risk Management, where severity escalates with volume.

An anonymous request never reaches this stage. It is rejected at security, which is both cheaper and more informative than inspecting the payload of a caller who was never getting through.