Cloudflare specific advice needed

I only have the one Backdrop site, but several others including phpBB  sites.

All have suffered massively recently (within the last 6 months or so) from AI  bots, crawlers and search engines that have flooded my servers.

In an attempt to mitigate this I popped several behind Cloudflare, and so far, afteer weeks of chatting to the Cloudflare AI and their Support Team, I have all of them working nicely... except for my Backdrop site!

I'm seeking advice from someone who has successfully run their Backdrop site from behind Cloudflare. I'd like advice on what my config should be and what Cloudflare features are necessary (I am on a Free plan at the moment). I'd also like advice on what my htaccess and iptables rules should be.  Don't want much do I? :) 

I'm starting to distrust their AI's suggestions - their latest fix to the issue I was working on seems to have resulted in an Access Denied message - but only for one specific page address. Working together we determined it is most likely not a Cloudflare issue but a Backdrop issue.

Here's the very last piece of advice I got ...

After fixing (I thought) access issues to admin.toysnz.com yesterday - I find I am receiving an "access denied - you are not authorized to access this page" message when trying to access https://admin.toysnz.com/admin/reports/updates.

This page is within the admin section of the site where all updates, editing, etc occurs.

What is causing this?

################################################################
Cloudflare AI finally responded after 2 hours of back and forth:
----------------------------------------------------------------

Cloudflare is not blocking these requests. The "Access Denied" is being generated by Backdrop CMS itself.
What's happening in Backdrop CMS

The pattern you're describing is a classic Backdrop/Drupal permission issue:

   /admin/reports/updates → Access Denied (this route checks administer site configuration permission)
   /admin/reports/updates?check=1 → Works (the ?check=1 parameter triggers a different code path)
   /admin/reports/updates/list → Works (different access callback)
   Cron runs from dashboard → Logs show completion but no UI feedback

Likely causes

   Corrupted session — your admin session may have a stale CSRF token or permission cache. Try:
       Log out completely, clear cookies for admin.toysnz.com, log back in
       Or run drush cc all (or the Backdrop equivalent) from the server CLI

   Stale permission cache — Backdrop caches user permissions. After the server power cycle, the cache may be inconsistent:

   # From the Backdrop site root on your server
   drush cc all
   # Or if drush isn't available:
   drush cc perm

   Module issue — the Update Status module may have a corrupted state. Try:

   drush pm-disable update; drush pm-enable update

   Database session table — after the unexpected shutdown, the sessions table may have corrupted entries:

   TRUNCATE TABLE sessions;

   (This will log everyone out — you'll need to log back in.)

I pointed out I didn't have Drush and hadn't used it since switching to Backdrop CMS  - AI then suggested I install Bee then "bee cc all" or clear the caches from mysql. Since Bee doesn't seem to have any active sites using it - I wonder if that is a viable option?

the mysql command suggested is :

mysql -u [db_user] -p [db_name] -e "TRUNCATE TABLE cache; TRUNCATE TABLE cache_bootstrap; TRUNCATE TABLE cache_filter; TRUNCATE TABLE 

cache_menu; TRUNCATE TABLE cache_page; TRUNCATE TABLE cache_path;"