API Bugs

When an API endpoint receives invalid input and returns HTTP 200 OK instead of an appropriate 4xx status code, the client cannot distinguish a successful operation from a failed one by checking the HTTP status alone. Error information is buried in the response body, breaking clients that rely on standard HTTP semantics.

An API endpoint declares a field as required in its documentation or schema but accepts a request where that field is absent, null, or an empty string, and proceeds as if the operation succeeded. Records are created or updated with missing data, silently violating the intended data model.

The POST /api/search endpoint accepts an unlimited number of requests per second from the same client. There is no per-client throttle and no 429 Too Many Requests response. A single client can saturate the server by sending requests in a tight loop without any backpressure.

When POST /api/orders receives an invalid payload, an unhandled exception causes the server to return an HTTP 500 response body containing a full stack trace with internal file paths, database table names, and query text. This information disclosure allows an attacker to map the application's internal structure and identify further attack targets.