Attack scenariosAPI security

Other users' data through the API

An API returns a record by its identifier but does not check who is asking. Change the number in the request and you get someone else's data. A script then walks through every number.

The problem

A request such as GET /api/v1/orders/10452 returns an order. The client is authenticated, but the backend does not check that order 10452 belongs to that client, so a request for 10453 returns another customer's order. One endpoint among hundreds that forgets the ownership check is enough.

Each request is well-formed and authenticated. No WAF can know who owns order 10453: that knowledge lives in the application. The lasting fix is an ownership check in the code. What Mikiri WAF does is narrow what an attacker can send, stop the walk through the identifiers, and keep data from leaving in the response.

Attack request

GET /api/v1/orders/10453 HTTP/1.1
Host: api.example.com
Authorization: Bearer <token of another customer>
Accept: application/json

What Mikiri WAF detects and limits

• API firewall. Requests are validated against the OpenAPI specification. An undocumented endpoint, an unexpected parameter or an identifier that is not of the declared type is blocked, which closes the variants an attacker tries first, such as orders/10453;export or orders/all.
• The walk itself. A client that requests object after object far faster than an application does is caught by the same traffic analysis that detects web scraping. With a rate limit for the host, its address is blocked on the first detection.
• The response. In Enterprise, a response rule blocks an answer that contains data this endpoint should never return, such as a field with card or passport numbers. The client receives no data, and the record shows which endpoint leaked it.
• The records. Data masking replaces tokens and personal data in the request before the attack is stored, so the investigation does not spread the data further.

What you see in WMC

The records under the host in Attacks show the address, the token-masked request and the run of identifiers in the path. That run points to the endpoint that is missing its ownership check, which is the endpoint to fix first.