David Launen

@Tetiana Gron (I can't figure out how to reference a user from this UI), for our use case, we configured CloudFlare to use a managed challenge for all requests for a specific action URL, for you it could be something like:

https://*.zendesk.com/requests//satisfaction/new/*

IMO, since you only really want humans to access this URL, avoid using the bot score and just have CloudFlare run it's challenge on all requests, which is typically a non intrusive JavaScript challenge where user just needs to wait a couple of seconds.

We ran into this exact issue when sending one time use URLs to certain users for initiating password resets, after we applied this method, we have never had a report again.

I use this approach on areas within our applications where you want only humans to access, i.e. initiating a password reset, etc.

Interesting, has this completely rolled out? Were still seeing the bad results being triggered without user intervention as of just yesterday.

This is actually quite easy to solve, we do it for similar links on our application. However, it requires Zendesk to run a bot check on the URL, we use a simple rule on CloudFlare, when the AV attempts to scan the URL CloudFlare checks the request and identifies it's not human and therefore does not pass the request to the application, and hence no false positives.

Works for us, but since Zendesk controls this URL, they need to implement this simple solution.