wallarm/api-firewall

The error "method or path not found in the OpenAPI" occurs when handling requests with the OPTIONS method

Closed this issue · 3 comments

0x566164696D commented

Typically, the OPTIONS method is not described in specifications. I suggest allowing OPTIONS requests to be skipped, even if they are not present in the specification.

Message example:
"level":"error","method":"OPTIONS","msg":"method or path not found in the OpenAPI specification","path":"/v1/some/path","request_id":"cf75d489-7ac2-490e-8587-4dbebeaa9f7c","response_length":"0","status_code":200

If you adhere to the belief that OPTIONS requests should be filtered, I suggest introducing a variable to control this behavior.
For example:

Normal mode - OPTIONS requests are ignored (default behavior)
Strict mode - OPTIONS requests must be described in the specification

afr1ka commented

We have added APIFW_PASS_OPTIONS env var for this case to the APIFW v0.6.12.

  • Introduced the ability to allow OPTIONS requests for endpoints specified in the OpenAPI, even if the OPTIONS method is not explicitly defined. This can be achieved using the APIFW_PASS_OPTIONS variable. The default value is false.
0x566164696D commented

Using this option only exacerbates CORS issues.

If the endpoint is specified in the specification, API-FIREWALL responds with:

HTTP/1.1 200 OK
Allow: OPTIONS, POST

However, no traffic reaches the backend, and there is no information about such a request in the API-FIREWALL logs.

The backend cannot set headers:
Access-Control-Allow-Origin
Access-Control-Allow-Headers
Access-Control-Allow-Credentials
Access-Control-Expose-Headers
And correct CORS functioning is impossible.

Expected behavior is to proxy the request to the backend, rather than receiving a 200 response from the API-FIREWALL itself.

afr1ka commented

Then it's a bug. Thanks. Will fix it in the APIFW v0.7.0.