Why Is It Even Necessary?
If you've been building Sitecore sites that have things like "Load More" functionality then you perhaps are using calls to Controller API's to achieve this. If it's not written properly this could be exposing your data unintentionally. Let's say you have secured it though. The call itself is unnecessary and could be prevented entirely just by using a Cloudflare rule. This saves you bandwidth and processing power. If you haven't built it properly, it could result in an internal server error and too many of those can expose other issues.
How To Setup A Firewall Rule
Login to your Cloudflare account and select the appropriate site. Next, navigate to Security > WAF.
Select Create firewall rule.
First thing first. Give the rule a name. Could be as simple as "API Protection".
Next, let's design the request matching. We need to check two items in particular but of course you could get more specific if needed.
The first is if the path contains a value where our API's are stored. And lastly, checking if the hostname does not contain our hostname. If you're hosting multiple sites, as you can in Sitecore, it may be important to use does not contain. If not, you can use does not equal. It's important to note that Cloudflare currently cannot test does not contain on the hostname value.
Last step is to review the expression, select Block as the action to take and then click Deploy firewall rule.
After a period of time, we can review the statistics and ensure it's not blocking any traffic we want to get through. In a 24hr period you can see we've already stopped over 1.5k unnecessary requests from hitting our servers. Most of these requests weren't malicious but they were bots that we simply don't want accessing the content.
If you are taking advantage of Sitecore Form Builder and using Sitecore Forms on your site, then you'll already be familiar with the /formbuilder call. This likely would be another external call you'd want to prevent unnecessary and potentially malicious traffic to.
Not to mention, if you're using Coveo for Sitecore then /coveo/rest would be yet another path to protect unless you're going against Coveo's Cloud Platform directly.
