CORS Policy only works with public APIs

[volkflo]

Apiman Version

3

Apiman Manager Distro

Tomcat

Apiman Gateway Distro

Vert.x

Java Version

11 LTS

Operating System

Linux

Are you running Apiman in a container, or on an orchestration platform?

Docker Compose

Describe the bug

It seems that the CORS policy only works 100% correctly if the API is public.

If the API is private the x-api-key is checked at first stage before the policy chain is loaded and executed.
However, the browser will send for all non-simple methods a preflight (OPTIONS) request.

The problem is that the browser only attaches the minimum headers to this request.
So our custom x-api-key header is never attached to this OPTIONS request made by the browser.

In that case the OPTIONS request will be blocked ("API not public") and we are never able to get into the policy chain to execute the CORS policy. So the CORS request is blocked before it can reach the CORS policy.

This seems to be as per design as the preflight request only contains these headers:

Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: origin, x-requested-with
Origin: https://foo.bar.org

See infos:

• https://stackoverflow.com/questions/13994507/how-do-you-send-a-custom-header-in-a-cors-preflight-options-request
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS
• https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request

Expected behaviour

TBH, I am not totally sure what would be the best way to handle this situation.
I guess the gateway should handle OPTION requests differently than a "normal" requests, but I am not sure if this is a good idea. But that would require some deeper modifications.

Actual behaviour

No response

How to Reproduce

1. Set up a private API, and attach the CORS Policy (the configuration can be a minimum, just add * for allowed origins)
2. Try to send an options request (without x-api-key as the browser would sent it)

Relevant log output

No response

Anything else?

No response