A curated set of tested Cloudflare firewall expressions, DDoS rules, bot controls and security headers that brings a Zero Trust posture to small websites on the free tier.
| Tool | buybitart/cloudflare-security-art — a free-plan Cloudflare security configuration guide built on Zero Trust WAF expressions |
| Category | Defensive web hardening / WAF rule collection |
| Primary Use | Protecting small websites, artist portfolios and self-hosted projects by pasting tested custom WAF expressions, L7 rate limits and security headers into the Cloudflare dashboard |
| Safe Use | Purely defensive configuration for sites you own or are formally authorized to administer; no offensive capability is included |
| Telemetry Note | As defensive infrastructure, its footprint appears in Cloudflare Security Events and firewall analytics as block actions, useful for measuring blocked bot volume |
cloudflare-security-art is not a traditional executable tool but a curated, copy-paste defensive configuration set distributed through GitHub under the MIT license, with roughly 224 stars and a topic footprint spanning cloudflare-waf-expression, cloudflare-firewall-rules, antibots, ddos-protection and security-headers. The repository, maintained by the BitcoinArt open-source project team, targets a genuinely under-served niche: small websites, artists, creators and self-hosted projects that sit behind Cloudflare's free plan and have neither the budget for enterprise security tooling nor the expertise to hand-write WAF expressions. Everything in the guide is designed to be applied through the standard Cloudflare dashboard at Security > WAF > Custom rules, which keeps the workflow entirely within Cloudflare's supported, documented configuration surface.
The core philosophy is explicitly Zero Trust: block all automated traffic by default, then carve out narrow allow-lists for verified, useful bots. This inverts the usual pattern of signature-based blocking, where you enumerate known-bad actors and hope the long tail misses you. Instead, the ruleset distrusts everything and grants passage only to search crawlers whose identity is corroborated by Cloudflare's cf.client.bot and cf.verified_bot_category fields, plus ACME challenges needed for certificate issuance. For defenders who have watched AI scrapers rotate user agents to evade naive blocklists, this default-deny posture is the more durable design, because it does not depend on correctly guessing the attacker's next alias.
The guide is structured as four sequential steps. STEP 1 covers WAF custom rules split into parts addressing bot parasites, AI crawlers, and other malicious request shapes. STEP 2 adds Layer-7 DDoS protection overrides and rate limiting to absorb floods. STEP 3 configures Cloudflare's bot management settings, and STEP 4 layers in recommended HTTP security headers. One immediately actionable and slightly counterintuitive recommendation stands out: the authors advise disabling Bot Fight Mode in the Security tab. Their reasoning is sound — because the custom rules already enforce stricter bot controls, leaving Bot Fight Mode enabled risks interfering with the deliberately allowed indexing bots such as googlebot, bing, slurp, duckduckbot and cloudflare, potentially harming legitimate search visibility.
The flagship expression in Part 1 is the most instructive artifact in the repository. It combines several detection heuristics into a single block rule: empty or malformed http.user_agent values that betray headless browsers and lazy scanners, string matches against automation frameworks like puppeteer, phantomjs, selenium, slimerjs, nightmare, casperjs and pyppeteer, Host headers leaking port suffixes like :80 or :443 typical of raw scanner probes, suspicious cf_use_ob cookie shapes, and a blanket block on HTTP/1.0 and HTTP/1.1 requests unless they come from verified search bots or hit /robots.txt or acme-challenge paths. The README claims this single rule stops roughly 90% of threats before they reach the origin, which is plausible for the low-and-slow automated noise that dominates traffic to small sites.
Part 2 addresses what the README calls AI bot parasites, and it is where the project's motivation becomes personal. The maintainers are artists, and the guide links to external discussions of AI companies scraping creative work. The expression enumerates a long list of AI crawler identifiers — gptbot, claudebot, perplexitybot, ccbot, bytespider, applebot, google-extended, anthropic, amazonbot and many others — alongside Cloudflare's own cf.verified_bot_category values AI Crawler and Other. Crucially, it also blocks any user agent containing bot, crawl, spider or scrapy originating from cloud provider ASNs such as 15169 and 8075 unless it is a verified search crawler, which catches scrapers that hide behind fake browser user agents.
Reading the expressions as engineering artifacts reveals competent use of the Cloudflare Ruleset Engine's expression language: lower() for case-insensitive matching, wildcard operators for fuzzy bot-name matching, ip.src.asnum sets for ASN-based reputation decisions, and careful boolean grouping so that allow-list exceptions (Google's inspection, site verification, AdWords and Lighthouse user agents) are nested inside the block conditions rather than appended as afterthoughts. This nesting pattern — deny broad, exempt narrow — is exactly how a senior operator would structure a default-deny rule, and studying it is educational even if you ultimately write your own expressions rather than copying these verbatim.
For authorized professionals, the practical value is twofold. First, it is a ready-made baseline for clients running small sites on Cloudflare free plans, where you cannot deploy paid WAF subscriptions and every custom rule counts against tight plan limits. Second, it functions as a reference of current AI crawler user agent strings, which is useful for defenders building their own edge rules on any platform, since the identifiers themselves are portable knowledge. Applying it is straightforward: clone or browse the repo, open Security > WAF > Custom rules in your own dashboard, and create rules from the provided expressions, following Cloudflare's documented custom-rule creation flow. Test in a staging or log-only phase before switching actions to Block, since aggressive HTTP-version filtering can surprise you with legitimate legacy clients.
Caveats worth flagging: user-agent string matching remains fundamentally spoofable, and the ruleset's real strength comes from pairing those strings with cf.client.bot verification, which relies on Cloudflare's authenticated bot validation rather than self-reported identity. The HTTP/1.x block, in particular, is aggressive enough that it should be validated against your actual audience before enforcement. The repository also leans heavily on the README as the delivery vehicle — it is a guide, not a Terraform module or API-driven deployer — so changes require manual re-pasting into the dashboard. For teams wanting infrastructure-as-code, translating these expressions into Cloudflare's rulesets API would be the natural next step.
There is a benign sponsorship angle: the authors, one of whom is credited in Apple's security acknowledgements, ask for GitHub Sponsors support to keep testing and updating the rules. That transparency is fine, but it also signals the maintenance model — updates are likely episodic and tied to the maintainers' own site protection needs, so verify the AI crawler list is current before deploying. From a telemetry perspective, everything here is purely defensive: its effects show up in your own Cloudflare Security Events and firewall analytics as block counts, giving you a measurable before-and-after picture of automated traffic reduction. As a free, tested, documentation-first hardening baseline for the long tail of small websites, cloudflare-security-art earns its place in the defensive toolkit.
buybitart/cloudflare-security-art.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.