Since you don't want the OPTIONS request to pass through to the backend API, there are two things needed:
A RouteRule to a null target with condition for the OPTIONS request. Notice there is no TargetEndpoint specified.
<RouteRule name="NoRoute"> <Condition>request.verb == "OPTIONS"</Condition> </RouteRule>
A custom flow in the ProxyEndpoint to handle the CORS response. Since the new RouteRule sends the message to a null Target (echoes request back to client), the message will not route to the 'default' TargetEndpoint where the CORS policy currently is defined.
An updated version of your ProxyEndpoint would look like the below:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
<Description/>
<Flows>
<Flow name="OptionsPreFlight">
<Request/>
<Response>
<Step>
<Name>Add-CORS</Name>
</Step>
</Response>
<Condition>request.verb == "OPTIONS"</Condition>
</Flow>
</Flows>
<PreFlow name="PreFlow">
<Request/>
<Response/>
</PreFlow>
<HTTPProxyConnection>
<BasePath>/v1/cnc</BasePath>
<VirtualHost>default</VirtualHost>
<VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
<RouteRule name="NoRoute">
<Condition>request.verb == "OPTIONS"</Condition>
</RouteRule>
<RouteRule name="default">
<TargetEndpoint>default</TargetEndpoint>
</RouteRule>
<PostFlow name="PostFlow">
<Request/>
<Response/>
</PostFlow>
</ProxyEndpoint>
NOTE: The RouteRules are evaluated in the order specified in the ProxyEnpoint configuration. You should always have the default (no condition) Route at the end. Otherwise, if at the top, it will always match and never evaluate the other Route possibilities.