A bit of theory at first:
"Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.(https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF))"
Viewstate in ASP.NET actually complicates these attacks making manipulation more complicated. If ViewState is enabled, you cannot send tampered POST requests to an ASP.NET application because validation of ViewState fails.
I suggest you take a look at explanation of our protection implementation at:
Shortly speaking we are protecting the requests by validating each post to the site by a cookie and hidden field security tokens. Cookie stored with user is validated against page hidden field on each post request.
Currently we validated all post requests coming to any page that inherits from abstract CMSPage.
Since search is a post action (you are posting search text to page), this causes protection to trigger. Usual case is that the post request does not contain the cookie (e.g. cookie is not created for public user), or there is another page reload or other action, that would break tokens pairing.
First and usual case are cookie issues and there was a hotfix for this that ensured that CSRF cookie is an system cookie (9.0.44). Otherwise you can try inspecting request headers, if cookie value is part of the request and maybe check network tab in browser console to see how the is the request handled(there might be network interference, redirect...)
One note for Trevor, unfortunately we can not control posts from 3rd parties, nor can we force them to send us some headers or other validation means so this creates a slight issue with situation like yours. Since v10.03 there is a workaround to disable CSRF on page level, but is available only with changes to page template:
HTTPHandlers are not part of this protection mechanisms so in general they are best to handle posts from 3rd parties (unfortunately, it would be hard to set in your specific case with CDN)