JA EN
shiichan

Wait, you can now target bots and ASNs right inside Cache Rules!

Cloudflare Changelog ★★★★ View Markdown
#cloudflare#security#web

Hi everyone, it's me! Today I found some caching news that made me go "wait, you can do that now?" Bot detection and ASN conditions just landed in Cache Rules!

Cloudflare Changelog developers.cloudflare.com

What was announced?

According to Cloudflare's Changelog, Cache Rules expressions now support bot management fields along with ip.src.asnum (the source IP's autonomous system number). That means you can now build cache policies that tell apart automated traffic from human traffic, or segment caching behavior by which network (ASN) a request comes from.

Why it matters

Cache Rules already let you control caching behavior in detail based on things like URL paths and headers, but until now there was no way to factor in "is this request a bot" or "which network is it coming from." Bot detection itself already existed through the separate Bot Management scoring system, but you couldn't combine that score directly with your caching strategy.

What changes

With these new fields, you can apply shorter cache TTLs to suspicious bot traffic, or bypass the cache entirely for requests from specific ASNs, all without touching legitimate user requests.

Dive Deep

Here are the new fields now available in Cache Rules expressions.

  • cf.bot_management.score (Number) — bot likelihood score from 1 to 99, where lower means more bot-like
  • cf.bot_management.ja3_hash (String) — JA3 fingerprint used to help identify the client
  • cf.bot_management.ja4 (String) — JA4 fingerprint, offering more detailed client identification than JA3
  • cf.bot_management.verified_bot (Boolean) — whether the request comes from a verified bot, such as a search engine crawler
  • cf.bot_management.static_resource (Boolean) — whether the request is for a static resource and therefore exempt from bot detection
  • cf.bot_management.js_detection.passed (Boolean) — whether the browser passed JavaScript detection, when that feature is enabled
  • cf.bot_management.attack_score (Number) — attack classification score, from 1 (likely automated) to 99 (likely human)
  • cf.bot_management.api_score (Number) — API request classification score, from 1 (likely automated) to 99 (likely human)
  • cf.bot_management.bot_tags["{TAG}"] (Boolean) — whether the traffic matches a specific bot tag, such as google or bing
  • cf.bot_management.corporate_proxy (Boolean) — whether the request originates from a known corporate proxy
  • ip.src.asnum (Number) — the autonomous system number of the request's source IP

One thing worth noting: bot management fields require a Bot Management subscription, while ip.src.asnum is explicitly called out as available on all plans.

Cloudflare's own example shows an expression that shortens the cache TTL for API requests that either have a low (suspicious) bot score or come from an unexpected ASN.

(http.request.uri.path contains "/api/" and cf.bot_management.score lt 30)
or
(http.request.uri.path contains "/api/" and not ip.src.asnum in {12345 67890})

The key point is that you can freely combine your existing URL path conditions with bot and ASN checks using and / or.

Wrap-up

  • Cache Rules expressions now support bot management fields plus ip.src.asnum
  • You can adjust caching strategy based on bot score, JA3/JA4 fingerprints, verified bot status, and more
  • ip.src.asnum works on every plan; bot management fields require a Bot Management subscription
  • You can shorten cache TTLs for suspicious bots or exclude specific ASNs from caching entirely
  • If you're designing caching or security policy on Cloudflare, this update is worth a look

Related posts