Additional requirements :
- PHP 7.2+
- XenForo CAPTCHA enabled.
XF Bot Guard
Challenge suspicious bots before they scrape your forum.
XF Bot Guard is a XenForo-native anti-scraping and bot challenge layer for public forums. It identifies risky visitor behaviour, builds reputation from hashed browser/session/IP signals, and challenges suspicious traffic using XenForo’s own CAPTCHA system.
It is built for forum owners who want a practical application-layer defence against anonymous crawlers, content scrapers, aggressive bots, repeated automated visitors, and browser-like traffic that basic blocks do not catch.
This is not a “CAPTCHA everyone” add-on. XF Bot Guard watches first, scores behaviour, gives normal browsers a short chance to identify themselves, and challenges visitors when their risk profile reaches your configured threshold.
What it protects against
XF Bot Guard combines local browser fingerprint collection, collector proof validation, browser coherence checks, request velocity, route awareness, IP/session/fingerprint reputation, CAPTCHA history, official crawler IP verification, bootstrap history protection, and XenForo route context.
It is designed to detect and challenge traffic showing signs such as:
Built for XenForo
XF Bot Guard runs inside XenForo. It understands forum routes, request methods, sessions, users, content context, CAPTCHA state, online activity, XenForo cache configuration, and XenForo’s normal page flow.
It does not require a proxy challenge page, external SaaS bot platform, paid fingerprinting service, or third-party XenForo add-on.
Native XenForo CAPTCHA challenge
XF Bot Guard uses the CAPTCHA provider configured in XenForo.
That keeps the challenge experience native to your forum. Configure CAPTCHA in XenForo first, then enable XF Bot Guard.
After a visitor completes CAPTCHA, Bot Guard temporarily trusts that visitor for the configured trust duration and returns them to the originally requested safe page where possible. Unsafe return targets are rejected automatically.
Safe challenge behaviour
XF Bot Guard challenges safe public page views. Other request types can still be observed, counted, and used for reputation where appropriate, but the CAPTCHA redirect is kept away from sensitive flows.
This protects forum browsing without breaking forms, AJAX, API requests, login/register flows, payment callbacks, webhook-style paths, static assets, or XenForo CAPTCHA routes.
In practical terms:
You decide what Bot Guard protects:
Explainable risk scoring
XF Bot Guard uses an explainable risk score. You can see why a visitor was allowed, observed, challenged, trusted, or failed.
Risk can increase from missing fingerprint data, missing cookie continuity, invalid collector proof, browser coherence contradictions, automation markers, changing IP/fingerprint relationships, repeated bootstrap-only behaviour without browser collection, route probing, scraping-sensitive route families, high velocity, and CAPTCHA failures.
Risk can decrease for logged-in users, staff, recently verified visitors, and trusted known crawler header requests when that feature is safely enabled.
Official crawler/fetcher IP matches are handled before risk scoring as a direct allow decision, because official provider-published IP ranges are the trust source for that feature.
You control the challenge threshold. Suggested starting points are shown in the options.
Browser collector and proof validation
XF Bot Guard includes a local browser collector using the bundled FingerprintJS library.
The collector posts a hashed visitor signal and lightweight browser continuity/coherence metadata back to XenForo. It also uses short-lived server-issued proof so collector submissions are tied to the current page, session, and timing window.
Invalid, expired, reused, missing, or mismatched proof is not accepted as trusted browser evidence. It is handled safely and contributes to scoring/logging.
Operational counters without audit-log bloat
XF Bot Guard keeps short-window operational counters separately from retained audit logs.
That matters on real forums. Scoring and rate-limit decisions continue to use recent activity counters even when routine low-value allow/skip rows are not written to the event log.
Bootstrap history protection also uses these counters. This means repeated bootstrap-only access can still be detected even when routine bootstrap allow rows are not retained as audit events.
When XenForo cache is configured, Bot Guard uses read-through and write-through cache for counter buckets to reduce repeated database reads. The database remains authoritative. If cache is unavailable, Bot Guard uses the database path.
Security-relevant events remain available for review when audit logging is enabled, while normal safe browsing does not have to create a log row for every ordinary request.
Event log and decision visibility
The admin event log shows Bot Guard decisions and the reasons behind them.
Logged events include:
Admin health/status page
XF Bot Guard includes a health/status page in the admin control panel.
It checks the add-on toggle, JavaScript collector status, XenForo CAPTCHA configuration, PAGE_CONTAINER template modification, bundled JavaScript assets, audit logging, low-value logging, event/session/visitor retention, counter retention, official crawler source/range import status, known crawler header trust, origin-lockdown acknowledgement, event/counter table size, and hash-secret/globalSalt availability.
Current visitors visibility
Bot Guard verification routes appear clearly in XenForo’s Current visitors / Members online area.
Challenged visitors can also be separated into a Bot Guard “Bots” count, so they do not inflate normal online visitor totals while they are still pending verification.
The activity text does not expose return URLs, visitor hashes, IP hashes, fingerprint IDs, collector proof values, or challenge metadata.
Known crawler support
XF Bot Guard supports two crawler trust paths.
Official source support includes Google crawler/fetcher feeds, Bingbot, Applebot, and DuckDuckBot. The health page shows whether the official source rows and imported IP ranges are available.
Privacy-conscious storage
XF Bot Guard is designed not to store raw IP addresses or raw browser fingerprint IDs in its own tables.
It stores hashed identifiers for reputation and anti-abuse decisions. Browser fingerprint collection runs locally with the bundled FingerprintJS library. No external fingerprinting account is required.
Bot Guard stores compact anti-abuse metadata and browser-coherence signals. It does not store raw FingerprintJS component entropy by default, and raw collector proof values are not stored in the event log.
Site owners should update their privacy policy because the add-on performs anti-abuse fingerprinting, behavioural monitoring, and challenge decisions.
No external service account required
XF Bot Guard does not require:
Works alongside Cloudflare and server security
Cloudflare, WAF rules, server firewall rules, and rate limits can block traffic before it reaches XenForo.
XF Bot Guard works at the XenForo layer, where it can see forum routes, sessions, cookies, CAPTCHA trust, collector state, content context, and hashed visitor reputation.
Use it as an additional XenForo-native layer, not as a replacement for good server/CDN security.
What this is not
XF Bot Guard is not a firewall, reverse proxy, CDN, WAF, nginx rule, Apache rule, LiteSpeed rule, or iptables block.
It does not stop requests before they reach PHP.
A sophisticated scraper using a real browser, stable cookies, JavaScript execution, careful timing, and CAPTCHA solving can still pass. XF Bot Guard is built to stop, slow, and expose unwanted automated visitors by forcing risky traffic through an explainable XenForo challenge flow.
Requirements
Proprietary freeware.
This resource is free to use, but it is not open source. Redistribution, resale, sublicensing, publishing modified versions, or removing copyright/license notices is not permitted without written permission from the developer.
Summary
XF Bot Guard gives XenForo forums a native, stable, configurable, explainable challenge layer for suspicious bots and scrapers.
It watches behaviour, validates browser evidence, verifies official crawler/fetcher IP ranges, tracks repeated bootstrap-only access, builds reputation, keeps operational counters separate from audit logs, uses XenForo cache for counter reads when configured, provides clear admin visibility, and challenges risky visitors before they can continue freely browsing protected content.
Télécharger V1.0.3 :
New checks include:
High-confidence automation indicators, such as explicit WebDriver or headless browser evidence, can still contribute strongly to the risk score.
Collected metadata is limited to compact browser and request-coherence signals used for bot-risk evaluation.
A successful CAPTCHA now properly honours the configured trust duration. During the active trust window, the visitor is allowed through without being challenged again.
CAPTCHA trust-window allows are also logged clearly, making it easier to understand when a visitor was allowed because they had recently completed verification.
XF Bot Guard now preserves the originally requested safe URL through the challenge flow and returns the visitor to that page after successful verification.
This includes first-visit and new-session challenge flows, such as visitors opening a protected thread or forum page before they already have an established forum session.
Unsafe return targets are rejected automatically, including external URLs, Bot Guard routes, login/logout/register routes, API routes, admin/install paths, webhook-style paths, payment callback-style paths, and malformed values.
If the original return URL is missing or unsafe, XF Bot Guard safely falls back to the forum index as before.
Previously, known crawler detection reduced the risk score but could still result in a challenge if the request scored highly enough for other reasons.
XF Bot Guard now still calculates and logs the score for observability, but verified known crawler requests can be allowed at the decision layer rather than being challenged unnecessarily.
This keeps crawler handling visible in the event log while making the trusted crawler setting behave more consistently.
This makes collector submissions harder to replay or synthesize independently from a genuine page load.
Collector proof is validated before browser metadata is accepted as trusted collector evidence. Invalid, expired, reused, missing, or mismatched collector proof is handled safely and logged for observability.
This hardening is designed to fail safely without breaking normal page loads.
Examples include:
Examples include:
XF Bot Guard now uses the configured Bot Guard hash secret where available, or XenForo’s global salt where available.
If neither is available, XF Bot Guard avoids generating predictable hashes, fails open for visitor access where appropriate, and logs the configuration issue so the administrator can correct it.
Cookies now set SameSite=Lax, use Secure when served over HTTPS, and only allow JavaScript access where the browser collector genuinely requires it.
This improves cookie behaviour consistency across modern browsers while preserving compatibility with the add-on’s supported XenForo versions.
Visitors on the verification flow should now show generic verification-related activity rather than appearing as an unknown or unrecognised route.
The displayed activity text does not expose sensitive return URLs, visitor hashes, IP hashes, fingerprint IDs, nonce values, or challenge metadata.
New or improved event visibility includes:
The harness covers key behaviours such as CAPTCHA trust overrides, known crawler overrides, return URL validation, unsafe return rejection, Bot Guard self-route rejection, collector proof validation, metadata sanitisation, entropy scoring fixtures, route classification, excluded paths/routes/methods, and Bot Guard online activity support.
This internal tooling complements the usual manual XenForo 2.1, 2.2, and 2.3 compatibility testing.
Administrators using trusted crawler handling should ensure their proxy/header environment is appropriately controlled, as trusted crawler decisions depend on request headers being reliable.
This release focuses on making the 1.0.x foundation safer, quieter, faster, and easier to monitor on real production XenForo forums. The core protection model remains the same, but the internal behaviour has been hardened for serious forums running conservative settings.
The main goals of this release are:
Earlier 1.0.x versions established the core challenge flow, browser collector, trusted crawler handling, scoring model, and verification behaviour. This release hardens that foundation for broader production use.
The add-on is still disabled by default after installation, and the default operating mode remains conservative.
Previously, some scoring and rate-limit decisions relied heavily on recent rows in the audit event table. That made it harder to safely reduce noisy low-value logging, because suppressing those rows could also affect scoring visibility.
In 1.0.6, short-window operational counters are stored independently and used for decisions such as recent request activity, recent error-route activity, recent sensitive-route activity, and CAPTCHA failure rate limiting.
This means XF Bot Guard can now reduce audit log pressure without weakening the scoring and rate-limit behaviour that depends on recent activity.
By default, XF Bot Guard no longer writes ordinary low-value allow/skip rows for every normal safe guest request.
This helps prevent busy forums from filling the Bot Guard event table with endless routine browsing activity while still retaining useful security events.
Important events continue to be logged when audit logging is enabled, including:
This allows administrators to keep a small sample of otherwise low-value allow rows for visibility without logging every normal safe request.
For example, a busy forum can keep audit logging enabled for security events while sampling only a small percentage of routine allow decisions.
The default sample rate is 0%.
XF Bot Guard still tracks useful relationship signals such as visitor/IP relationships, visitor country/ASN variation, and IP/fingerprint relationships, but these are now refreshed periodically instead of repeatedly queried on every scored request.
This reduces database pressure on normal repeat guest browsing while preserving the same general scoring signals.
Counter rows are short-lived and are pruned after approximately 48 hours.
This keeps the counter table focused on recent operational decisions and prevents it from growing indefinitely.
Existing event, visitor, session, fingerprint/IP, and online challenge cleanup behaviour remains in place.
The health page provides clear OK, warning, and error rows for important configuration and runtime checks, including:
Trusted crawler decisions depend on crawler-related request headers being reliable. Those headers are only trustworthy if visitors cannot bypass the proxy/CDN layer and hit the origin server directly while spoofing headers.
If known crawler trust is enabled but origin lockdown has not been acknowledged, XF Bot Guard now shows a warning in the health page.
This does not block operation. It is an admin safety warning only.
This may include decision time, risk-data time, scoring time, counter time, and whether full scoring was run.
This is intended to help diagnose production behaviour without exposing debug output on public pages.
In particular:
This table stores short-lived operational counters used for scoring and rate-limit decisions.
The table is maintained automatically by XF Bot Guard and cleaned up through the existing cleanup process.
Administrators using trusted crawler handling should also confirm their proxy/CDN and origin-server setup prevents direct origin access before acknowledging origin lockdown.
Administrators who previously relied on very verbose allow-row logging can re-enable low-value event logging or configure allow-event sampling in the Bot Guard options.
Administrations should also review the new Bot Guard health/status page, linked to from the logs page.
It reduces routine event log growth, moves scoring counters out of the audit log, lowers hot-path database pressure, adds better admin visibility, improves retention behaviour, and keeps the default configuration conservative.
This is the recommended stable foundation for production XenForo forums using XF Bot Guard.
Télécharger V1.0.6 :
Télécharger V1.1.1 :
Télécharger V1.1.5 :
Télécharger V1.2.2 :
Télécharger V1.2.3 :
Télécharger V1.3.2 :
- PHP 7.2+
- XenForo CAPTCHA enabled.
XF Bot Guard
Challenge suspicious bots before they scrape your forum.
XF Bot Guard is a XenForo-native anti-scraping and bot challenge layer for public forums. It identifies risky visitor behaviour, builds reputation from hashed browser/session/IP signals, and challenges suspicious traffic using XenForo’s own CAPTCHA system.
It is built for forum owners who want a practical application-layer defence against anonymous crawlers, content scrapers, aggressive bots, repeated automated visitors, and browser-like traffic that basic blocks do not catch.
This is not a “CAPTCHA everyone” add-on. XF Bot Guard watches first, scores behaviour, gives normal browsers a short chance to identify themselves, and challenges visitors when their risk profile reaches your configured threshold.
What it protects against
XF Bot Guard combines local browser fingerprint collection, collector proof validation, browser coherence checks, request velocity, route awareness, IP/session/fingerprint reputation, CAPTCHA history, official crawler IP verification, bootstrap history protection, and XenForo route context.
It is designed to detect and challenge traffic showing signs such as:
- No JavaScript or fingerprint signal
- Missing or inconsistent Bot Guard cookies
- No browser proof signals at all
- Missing, expired, invalid, reused, or mismatched collector proof
- Repeated bootstrap-only access without successful browser collection
- Browser identity, platform, screen, language, timezone, or request-header contradictions
- WebDriver, headless browser, automation, or browser-control artefacts
- Suspiciously thin rendering/resource-loading profiles
- One browser-like identity appearing across multiple IPs
- One IP appearing with many browser identities
- Unexpected User-Agent changes
- Country/ASN changes where trusted proxy headers provide that data
- Unusual request velocity
- Repeated sensitive-route or error-route hits
- Search, find-new, listing, member, profile, and deep-pagination patterns commonly associated with scraping
- Fake crawler user-agents from IPs that do not match official crawler/fetcher ranges
- Recent CAPTCHA failure
Built for XenForo
XF Bot Guard runs inside XenForo. It understands forum routes, request methods, sessions, users, content context, CAPTCHA state, online activity, XenForo cache configuration, and XenForo’s normal page flow.
It does not require a proxy challenge page, external SaaS bot platform, paid fingerprinting service, or third-party XenForo add-on.
Native XenForo CAPTCHA challenge
XF Bot Guard uses the CAPTCHA provider configured in XenForo.
That keeps the challenge experience native to your forum. Configure CAPTCHA in XenForo first, then enable XF Bot Guard.
After a visitor completes CAPTCHA, Bot Guard temporarily trusts that visitor for the configured trust duration and returns them to the originally requested safe page where possible. Unsafe return targets are rejected automatically.
Safe challenge behaviour
XF Bot Guard challenges safe public page views. Other request types can still be observed, counted, and used for reputation where appropriate, but the CAPTCHA redirect is kept away from sensitive flows.
This protects forum browsing without breaking forms, AJAX, API requests, login/register flows, payment callbacks, webhook-style paths, static assets, or XenForo CAPTCHA routes.
In practical terms:
- Suspicious behaviour can be monitored across safe request contexts.
- CAPTCHA challenges occur on safe primary page navigation requests.
- Visitors who pass CAPTCHA are trusted for the configured trust window.
- Visitors who fail or cannot complete CAPTCHA cannot continue freely through protected pages.
- Successful visitors are returned to the original safe page where possible.
You decide what Bot Guard protects:
- All public pages
- Threads only
- Threads plus forums
- Selected content types
- Selected route prefixes
- Custom path/route lists
- Guests only
- Guests plus registered users
- Guests plus registered users except staff
- Excluded user groups
- Excluded IPs/CIDRs
Explainable risk scoring
XF Bot Guard uses an explainable risk score. You can see why a visitor was allowed, observed, challenged, trusted, or failed.
Risk can increase from missing fingerprint data, missing cookie continuity, invalid collector proof, browser coherence contradictions, automation markers, changing IP/fingerprint relationships, repeated bootstrap-only behaviour without browser collection, route probing, scraping-sensitive route families, high velocity, and CAPTCHA failures.
Risk can decrease for logged-in users, staff, recently verified visitors, and trusted known crawler header requests when that feature is safely enabled.
Official crawler/fetcher IP matches are handled before risk scoring as a direct allow decision, because official provider-published IP ranges are the trust source for that feature.
You control the challenge threshold. Suggested starting points are shown in the options.
Browser collector and proof validation
XF Bot Guard includes a local browser collector using the bundled FingerprintJS library.
The collector posts a hashed visitor signal and lightweight browser continuity/coherence metadata back to XenForo. It also uses short-lived server-issued proof so collector submissions are tied to the current page, session, and timing window.
Invalid, expired, reused, missing, or mismatched proof is not accepted as trusted browser evidence. It is handled safely and contributes to scoring/logging.
Operational counters without audit-log bloat
XF Bot Guard keeps short-window operational counters separately from retained audit logs.
That matters on real forums. Scoring and rate-limit decisions continue to use recent activity counters even when routine low-value allow/skip rows are not written to the event log.
Bootstrap history protection also uses these counters. This means repeated bootstrap-only access can still be detected even when routine bootstrap allow rows are not retained as audit events.
When XenForo cache is configured, Bot Guard uses read-through and write-through cache for counter buckets to reduce repeated database reads. The database remains authoritative. If cache is unavailable, Bot Guard uses the database path.
Security-relevant events remain available for review when audit logging is enabled, while normal safe browsing does not have to create a log row for every ordinary request.
Event log and decision visibility
The admin event log shows Bot Guard decisions and the reasons behind them.
Logged events include:
- Challenge required events
- Bootstrap suppression events
- CAPTCHA pass/fail/rate-limit events
- Verified official crawler/fetcher IP allows
- Known crawler header allow decisions
- Collector submissions and collector proof failures
- Browser re-collection requests
- Route, controller, action, method, and path context
- Reason codes and risk score
- Hashed visitor, IP, session, URI, and referrer identifiers
- Decision timing metadata
Admin health/status page
XF Bot Guard includes a health/status page in the admin control panel.
It checks the add-on toggle, JavaScript collector status, XenForo CAPTCHA configuration, PAGE_CONTAINER template modification, bundled JavaScript assets, audit logging, low-value logging, event/session/visitor retention, counter retention, official crawler source/range import status, known crawler header trust, origin-lockdown acknowledgement, event/counter table size, and hash-secret/globalSalt availability.
Current visitors visibility
Bot Guard verification routes appear clearly in XenForo’s Current visitors / Members online area.
Challenged visitors can also be separated into a Bot Guard “Bots” count, so they do not inflate normal online visitor totals while they are still pending verification.
The activity text does not expose return URLs, visitor hashes, IP hashes, fingerprint IDs, collector proof values, or challenge metadata.
Known crawler support
XF Bot Guard supports two crawler trust paths.
| Crawler trust path | How it works |
|---|---|
| Official crawler/fetcher IP ranges | Bot Guard imports official provider-published JSON CIDR feeds and allows matching request IPs locally. This is enabled by default and does not trust user-agent strings, reverse DNS, or spoofable headers. |
| Trusted crawler headers | Bot Guard can trust known verified crawler headers when you explicitly enable that option. Use this only when the headers come from trusted infrastructure and direct origin access is blocked. |
Official source support includes Google crawler/fetcher feeds, Bingbot, Applebot, and DuckDuckBot. The health page shows whether the official source rows and imported IP ranges are available.
Privacy-conscious storage
XF Bot Guard is designed not to store raw IP addresses or raw browser fingerprint IDs in its own tables.
It stores hashed identifiers for reputation and anti-abuse decisions. Browser fingerprint collection runs locally with the bundled FingerprintJS library. No external fingerprinting account is required.
Bot Guard stores compact anti-abuse metadata and browser-coherence signals. It does not store raw FingerprintJS component entropy by default, and raw collector proof values are not stored in the event log.
Site owners should update their privacy policy because the add-on performs anti-abuse fingerprinting, behavioural monitoring, and challenge decisions.
No external service account required
XF Bot Guard does not require:
- A paid subscription
- An API key
- A cloud account
- A CDN account
- An external bot-detection service account
- A third-party XenForo add-on
Works alongside Cloudflare and server security
Cloudflare, WAF rules, server firewall rules, and rate limits can block traffic before it reaches XenForo.
XF Bot Guard works at the XenForo layer, where it can see forum routes, sessions, cookies, CAPTCHA trust, collector state, content context, and hashed visitor reputation.
Use it as an additional XenForo-native layer, not as a replacement for good server/CDN security.
What this is not
XF Bot Guard is not a firewall, reverse proxy, CDN, WAF, nginx rule, Apache rule, LiteSpeed rule, or iptables block.
It does not stop requests before they reach PHP.
A sophisticated scraper using a real browser, stable cookies, JavaScript execution, careful timing, and CAPTCHA solving can still pass. XF Bot Guard is built to stop, slow, and expose unwanted automated visitors by forcing risky traffic through an explainable XenForo challenge flow.
Requirements
- XenForo 2.1.0+
- PHP 7.2+
- A configured XenForo CAPTCHA provider for challenge use
- A theme that includes the standard PAGE_CONTAINER output
- Optional: XenForo cache configured for counter read-load reduction
- Upload the add-on files to your XenForo installation.
- Install XF Bot Guard from the XenForo admin control panel.
- Configure XenForo CAPTCHA if it is not already configured.
- Review the Bot Guard options.
- Review the Bot Guard health/status page.
- Confirm official crawler/fetcher IP sources imported successfully.
- Enable the add-on.
- Monitor the event log and adjust the threshold/scope as needed.
- Confirm XenForo CAPTCHA is configured and working.
- Confirm the Bot Guard JavaScript files are reachable.
- Confirm the PAGE_CONTAINER template modification is enabled.
- Confirm official crawler/fetcher source ranges are imported in the health page.
- If using a proxy/CDN, confirm XenForo receives the correct real visitor IP.
- If trusting known crawler headers, confirm direct origin access is blocked first.
- Start with guests only and the default threshold before tightening.
Proprietary freeware.
This resource is free to use, but it is not open source. Redistribution, resale, sublicensing, publishing modified versions, or removing copyright/license notices is not permitted without written permission from the developer.
Summary
XF Bot Guard gives XenForo forums a native, stable, configurable, explainable challenge layer for suspicious bots and scrapers.
It watches behaviour, validates browser evidence, verifies official crawler/fetcher IP ranges, tracks repeated bootstrap-only access, builds reputation, keeps operational counters separate from audit logs, uses XenForo cache for counter reads when configured, provides clear admin visibility, and challenges risky visitors before they can continue freely browsing protected content.
Télécharger V1.0.3 :
Pour consulter le contenu, vous devez : Se connecter ou S'inscrire.
Browser Signal Hardening & CAPTCHA Trust Improvements
This update improves XF Bot Guard’s browser verification and challenge handling without changing the core protection model.Improved browser coherence checks
XF Bot Guard now collects and evaluates a broader set of lightweight browser signals to better identify suspicious or automated traffic patterns. These checks help distinguish normal browser activity from sessions that appear inconsistent, incomplete, automated, or artificially constructed.New checks include:
- WebDriver and automation artefact detection
- User-Agent and Client Hints consistency checks
- Platform, screen, touch, and hardware profile consistency checks
- Language, timezone, and country plausibility checks
- Resource loading and rendering profile checks
- Cookie capability consistency checks
Safer scoring behaviour
Browser-coherence signals are now capped so that unusual but legitimate browsers, privacy extensions, older devices, or uncommon network setups are not over-penalised.High-confidence automation indicators, such as explicit WebDriver or headless browser evidence, can still contribute strongly to the risk score.
Improved metadata handling
The browser collector now stores richer but still privacy-conscious metadata. XF Bot Guard continues to avoid storing raw FingerprintJS component entropy, raw IP addresses, or unbounded client-side data.Collected metadata is limited to compact browser and request-coherence signals used for bot-risk evaluation.
Fixed CAPTCHA trust-window behaviour
Fixed an issue where a visitor who successfully completed CAPTCHA could immediately be challenged again if their underlying risk score remained high.A successful CAPTCHA now properly honours the configured trust duration. During the active trust window, the visitor is allowed through without being challenged again.
Improved logging and observability
New browser-coherence risk factors now appear in the existing XF Bot Guard event log as named reason codes with point values.CAPTCHA trust-window allows are also logged clearly, making it easier to understand when a visitor was allowed because they had recently completed verification.
No admin action required
This update does not add new configuration options and does not require any database schema changes.Redirect, Collector Hardening & Verification Flow Improvements
This update improves XF Bot Guard’s verification flow, browser collector integrity, trusted crawler handling, and XenForo integration polish without changing the core protection model.Fixed post-CAPTCHA return behaviour
Fixed an issue where visitors who completed CAPTCHA could be returned to the forum homepage instead of the original page they were trying to access.XF Bot Guard now preserves the originally requested safe URL through the challenge flow and returns the visitor to that page after successful verification.
This includes first-visit and new-session challenge flows, such as visitors opening a protected thread or forum page before they already have an established forum session.
Unsafe return targets are rejected automatically, including external URLs, Bot Guard routes, login/logout/register routes, API routes, admin/install paths, webhook-style paths, payment callback-style paths, and malformed values.
If the original return URL is missing or unsafe, XF Bot Guard safely falls back to the forum index as before.
Improved trusted crawler handling
Known allowed crawler detection now works as a true allow decision when trusted crawler handling is enabled.Previously, known crawler detection reduced the risk score but could still result in a challenge if the request scored highly enough for other reasons.
XF Bot Guard now still calculates and logs the score for observability, but verified known crawler requests can be allowed at the decision layer rather than being challenged unnecessarily.
This keeps crawler handling visible in the event log while making the trusted crawler setting behave more consistently.
Collector proof and replay hardening
The browser collector now uses short-lived server-issued proof to better bind collector submissions to the current page, session, and timing window.This makes collector submissions harder to replay or synthesize independently from a genuine page load.
Collector proof is validated before browser metadata is accepted as trusted collector evidence. Invalid, expired, reused, missing, or mismatched collector proof is handled safely and logged for observability.
This hardening is designed to fail safely without breaking normal page loads.
Suspicion-triggered browser re-collection
XF Bot Guard can now request fresh browser collection when request context changes in ways that may make older collector metadata less reliable.Examples include:
- User-Agent family changes
- Country changes
- ASN changes where available
- Stale collector metadata
- Suspicious route families
- Collector metadata missing despite an existing visitor fingerprint
- Fingerprint/session relationship inconsistencies
Conservative route-family scoring
This update adds a small route-family risk layer for routes commonly associated with scraping or enumeration behaviour.Examples include:
- Search pages
- Find-new / what’s-new style pages
- Member list and profile enumeration
- Deep pagination
- Repeated listing or index traversal
Safer hash-secret behaviour
Removed the predictable fallback hash secret path.XF Bot Guard now uses the configured Bot Guard hash secret where available, or XenForo’s global salt where available.
If neither is available, XF Bot Guard avoids generating predictable hashes, fails open for visitor access where appropriate, and logs the configuration issue so the administrator can correct it.
Explicit cookie attributes
Bot Guard marker cookies now use explicit modern cookie attributes.Cookies now set SameSite=Lax, use Secure when served over HTTPS, and only allow JavaScript access where the browser collector genuinely requires it.
This improves cookie behaviour consistency across modern browsers while preserving compatibility with the add-on’s supported XenForo versions.
Improved Current visitors activity
Bot Guard verification routes now display clearer activity text in XenForo’s Current visitors / online users area.Visitors on the verification flow should now show generic verification-related activity rather than appearing as an unknown or unrecognised route.
The displayed activity text does not expose sensitive return URLs, visitor hashes, IP hashes, fingerprint IDs, nonce values, or challenge metadata.
Improved logging and observability
The existing XF Bot Guard event log now provides clearer visibility for the new behaviours.New or improved event visibility includes:
- CAPTCHA return URL restored or safely discarded
- Known crawler decision-layer allow overrides
- Collector proof validation failures
- Browser re-collection requests
- Route-family risk modifiers
- Hash secret / global salt configuration issues
Internal sanity and health-check tooling
This release includes an internal developer sanity and health-check harness used to improve release testing.The harness covers key behaviours such as CAPTCHA trust overrides, known crawler overrides, return URL validation, unsafe return rejection, Bot Guard self-route rejection, collector proof validation, metadata sanitisation, entropy scoring fixtures, route classification, excluded paths/routes/methods, and Bot Guard online activity support.
This internal tooling complements the usual manual XenForo 2.1, 2.2, and 2.3 compatibility testing.
No admin action required
This update does not require a new database schema change and does not add a new admin configuration page.Administrators using trusted crawler handling should ensure their proxy/header environment is appropriately controlled, as trusted crawler decisions depend on request headers being reliable.
XF Bot Guard 1.0.6 — First Stable Release & Production Hardening
XF Bot Guard 1.0.6 is now considered the first stable release of the add-on.This release focuses on making the 1.0.x foundation safer, quieter, faster, and easier to monitor on real production XenForo forums. The core protection model remains the same, but the internal behaviour has been hardened for serious forums running conservative settings.
The main goals of this release are:
- Reducing event log noise
- Separating operational counters from audit logs
- Improving hot-path performance
- Adding clearer admin health/status visibility
- Improving cleanup and retention behaviour
- Keeping defaults conservative for stable production use
First stable release
Version 1.0.6 is the first XF Bot Guard release marked as stable.Earlier 1.0.x versions established the core challenge flow, browser collector, trusted crawler handling, scoring model, and verification behaviour. This release hardens that foundation for broader production use.
The add-on is still disabled by default after installation, and the default operating mode remains conservative.
Operational counters are now separate from audit logs
XF Bot Guard now keeps lightweight internal counters separately from the main event log.Previously, some scoring and rate-limit decisions relied heavily on recent rows in the audit event table. That made it harder to safely reduce noisy low-value logging, because suppressing those rows could also affect scoring visibility.
In 1.0.6, short-window operational counters are stored independently and used for decisions such as recent request activity, recent error-route activity, recent sensitive-route activity, and CAPTCHA failure rate limiting.
This means XF Bot Guard can now reduce audit log pressure without weakening the scoring and rate-limit behaviour that depends on recent activity.
Reduced event log pressure
Low-value audit rows are now controlled separately from important security and verification events.By default, XF Bot Guard no longer writes ordinary low-value allow/skip rows for every normal safe guest request.
This helps prevent busy forums from filling the Bot Guard event table with endless routine browsing activity while still retaining useful security events.
Important events continue to be logged when audit logging is enabled, including:
- Challenge required events
- CAPTCHA pass/fail events
- CAPTCHA rate limiting
- Known crawler allow decisions
- Collector failure events
- Collector nonce/proof failures
- Hash secret or collector hash configuration problems
- Browser re-collection requests
- Error-route activity
Optional allow-event sampling
A new allow-event sample rate option has been added.This allows administrators to keep a small sample of otherwise low-value allow rows for visibility without logging every normal safe request.
For example, a busy forum can keep audit logging enabled for security events while sampling only a small percentage of routine allow decisions.
The default sample rate is 0%.
Hot-path performance hardening
Several relationship-count checks have been throttled so they are no longer recalculated on every eligible request.XF Bot Guard still tracks useful relationship signals such as visitor/IP relationships, visitor country/ASN variation, and IP/fingerprint relationships, but these are now refreshed periodically instead of repeatedly queried on every scored request.
This reduces database pressure on normal repeat guest browsing while preserving the same general scoring signals.
Counter cleanup and retention
The new operational counter table is automatically cleaned up by the existing Bot Guard cleanup cron path.Counter rows are short-lived and are pruned after approximately 48 hours.
This keeps the counter table focused on recent operational decisions and prevents it from growing indefinitely.
Existing event, visitor, session, fingerprint/IP, and online challenge cleanup behaviour remains in place.
New ACP health/status page
XF Bot Guard now includes an admin health/status page to make production setup easier to review.The health page provides clear OK, warning, and error rows for important configuration and runtime checks, including:
- Bot Guard enabled/disabled state
- JavaScript collector status
- XenForo CAPTCHA configuration
- PAGE_CONTAINER template modification status
- Bundled Bot Guard JavaScript asset presence
- Bundled FingerprintJS asset presence
- Audit logging status
- Low-value audit logging status
- Allow-event sample rate
- Event, visitor, and session retention settings
- Known crawler trust status
- Known crawler origin-lockdown acknowledgement
- Approximate event table size
- Approximate counter table size
- Hash secret / XenForo global salt availability
Known crawler origin-lockdown warning
This release adds a new origin-lockdown acknowledgement option for forums that enable trusted crawler handling.Trusted crawler decisions depend on crawler-related request headers being reliable. Those headers are only trustworthy if visitors cannot bypass the proxy/CDN layer and hit the origin server directly while spoofing headers.
If known crawler trust is enabled but origin lockdown has not been acknowledged, XF Bot Guard now shows a warning in the health page.
This does not block operation. It is an admin safety warning only.
Decision timing metadata
Retained decision/security events can now include lightweight timing metadata.This may include decision time, risk-data time, scoring time, counter time, and whether full scoring was run.
This is intended to help diagnose production behaviour without exposing debug output on public pages.
Stable defaults review
The stable defaults remain conservative.In particular:
- Bot Guard remains disabled by default
- Guest-only protection remains the default scope
- Challenge methods remain conservative
- Known crawler trust remains disabled by default
- Hard deny remains disabled by default
- AJAX exclusion remains enabled by default
- Strict no-browser/no-grace behaviour remains enabled
- Bootstrap allow behaviour remains enabled
- Important audit logging remains enabled
- Low-value allow-row logging is disabled by default
Database schema change
This release adds a new internal table:xf_zee_botguard_counterThis table stores short-lived operational counters used for scoring and rate-limit decisions.
The table is maintained automatically by XF Bot Guard and cleaned up through the existing cleanup process.
Recommended admin review after upgrade
After upgrading, administrators should review and save the Bot Guard options, as new options have been introduced.Administrators using trusted crawler handling should also confirm their proxy/CDN and origin-server setup prevents direct origin access before acknowledging origin lockdown.
Administrators who previously relied on very verbose allow-row logging can re-enable low-value event logging or configure allow-event sampling in the Bot Guard options.
Administrations should also review the new Bot Guard health/status page, linked to from the logs page.
Summary
XF Bot Guard 1.0.6 is a stability and production-readiness release.It reduces routine event log growth, moves scoring counters out of the audit log, lowers hot-path database pressure, adds better admin visibility, improves retention behaviour, and keeps the default configuration conservative.
This is the recommended stable foundation for production XenForo forums using XF Bot Guard.
Pour consulter le contenu, vous devez : Se connecter ou S'inscrire.
Version 1.0.7 / 1.0.8 :
xenforo.com
Version 1.0.9 :
xenforo.com
Version 1.1.0 :
xenforo.com
Version 1.1.1 :
xenforo.com
Pour consulter le contenu, vous devez : Se connecter ou S'inscrire.
Version 1.1.2 :
xenforo.com
Version 1.1.3 :
xenforo.com
Version 1.1.4 :
xenforo.com
Version 1.1.5 :
xenforo.com
Pour consulter le contenu, vous devez : Se connecter ou S'inscrire.
XF Bot Guard 1.1.6
Release type: Minor update
This update improves the reliability of the “Validating browser…” interstitial flow, particularly for fresh visitors who may not yet have a fully established XenForo cookie/session state.
Changes
Important for Cloudflare / CDN / cache users
This update changes the JavaScript file:
If you cache static assets through Cloudflare, another CDN, a reverse proxy, or a server-side cache layer, purge the cached copy of that file after upgrading.
If you are testing the fix immediately after upgrading, you should also visit that JavaScript URL directly in your browser and hard refresh it. This helps ensure your own browser is no longer using the old cached JavaScript.
After that, test the validating-browser flow again in a fresh private/incognito window.
XF Bot Guard 1.1.7
Release type: Minor update
This minor update improves how XF Bot Guard’s browser-validation JavaScript is loaded, helping avoid stale cached files after upgrades.
Release type: Major update
This release adds a new reverse-DNS hosting/datacentre detection layer, improves compatibility with online bot/statistics handling, and adds protection against incompatible guest-page caching configurations that can prevent XF Bot Guard from validating visitors correctly.
Changes
This update may challenge more traffic from confirmed hosting, VPS, cloud, proxy, and datacentre networks. That is intentional.
Most normal residential visitors should not be affected by the new reverse-DNS scoring layer.
If you use DigitalPoint Cloudflare and have guest page caching enabled, XF Bot Guard may warn that this configuration is incompatible. Guest page caching can serve cached HTML before XenForo and XF Bot Guard have a chance to validate the visitor, so it should be disabled when using XF Bot Guard.
If you use the Known Bots add-on, XF Bot Guard does not disable Known Bots itself. It only suppresses the overlapping public robot statistics option when XF Bot Guard is configured to manage online visitor/challenge counts.
XF Bot Guard 1.1.9
Release type: Major update
This release significantly strengthens XF Bot Guard's cache-bypass protection, adds reverse-DNS verification for additional legitimate crawlers, improves feed/RSS handling, adds browser-validation page customisation, and expands the Health Check system so site owners can more easily detect configurations that may prevent XF Bot Guard from validating visitors correctly.
Changes
This is a major update.
The most important change is the new cache-bypass protection work. XF Bot Guard now applies stronger no-store cache headers more broadly across protected responses, not just in the previous DigitalPoint Cloudflare-specific scenario.
This does not mean every possible cache configuration is automatically safe. If a CDN, reverse proxy, server cache, optimisation add-on, or page-cache rule force-caches protected HTML before XenForo and XF Bot Guard can run, it can still bypass visitor validation. XF Bot Guard now detects and warns about more of these cases, but protected XenForo pages should still not be served from a shared full-page HTML cache.
Static assets such as images, CSS, JavaScript, fonts, and attachments can still be cached normally. The concern is cached public HTML pages that should have passed through XenForo and XF Bot Guard first.
The new reverse-DNS crawler verification layer is intended to reduce false positives for legitimate crawlers that identify themselves correctly but are not always covered by official published IP ranges. XF Bot Guard does not trust the User-Agent alone. Reverse DNS must match an expected crawler domain and forward DNS must confirm the same IP.
Be careful with the new custom trusted crawler reverse-DNS domains option. Only add domains for crawlers you genuinely trust. XF Bot Guard will still verify the DNS relationship, but trusting the wrong domain is still a site-owner configuration risk.
Feed handling has also changed. RSS and Atom feed clients should no longer be pushed into normal interactive browser validation. Trusted feed requests can be allowed, while suspicious feed requests can be denied without serving a CAPTCHA or browser-validation page.
If you use aggressive CDN, proxy, server-level, LiteSpeed, NGINX, Varnish, Cloudflare, or optimisation add-on caching, review the XF Bot Guard Health Check after upgrading.
XF Bot Guard 1.2.0
Release type: Major update
This release adds Cloudflare Edge Enforcement, an optional new protection layer that allows XF Bot Guard to feed high-confidence application-level abuse intelligence back into Cloudflare.
For heavily botted forums using Cloudflare, this is a significant step forward. XF Bot Guard can now detect repeat abusive behaviour inside XenForo, promote the worst offending public IPs into a managed Cloudflare IP list, and have Cloudflare issue a Managed Challenge before those requests continue reaching XenForo.
In plain terms: XF Bot Guard still performs the intelligent application-level detection, but Cloudflare can now help enforce against repeat offenders at the edge.
Changes
Before this release, XF Bot Guard could detect, score, challenge, deny, and log suspicious traffic once that traffic had already reached XenForo.
That is still useful, but repeat abusive traffic can still consume origin resources. The request still reaches Cloudflare, then your server, then PHP, then XenForo, then XF Bot Guard.
With Cloudflare Edge Enforcement enabled, XF Bot Guard can escalate the worst repeat offenders back to Cloudflare.
Before Cloudflare Edge Enforcement:
After promotion and Cloudflare sync:
This is the important part of 1.2.0.
XF Bot Guard is no longer only protecting at the application layer after the request reaches XenForo. For suitable forums using Cloudflare, it can now contribute application-level intelligence back into the edge protection layer.
For heavily botted sites, this can be extremely valuable. Repeat abusive traffic can be challenged before it continues hitting PHP, XenForo routing, sessions, challenge pages, counters, logs, and database-backed behaviour checks.
This is not intended to replace XF Bot Guard's normal protection. It is an escalation layer. XF Bot Guard identifies the behaviour inside XenForo, then Cloudflare helps absorb repeat abuse earlier in the request path.
How IP promotion works
XF Bot Guard does not send every challenged visitor to Cloudflare.
Promotion is deliberately conservative.
An IP generally needs to be an anonymous public IP showing repeated or high-confidence abusive behaviour. XF Bot Guard looks for signals such as excessive request velocity, repeated failed validation, repeated CAPTCHA failure or rate limiting, suspicious automation behaviour, invalid collector/proof activity, abnormal fingerprint behaviour, and other strong bot-like patterns.
Some severe events may be promoted faster than weaker signals, but XF Bot Guard still applies safety checks first.
XF Bot Guard is designed to avoid promoting:
What happens when a promoted IP returns
When a promoted IP has been synced to Cloudflare, Cloudflare applies a Managed Challenge before the request reaches XenForo.
This does not mean the IP is permanently banned.
A Cloudflare Managed Challenge is intentionally softer than a hard block. Many real human visitors can pass it. Many bots, scripts, scrapers, headless clients, and low-quality automated requests cannot.
That is the balance XF Bot Guard is aiming for: move repeat abuse away from the origin, without turning the feature into a blunt permanent firewall ban.
Cloudflare rule used
XF Bot Guard manages a Cloudflare WAF rule using its managed IP list.
The rule is based on this logic:
The action is:
This means requests from IPs in the XF Bot Guard managed list receive a Cloudflare Managed Challenge, while Cloudflare-recognised verified bots are excluded.
A quick note on the Admin Control Panel pages
Before the setup instructions, a fair warning: the Cloudflare Edge Enforcement ACP pages are functional, but they are still very much first-pass admin pages.
They do what they need to do: setup, health checks, candidate review, sync logs, repair actions, and disable tools are all there. But, like some of XF Bot Guard's existing reports and tables, they are not yet as tidy or polished as I want them to be.
The protection layer is the important part of this release, and that is where the focus has been. The next minor releases will be concentrating heavily on admin quality-of-life improvements, tidier tables, clearer reports, better page flow, and generally making the ACP feel less like it was assembled during a bot attack.
Which, to be fair, parts of it probably were.
Setup
Cloudflare Edge Enforcement is optional and disabled by default.
Dry-run mode is enabled by default. In dry-run mode, XF Bot Guard can evaluate and queue local candidates, but it will not write changes to Cloudflare.
To set it up:
After that, the integration is active. The cron will keep the Cloudflare list in sync automatically.
At the time of this release, XF Bot Guard expects Cloudflare permissions for account rule lists, zone read access, and zone WAF editing. The setup page provides guidance and the API token link is pre-filled with the required permissions.
Important notes
This is a major update.
The Cloudflare Edge Enforcement layer is optional. If you do not use Cloudflare, or do not want XF Bot Guard to manage a Cloudflare IP list and WAF rule, you can leave this feature disabled.
This feature is most valuable for forums that are already behind Cloudflare and receive heavy bot, scraper, spam, automation, or abusive guest traffic.
Raw IP storage is required for Cloudflare Edge Enforcement. XF Bot Guard cannot sync an IP to Cloudflare if it is only storing hashed IP data. Before enabling raw IP storage, review your own privacy policy and local requirements.
Dry-run is enabled by default for a reason. Use it first. It allows you to see what XF Bot Guard would do before it starts writing to Cloudflare.
You should be reasonably comfortable with Cloudflare before enabling this feature. You do not need to be a Cloudflare expert, and XF Bot Guard provides setup, test, sync, health check, repair, and disable tools. However, this feature does interact with Cloudflare account-level lists and zone WAF rules, so it should be enabled carefully rather than blindly switched on.
As noted above, the next minor releases will focus heavily on admin quality-of-life improvements across XF Bot Guard.
Cloudflare Edge Enforcement should be treated as an escalation layer, not a replacement for XF Bot Guard's normal protection. XF Bot Guard still performs the application-level detection. Cloudflare simply helps enforce against the worst repeat offenders earlier, before they continue consuming XenForo resources.
XF Bot Guard 1.2.1
Release type: Minor update
This minor update gives XF Bot Guard’s admin pages a much-needed quality-of-life pass. The old ACP layouts worked, but let’s be honest: some of those tables were doing their best impression of a car crash.
This update makes the admin-side pages cleaner, easier to scan, and much less painful when dealing with long bot data, hashes, paths, metadata, and Cloudflare edge records.
Release type: Minor update
This update improves the reliability of the “Validating browser…” interstitial flow, particularly for fresh visitors who may not yet have a fully established XenForo cookie/session state.
Changes
- Improved handling of the interstitial browser-validation collect request so it is processed earlier in the XenForo request lifecycle.
- Added a small client-side breathing-space delay before the interstitial collect request is sent.
- Added automatic back-off and retry handling if the interstitial collect request temporarily fails.
- Added a fallback path: if the interstitial collect still cannot complete after retries, the visitor is redirected to the full XF Bot Guard challenge page instead of being left stuck on the validating screen.
- Ensured XF Bot Guard’s own challenge route is never served through the lightweight interstitial flow.
- Added clearer AJAX/JSON request handling for the collector request.
Important for Cloudflare / CDN / cache users
This update changes the JavaScript file:
Code:
/js/zee/botguard/botguard.js
If you are testing the fix immediately after upgrading, you should also visit that JavaScript URL directly in your browser and hard refresh it. This helps ensure your own browser is no longer using the old cached JavaScript.
After that, test the validating-browser flow again in a fresh private/incognito window.
XF Bot Guard 1.1.7
Release type: Minor update
This minor update improves how XF Bot Guard’s browser-validation JavaScript is loaded, helping avoid stale cached files after upgrades.
- Loads Bot Guard’s main JavaScript directly instead of through XenForo’s normal JS include/combiner path.
- Adds version-based cache busting to Bot Guard’s JavaScript and bundled fingerprinting script.
- Helps Cloudflare, CDN, browser, and JavaScript-combiner caches pick up the latest Bot Guard files more reliably after an update.
- Keeps the script base path unversioned internally so dynamically loaded assets continue resolving correctly.
Release type: Major update
This release adds a new reverse-DNS hosting/datacentre detection layer, improves compatibility with online bot/statistics handling, and adds protection against incompatible guest-page caching configurations that can prevent XF Bot Guard from validating visitors correctly.
Changes
- Added reverse-DNS hosting and datacentre detection for public IP addresses.
- Added a new hosting/datacentre reverse-DNS score option, enabled by default.
- Added a new reverse-DNS cache table so confirmed hosting/datacentre results can be reused without repeated DNS lookups.
- Added support for detecting many common hosting, cloud, VPS, proxy, and datacentre networks by confirmed reverse-DNS patterns.
- Improved handling of visitors coming from confirmed hosting/datacentre networks so they can be scored more accurately before the final allow/challenge decision is made.
- Added new Health Check entries for reverse-DNS hosting detection, including cache status, confirmed matches, resolver errors, and stale pending lookups.
- Improved compatibility with the Known Bots add-on when XF Bot Guard is managing online visitor and challenge statistics.
- When XF Bot Guard’s online-count adjustment is enabled, XF Bot Guard now suppresses overlapping public robot statistics from Known Bots so visitor counts are not double-handled or misrepresented.
- Added ongoing compatibility enforcement for Known Bots during install, upgrade, online-count calculation, and scheduled cleanup.
- Added compatibility detection for DigitalPoint Cloudflare guest page caching.
- Added a new option to disable incompatible DigitalPoint Cloudflare guest page caching when XF Bot Guard is active.
- Added a Health Check warning when DigitalPoint Cloudflare guest page caching is enabled in a way that may bypass XF Bot Guard validation.
- Added a Health Check action button to disable the incompatible DigitalPoint Cloudflare guest page cache configuration directly from the XF Bot Guard health page.
- Added public HTML cache-header hardening when DigitalPoint Cloudflare compatibility protection is enabled.
- Improved Members Online template modification compatibility.
This update may challenge more traffic from confirmed hosting, VPS, cloud, proxy, and datacentre networks. That is intentional.
Most normal residential visitors should not be affected by the new reverse-DNS scoring layer.
If you use DigitalPoint Cloudflare and have guest page caching enabled, XF Bot Guard may warn that this configuration is incompatible. Guest page caching can serve cached HTML before XenForo and XF Bot Guard have a chance to validate the visitor, so it should be disabled when using XF Bot Guard.
If you use the Known Bots add-on, XF Bot Guard does not disable Known Bots itself. It only suppresses the overlapping public robot statistics option when XF Bot Guard is configured to manage online visitor/challenge counts.
XF Bot Guard 1.1.9
Release type: Major update
This release significantly strengthens XF Bot Guard's cache-bypass protection, adds reverse-DNS verification for additional legitimate crawlers, improves feed/RSS handling, adds browser-validation page customisation, and expands the Health Check system so site owners can more easily detect configurations that may prevent XF Bot Guard from validating visitors correctly.
Changes
- Added a new protected-response cache shield for XF Bot Guard routes, challenge pages, browser-validation pages, collection endpoints, redirects, and protected public HTML responses.
- Expanded cache-header hardening beyond the previous DigitalPoint Cloudflare-specific compatibility handling.
- XF Bot Guard now sends stronger no-store/no-cache headers for protected responses, including headers intended for browsers, proxies, CDNs, LiteSpeed, NGINX, Cloudflare, surrogate caches, and other shared cache layers.
- Added a new Health Check probe that can test whether protected pages or XF Bot Guard routes appear to be served from a shared or full-page cache.
- Added Health Check reporting for common cache indicators such as Cloudflare, LiteSpeed, Varnish, proxy cache, FastCGI cache, NGINX cache, CDN cache, and other shared-cache headers.
- Added a Health Check action to refresh the shared full-page cache probe.
- Added clearer Health Check warnings when a server, CDN, proxy, or optimisation layer may be caching protected HTML in a way that can bypass XF Bot Guard.
- Added reverse-DNS and forward-DNS verification for additional legitimate crawlers that are not always covered by official published IP range data.
- Added verified crawler support for Yandex, Qwant, Seznam, and Applebot-style reverse-DNS verification.
- Added a new trusted crawler reverse-DNS domains option, allowing site owners to trust additional crawler domains when reverse DNS and forward DNS both confirm the request IP.
- Improved verified crawler logging so XF Bot Guard records whether a crawler was trusted by official IP range data or by confirmed reverse-DNS verification.
- Improved robot/activity classification so reverse-DNS verified crawlers can be represented more accurately in XenForo's online activity systems.
- Added dynamic robot definitions for custom trusted reverse-DNS crawler domains.
- Improved RSS, Atom, and feed request handling so feed clients are not redirected to interactive browser validation or CAPTCHA pages.
- Feed requests can now be allowed, scored, or quietly denied depending on trust status and risk, rather than being handled like normal browser page views.
- Added empty 403 responses for denied non-interactive feed requests.
- Added browser-validation page customisation options for the page title, heading, and message.
- Added safe text handling for browser-validation page customisation, including escaping, length limits, and line-break support for the message.
- Added an option to retain browser-validation allow logs without needing to enable all low-value event logging.
- Added self-server IP detection so XF Bot Guard can recognise its own server-side health-check and XenForo unfurl requests and avoid treating them like normal visitors.
- Added storage and cleanup for self-server IP detection data.
- Added storage and cleanup for reverse-DNS crawler verification results.
- Improved protection policy handling by centralising route, scope, static asset, AJAX, excluded IP, protected-area, and cache-shield decisions.
- Improved handling of failed browser-validation interstitial generation by falling back to the normal challenge flow instead of leaving the request in an unclear state.
- Improved online visitor handling by suppressing anonymous HEAD request activity updates when XF Bot Guard's online-count adjustment is enabled.
- Added an admin navigation entry for XF Bot Guard logs under the XenForo logs area.
- Added install and upgrade repair logic to ensure the XF Bot Guard admin navigation entry is present.
- Improved option parsing for textbox-style lists by allowing blank lines and comments.
- Updated Health Check wording and option explanations to better describe cache protection and verified crawler handling.
This is a major update.
The most important change is the new cache-bypass protection work. XF Bot Guard now applies stronger no-store cache headers more broadly across protected responses, not just in the previous DigitalPoint Cloudflare-specific scenario.
This does not mean every possible cache configuration is automatically safe. If a CDN, reverse proxy, server cache, optimisation add-on, or page-cache rule force-caches protected HTML before XenForo and XF Bot Guard can run, it can still bypass visitor validation. XF Bot Guard now detects and warns about more of these cases, but protected XenForo pages should still not be served from a shared full-page HTML cache.
Static assets such as images, CSS, JavaScript, fonts, and attachments can still be cached normally. The concern is cached public HTML pages that should have passed through XenForo and XF Bot Guard first.
The new reverse-DNS crawler verification layer is intended to reduce false positives for legitimate crawlers that identify themselves correctly but are not always covered by official published IP ranges. XF Bot Guard does not trust the User-Agent alone. Reverse DNS must match an expected crawler domain and forward DNS must confirm the same IP.
Be careful with the new custom trusted crawler reverse-DNS domains option. Only add domains for crawlers you genuinely trust. XF Bot Guard will still verify the DNS relationship, but trusting the wrong domain is still a site-owner configuration risk.
Feed handling has also changed. RSS and Atom feed clients should no longer be pushed into normal interactive browser validation. Trusted feed requests can be allowed, while suspicious feed requests can be denied without serving a CAPTCHA or browser-validation page.
If you use aggressive CDN, proxy, server-level, LiteSpeed, NGINX, Varnish, Cloudflare, or optimisation add-on caching, review the XF Bot Guard Health Check after upgrading.
XF Bot Guard 1.2.0
Release type: Major update
This release adds Cloudflare Edge Enforcement, an optional new protection layer that allows XF Bot Guard to feed high-confidence application-level abuse intelligence back into Cloudflare.
For heavily botted forums using Cloudflare, this is a significant step forward. XF Bot Guard can now detect repeat abusive behaviour inside XenForo, promote the worst offending public IPs into a managed Cloudflare IP list, and have Cloudflare issue a Managed Challenge before those requests continue reaching XenForo.
In plain terms: XF Bot Guard still performs the intelligent application-level detection, but Cloudflare can now help enforce against repeat offenders at the edge.
Changes
- Added optional Cloudflare Edge Enforcement, allowing XF Bot Guard to escalate repeat high-confidence abusive IPs to Cloudflare.
- Added automatic Cloudflare IP list and WAF rule management, so repeat offenders can receive a Cloudflare Managed Challenge before reaching XenForo.
- Added local edge-candidate tracking so XF Bot Guard can identify, score, expire, and sync abusive IPs safely.
- Added dry-run mode, enabled by default, so site owners can review what would be synced before XF Bot Guard writes anything to Cloudflare.
- Added safety protections to avoid promoting staff, logged-in users, verified crawlers, excluded IPs, private/internal IPs, and manually protected IPs.
- Added Cloudflare setup, connection testing, health checks, manual sync, sync logs, candidate review, repair, and disable tools in the Admin Control Panel.
- Added encrypted storage for the Cloudflare API token.
- Added a manual never-export list for IPs that should not be synced to Cloudflare.
- Updated FingerprintJS from 5.1.0 to 5.2.0.
Before this release, XF Bot Guard could detect, score, challenge, deny, and log suspicious traffic once that traffic had already reached XenForo.
That is still useful, but repeat abusive traffic can still consume origin resources. The request still reaches Cloudflare, then your server, then PHP, then XenForo, then XF Bot Guard.
With Cloudflare Edge Enforcement enabled, XF Bot Guard can escalate the worst repeat offenders back to Cloudflare.
Before Cloudflare Edge Enforcement:
Code:
Bot or abusive client
-> Cloudflare
-> XenForo / PHP / database
-> XF Bot Guard detects, challenges, denies, or logs
After promotion and Cloudflare sync:
Code:
Bot or abusive client
-> Cloudflare Managed Challenge
-> usually never reaches XenForo
This is the important part of 1.2.0.
XF Bot Guard is no longer only protecting at the application layer after the request reaches XenForo. For suitable forums using Cloudflare, it can now contribute application-level intelligence back into the edge protection layer.
For heavily botted sites, this can be extremely valuable. Repeat abusive traffic can be challenged before it continues hitting PHP, XenForo routing, sessions, challenge pages, counters, logs, and database-backed behaviour checks.
This is not intended to replace XF Bot Guard's normal protection. It is an escalation layer. XF Bot Guard identifies the behaviour inside XenForo, then Cloudflare helps absorb repeat abuse earlier in the request path.
How IP promotion works
XF Bot Guard does not send every challenged visitor to Cloudflare.
Promotion is deliberately conservative.
An IP generally needs to be an anonymous public IP showing repeated or high-confidence abusive behaviour. XF Bot Guard looks for signals such as excessive request velocity, repeated failed validation, repeated CAPTCHA failure or rate limiting, suspicious automation behaviour, invalid collector/proof activity, abnormal fingerprint behaviour, and other strong bot-like patterns.
Some severe events may be promoted faster than weaker signals, but XF Bot Guard still applies safety checks first.
XF Bot Guard is designed to avoid promoting:
- staff members;
- logged-in users;
- verified crawlers;
- private, reserved, or internal IP ranges;
- IPs excluded from XF Bot Guard handling;
- IPs added to the never-export list.
What happens when a promoted IP returns
When a promoted IP has been synced to Cloudflare, Cloudflare applies a Managed Challenge before the request reaches XenForo.
This does not mean the IP is permanently banned.
A Cloudflare Managed Challenge is intentionally softer than a hard block. Many real human visitors can pass it. Many bots, scripts, scrapers, headless clients, and low-quality automated requests cannot.
That is the balance XF Bot Guard is aiming for: move repeat abuse away from the origin, without turning the feature into a blunt permanent firewall ban.
Cloudflare rule used
XF Bot Guard manages a Cloudflare WAF rule using its managed IP list.
The rule is based on this logic:
Code:
(ip.src in $xf_bot_guard_edge_ips and not cf.client.bot)
The action is:
Code:
managed_challenge
This means requests from IPs in the XF Bot Guard managed list receive a Cloudflare Managed Challenge, while Cloudflare-recognised verified bots are excluded.
A quick note on the Admin Control Panel pages
Before the setup instructions, a fair warning: the Cloudflare Edge Enforcement ACP pages are functional, but they are still very much first-pass admin pages.
They do what they need to do: setup, health checks, candidate review, sync logs, repair actions, and disable tools are all there. But, like some of XF Bot Guard's existing reports and tables, they are not yet as tidy or polished as I want them to be.
The protection layer is the important part of this release, and that is where the focus has been. The next minor releases will be concentrating heavily on admin quality-of-life improvements, tidier tables, clearer reports, better page flow, and generally making the ACP feel less like it was assembled during a bot attack.
Which, to be fair, parts of it probably were.
Setup
Cloudflare Edge Enforcement is optional and disabled by default.
Dry-run mode is enabled by default. In dry-run mode, XF Bot Guard can evaluate and queue local candidates, but it will not write changes to Cloudflare.
To set it up:
- Upgrade XF Bot Guard to 1.2.0.
- Review your privacy policy before enabling raw IP storage.
- In the Admin Control Panel, go to Add-ons.
- Open XF Bot Guard -> Cloudflare Edge Enforcement.
- Open Setup using the top-right button.
- Enable raw IP storage.
- Enable Cloudflare Edge Enforcement.
- Leave Dry-run mode enabled for now.
- In a new browser tab, log in to Cloudflare.
- Copy your Cloudflare Account ID and Cloudflare Zone ID into the XF Bot Guard setup page. Cloudflare documentation: Find account and zone IDs
- Back in the XF Bot Guard setup page, click Create Cloudflare API token.
- Create the Cloudflare API token using the pre-filled permissions.
- Copy the Cloudflare API token into the XF Bot Guard setup page.
- Press Save.
- After saving, scroll down and click Set up Cloudflare automatically.
- Return to the Cloudflare Edge Enforcement overview.
- Click Sync now.
- Review the health checks.
- Periodically open Candidates to review what XF Bot Guard would sync while dry-run mode is still enabled.
- Once you are happy with what Cloudflare Edge Enforcement would have enforced, go back to Setup and disable dry-run mode.
- Run Sync now again, or allow the cron to perform the next sync automatically.
After that, the integration is active. The cron will keep the Cloudflare list in sync automatically.
At the time of this release, XF Bot Guard expects Cloudflare permissions for account rule lists, zone read access, and zone WAF editing. The setup page provides guidance and the API token link is pre-filled with the required permissions.
Important notes
This is a major update.
The Cloudflare Edge Enforcement layer is optional. If you do not use Cloudflare, or do not want XF Bot Guard to manage a Cloudflare IP list and WAF rule, you can leave this feature disabled.
This feature is most valuable for forums that are already behind Cloudflare and receive heavy bot, scraper, spam, automation, or abusive guest traffic.
Raw IP storage is required for Cloudflare Edge Enforcement. XF Bot Guard cannot sync an IP to Cloudflare if it is only storing hashed IP data. Before enabling raw IP storage, review your own privacy policy and local requirements.
Dry-run is enabled by default for a reason. Use it first. It allows you to see what XF Bot Guard would do before it starts writing to Cloudflare.
You should be reasonably comfortable with Cloudflare before enabling this feature. You do not need to be a Cloudflare expert, and XF Bot Guard provides setup, test, sync, health check, repair, and disable tools. However, this feature does interact with Cloudflare account-level lists and zone WAF rules, so it should be enabled carefully rather than blindly switched on.
As noted above, the next minor releases will focus heavily on admin quality-of-life improvements across XF Bot Guard.
Cloudflare Edge Enforcement should be treated as an escalation layer, not a replacement for XF Bot Guard's normal protection. XF Bot Guard still performs the application-level detection. Cloudflare simply helps enforce against the worst repeat offenders earlier, before they continue consuming XenForo resources.
XF Bot Guard 1.2.1
Release type: Minor update
This minor update gives XF Bot Guard’s admin pages a much-needed quality-of-life pass. The old ACP layouts worked, but let’s be honest: some of those tables were doing their best impression of a car crash.
This update makes the admin-side pages cleaner, easier to scan, and much less painful when dealing with long bot data, hashes, paths, metadata, and Cloudflare edge records.
- Improves the layout and styling of XF Bot Guard ACP pages.
- Adds cleaner spacing, padding, button alignment, and table handling across the admin interface.
- Improves wide data tables so long values, dates, paths, JSON, hashes, and error messages are better contained.
- Improves filter panels so fields are easier to read and take up less unnecessary vertical space.
- Improves event detail and Edge candidate detail pages with cleaner code block and metadata presentation.
- Improves health check/status display readability.
- Adds a small optional support/development contribution prompt in the relevant XF Bot Guard admin pages.
- Does not change public-facing challenge behaviour or bot detection logic.
XF Bot Guard 1.2.2
Release type: Major update
This release adds the new XF Bot Guard Dashboard, a visual single-page overview designed to show what Bot Guard is doing, why traffic is being challenged, where suspicious activity is coming from, and whether the system is healthy.
This is not just a prettier log page.
The dashboard is designed to tell the full Bot Guard story:
The screenshot above only shows part of it. There is quite a bit more further down the page, including traffic journey charts, challenge outcomes, interstitial/browser proof activity, risk signals, route pressure, CAPTCHA trust-window behaviour, crawler health, Cloudflare Edge Enforcement status, system health, and raw drill-down links.
After upgrading, go to:
Admin Control Panel -> Add-ons -> XF Bot Guard -> Dashboard
And enjoy.
Changes
Before this release, XF Bot Guard already recorded a lot of useful information, but most of it lived in logs, counters, health pages, and specialised admin screens.
That was useful for debugging, but not ideal for quickly answering the big question:
Is Bot Guard working?
The new dashboard is intended to answer that quickly.
Instead of making you dig through raw events first, XF Bot Guard now gives you a visual summary of what it is seeing and how traffic is moving through the protection layers.
In plain terms, the dashboard helps show:
One important part of this dashboard is the wording.
XF Bot Guard does not present a CAPTCHA pass as proof that a visitor is human.
A CAPTCHA pass means the session completed the proof step. It does not prove the session was human.
That distinction matters.
The dashboard deliberately uses wording such as:
Bot Guard is a layered system. Some weak bots are handled before CAPTCHA. Some suspicious JavaScript-capable sessions reach CAPTCHA. Some complete the proof step. Some fail. Some vanish. Some are temporarily trusted and later re-evaluated.
The new dashboard is built around that model.
The traffic journey is now much clearer
The new funnel chart is one of the most useful parts of the dashboard.
It shows the broad journey:
Release type: Major update
This release adds the new XF Bot Guard Dashboard, a visual single-page overview designed to show what Bot Guard is doing, why traffic is being challenged, where suspicious activity is coming from, and whether the system is healthy.
This is not just a prettier log page.
The dashboard is designed to tell the full Bot Guard story:
- what protected traffic Bot Guard saw;
- what was handled before CAPTCHA;
- what reached the CAPTCHA;
- what passed, failed, or never completed the challenge;
- why sessions were considered suspicious;
- which routes are under pressure;
- what crawlers and edge systems are doing;
- whether the underlying telemetry and cleanup systems look healthy.
The screenshot above only shows part of it. There is quite a bit more further down the page, including traffic journey charts, challenge outcomes, interstitial/browser proof activity, risk signals, route pressure, CAPTCHA trust-window behaviour, crawler health, Cloudflare Edge Enforcement status, system health, and raw drill-down links.
After upgrading, go to:
Admin Control Panel -> Add-ons -> XF Bot Guard -> Dashboard
And enjoy.
Changes
- Added a new single-page visual Dashboard for XF Bot Guard.
- Added dashboard charts using locally bundled Apache ECharts.
- Added a clear overview section showing protected activity, challenged sessions, no CAPTCHA result sessions, CAPTCHA passes, current trusted sessions, crawler activity, and edge candidate/block counts.
- Added a traffic journey funnel showing the path from protected request through browser proof, risk checks, CAPTCHA challenge, CAPTCHA outcome, temporary trust, and rechallenge behaviour.
- Added challenge outcome reporting, including pass-only, fail-only, fail-then-pass, pending challenge, and no CAPTCHA result sessions.
- Added counter-based pressure trend charts for challenge/pass/fail activity.
- Added interstitial and browser validation reporting so site owners can see what is being handled before CAPTCHA.
- Added risk signal reporting, including top reason codes and risk score distribution.
- Added route pressure reporting to show which areas of the forum are attracting the most suspicious challenge activity.
- Added CAPTCHA trust-window reporting, including current trusted sessions and rechallenge behaviour after trust expiry.
- Added crawler health visibility, including known and verified crawler activity.
- Added Cloudflare Edge Enforcement visibility to the dashboard where the edge feature is available.
- Added system health and telemetry availability reporting.
- Added raw drill-down links from the dashboard back into the existing event log.
- Added configurable counter retention via the new Counter retention hours option.
- Changed counter cleanup so it now respects the configured counter retention option instead of always pruning after 48 hours.
- Improved handling of malformed requests with no User-Agent header so collector-token unavailability is handled cleanly without noisy server error logging.
- Improved dashboard table scrolling, chart spacing, chart expansion, and admin-page usability.
Before this release, XF Bot Guard already recorded a lot of useful information, but most of it lived in logs, counters, health pages, and specialised admin screens.
That was useful for debugging, but not ideal for quickly answering the big question:
Is Bot Guard working?
The new dashboard is intended to answer that quickly.
Instead of making you dig through raw events first, XF Bot Guard now gives you a visual summary of what it is seeing and how traffic is moving through the protection layers.
In plain terms, the dashboard helps show:
- how much protected traffic is being seen;
- how much suspicious traffic is reaching challenge logic;
- how much is failing or disappearing before completing CAPTCHA;
- which requests are likely automated, abandoned, or incompatible;
- which routes are attracting suspicious activity;
- which risk signals are causing challenges;
- whether crawlers and Cloudflare Edge Enforcement are behaving as expected;
- whether your telemetry is complete enough for each report.
One important part of this dashboard is the wording.
XF Bot Guard does not present a CAPTCHA pass as proof that a visitor is human.
A CAPTCHA pass means the session completed the proof step. It does not prove the session was human.
That distinction matters.
The dashboard deliberately uses wording such as:
- No CAPTCHA result
- Pending challenge
- Temporary trust window
- Maximum possible false-positive ceiling
- CAPTCHA pass is not a human verdict
Bot Guard is a layered system. Some weak bots are handled before CAPTCHA. Some suspicious JavaScript-capable sessions reach CAPTCHA. Some complete the proof step. Some fail. Some vanish. Some are temporarily trusted and later re-evaluated.
The new dashboard is built around that model.
The traffic journey is now much clearer
The new funnel chart is one of the most useful parts of the dashboard.
It shows the broad journey:
Pour consulter le contenu, vous devez : Se connecter ou S'inscrire.
XF Bot Guard 1.2.3
Release type: Major update
Important: please read before upgrading
XF Bot Guard 1.2.3 is a major database, retention, reporting, and cleanup update.
This is not an update that very large forums should blindly apply without first choosing the right upgrade path.
For most small and medium forums, the normal XenForo add-on upgrade process should be fine.
For very large forums, this release may take considerably longer to upgrade because existing Bot Guard data needs to be migrated into the new structure, including internal hash storage changes and event-detail storage changes.
Before upgrading, decide which path makes sense:
If you run a very large forum and do not care about old Bot Guard telemetry, the clean uninstall/delete/install path may be the better option.
Review your retention settings after upgrading
XF Bot Guard 1.2.3 changes the retention model.
Some retention settings have moved from day-based retention to hour-based retention, and new defaults have been introduced.
After upgrading, review the new retention options and consider whether your previous settings still make sense.
The recommended starting point is to try the new defaults first.
New retention defaults
Raw event, visitor, session, and counter retention is capped at:
The new model is designed around:
If you previously increased raw retention mainly for dashboard visibility, you may no longer need to keep raw Bot Guard data for as long.
Similarly, if you previously decreased raw retention mainly to control database growth, you may wish to revise it now that cleanup and snapshot reporting have changed.
Thank you to @eva2000
A quick thank you to @eva2000 for an extensive and very useful data-growth and storage report, which helped inform the nature of this update.
That report highlighted the practical reality that very active forums can generate a large amount of Bot Guard telemetry, and included several actionable points around retention, cleanup, database growth, and long-term reporting.
XF Bot Guard 1.2.3 is largely about addressing that properly.
What this release does
This release makes the dashboard more practical long-term, especially on busy forums where keeping every raw Bot Guard event forever is not realistic.
It adds hourly dashboard snapshots, new retention options, safer cleanup behaviour, and internal database storage improvements designed to reduce database pressure over time.
In plain terms:
Release type: Major update
Important: please read before upgrading
XF Bot Guard 1.2.3 is a major database, retention, reporting, and cleanup update.
This is not an update that very large forums should blindly apply without first choosing the right upgrade path.
For most small and medium forums, the normal XenForo add-on upgrade process should be fine.
For very large forums, this release may take considerably longer to upgrade because existing Bot Guard data needs to be migrated into the new structure, including internal hash storage changes and event-detail storage changes.
Before upgrading, decide which path makes sense:
- Normal upgrade: preserves existing Bot Guard history, events, counters, sessions, visitors, and telemetry, but may take longer on large forums.
- Clean install: write down your Bot Guard configuration, uninstall/delete Bot Guard, install 1.2.3 fresh, then re-enter your configuration. This avoids migrating old Bot Guard telemetry, but historical Bot Guard data will be lost.
If you run a very large forum and do not care about old Bot Guard telemetry, the clean uninstall/delete/install path may be the better option.
Review your retention settings after upgrading
XF Bot Guard 1.2.3 changes the retention model.
Some retention settings have moved from day-based retention to hour-based retention, and new defaults have been introduced.
After upgrading, review the new retention options and consider whether your previous settings still make sense.
The recommended starting point is to try the new defaults first.
New retention defaults
| Data type | Default | Plain English |
|---|---|---|
| Raw event data | 336 hours | 14 days |
| Visitor data | 336 hours | 14 days |
| Session data | 336 hours | 14 days |
| Counter data | 336 hours | 14 days |
| Dashboard snapshots | 17,520 hours | 2 years |
| Zero-signal IP data | 2,160 hours | 90 days |
Raw event, visitor, session, and counter retention is capped at:
Code:
720 hours
= 30 days
The new model is designed around:
Code:
shorter raw data retention
+ longer dashboard snapshot retention
= useful long-term visibility without unnecessary raw database growth
If you previously increased raw retention mainly for dashboard visibility, you may no longer need to keep raw Bot Guard data for as long.
Similarly, if you previously decreased raw retention mainly to control database growth, you may wish to revise it now that cleanup and snapshot reporting have changed.
Thank you to @eva2000
A quick thank you to @eva2000 for an extensive and very useful data-growth and storage report, which helped inform the nature of this update.
That report highlighted the practical reality that very active forums can generate a large amount of Bot Guard telemetry, and included several actionable points around retention, cleanup, database growth, and long-term reporting.
XF Bot Guard 1.2.3 is largely about addressing that properly.
What this release does
This release makes the dashboard more practical long-term, especially on busy forums where keeping every raw Bot Guard event forever is not realistic.
It adds hourly dashboard snapshots, new retention options, safer cleanup behaviour, and internal database storage improvements designed to reduce database pressure over time.
In plain terms:
- the dashboard now has its own long-term snapshot data;
- raw event/session/visitor/counter data can be retained for a shorter period;
- longer-term dashboard reporting can still remain available;
- cleanup now works in safer batches;
- several internal hash fields are migrated to more compact binary storage;
- large forums get a more sustainable path forward, but should choose their upgrade path carefully.
Pour consulter le contenu, vous devez : Se connecter ou S'inscrire.
XF Bot Guard 1.2.4
Release type: Minor, with major reliability improvements
This release introduces intelligent event-detail buffering to help protect database performance during periods of heavy traffic or bot activity. XF Bot Guard can now automatically detect database pressure and temporarily shift write-heavy event-detail storage to disk, importing data back into the database smoothly over time without affecting protection decisions, telemetry, detection signals, suspicion scoring, or reporting.
The release also adds a dedicated Admin Control Panel section, granular admin permissions, improved Cloudflare Edge safeguards, and a range of reliability and maintenance improvements.
Added
Release type: bug fix
This patch resolves a dashboard snapshot cron issue introduced with event-detail buffering in XF Bot Guard 1.2.4.
In some cases, when buffered event details were still pending, the dashboard snapshot cron could attempt to write an internal status value that was too long for the snapshot status column. This could trigger a MySQL “Data too long for column 'status'” server error.
This patch also improves dashboard snapshot timing so snapshots are generated only for completed reporting hours, with the existing buffer grace period applied.
Fixed
Important upgrade notice for Cloudflare / trusted proxy customers: Before upgrading, please review the upgrade notes and ensure the existing Origin lockdown acknowledged for trusted proxy signals option is correctly set where applicable.
Release type: Minor feature release
This release adds a new Quick settings workflow to make XF Bot Guard easier to configure safely, especially for first rollout, normal production use, active bot attacks, and SEO-sensitive sites. The new workflow previews what will change before applying settings, highlights blockers and warnings, and preserves sensitive or site-specific configuration that should not be overwritten by a preset.
The release also includes bundled documentation, improved Admin Control Panel navigation, better event log filtering, safer trusted proxy signal handling, dashboard/UI polish, and Cloudflare Edge Enforcement reliability improvements.
Added
Important upgrade notes for existing customers:
This release focuses on practical controls for existing installations: safer social media unfurling, broader IP/CIDR/ASN handling, an observe-only rollout mode, clearer reporting for fake crawler claims, more accurate dashboard counts, and safer diagnostic output for support.
Added
Release type: minor
XF Bot Guard 1.2.8 is a protection, crawler-control, and operations release. It adds stronger bot-detection signals, safer AI crawler handling, configurable CAPTCHA and Edge behaviour, emergency origin protection, better investigation tools, and a broad documentation, performance, and hardening pass.
Contextual link canaries
XF Bot Guard can now place temporary canary aliases on a very small number of eligible public internal links. Real visitors are safely resolved back to the normal XenForo URL before navigation, while bots that scrape and fetch the canary URL directly create high-quality risk evidence. This helps catch crawlers that behave differently from real users without punishing verified crawlers or excluded traffic. This is enabled by default and can be controlled from the XF Bot Guard options.
Verified AI crawler and AI fetcher controls
AI crawler handling is now available with precise verification controls. XF Bot Guard can separately allow selected verified AI search crawlers and user-triggered AI fetchers, such as supported OpenAI and Anthropic sources, only when the official IP range and expected user-agent evidence both match. AI user-fetchers are human-aided services that retrieve content because a real user has requested it (for example, asking an AI assistant to summarise or analyse a page), which is different from AI crawlers that systematically collect content for model training or dataset building. This helps keep legitimate user-requested AI fetch behaviour working without blindly trusting every AI-looking bot, while still allowing you to control broader AI crawling activity separately. Use the verified AI crawler and AI user-fetcher options, with the main verified crawler option enabled.
Choose a Bot Guard CAPTCHA provider
Bot Guard challenges can now use their own CAPTCHA provider instead of always inheriting XenForo’s global CAPTCHA setting. Leave the setting blank to keep using the XenForo default, or select a supported XenForo-compatible provider specifically for Bot Guard challenges. This is useful if you want registration, contact forms, and bot challenges to use different CAPTCHA setups. Configure it under the XF Bot Guard CAPTCHA provider option.
Origin survival mode
Origin survival mode is a new emergency load-shedding option for bot storms or origin pressure. When enabled, it does not immediately start blocking visitors. Instead, XF Bot Guard continuously monitors a range of server health signals, such as CPU load, memory pressure, PHP worker availability, and request queue pressure, to determine when the origin is genuinely under strain. Only when those conditions are detected does it intelligently begin taking preventative action, temporarily returning lightweight 503 Retry-After responses to unknown, low-trust public page requests before they consume additional origin resources. This helps preserve availability for known users, trusted visitors, and verified bots during severe spikes, while temporarily shedding traffic that cannot be confidently identified. Because it can affect real unknown visitors during emergency conditions, it is disabled by default. Enable it from Quick Settings or the advanced Origin Survival options when needed.
Updated recommended presets
The recommended Quick Settings presets have been refreshed to account for newer protections, including canaries, light responses, verified AI crawler choices, crawler discovery paths, event detail handling, and origin survival mode. This makes the Cautious, Balanced, Active Bot Storm, and SEO-sensitive overlays safer and more complete. Use Quick Settings to preview and apply the posture that best matches your forum’s current risk level.
Remote CIDR JSON sources
You can now connect trusted remote HTTPS CIDR JSON sources for additional excluded networks or forced-challenge networks. XF Bot Guard refreshes these lists on a schedule, stores a local cache, and uses the local cache at request time. This is helpful for admins who maintain network ranges externally or want to sync trusted/challenged ranges without manually pasting CIDRs into XenForo. Add one trusted source per line in the remote CIDR source options.
Flag suspicious visitors from the Online page
Admins can now flag a suspicious visitor directly from XenForo’s Online page. A confirmed report records Bot Guard evidence and can add a configurable risk score for that visitor/session identity for the next 24 hours. This gives staff a practical way to turn live observations into protection signals without needing raw IP access. Use the Flag Visitor action on eligible online visitors, and adjust the report score in the XF Bot Guard options.
Sharper Event Log filtering and CSV export
The Event Log now has stronger filtering, including “not this” filters, below-threshold score searches, outside-date-range searches, guest/member/user filters, cohort filters, and filtered CSV export. This makes it much easier to investigate what happened, find patterns, and share a focused export without dumping the full log. Use the Event Log filters as normal, then export the currently filtered results when needed.
Faster dashboard snapshot reads
Dashboard snapshot reads have been optimised so XF Bot Guard now queries and aggregates only the metrics needed for the dashboard view. On busier forums, this should reduce unnecessary database work, lower PHP memory usage, and make dashboard views feel lighter. There is nothing to enable; the improvement is automatic after upgrade.
Configurable Cloudflare Edge thresholds
Cloudflare Edge candidate scoring is now configurable instead of being locked to fixed internal thresholds. This gives advanced admins more control over how strong local Bot Guard evidence must be before an IP becomes an Edge candidate, and how forgiving behaviour should be after a successful CAPTCHA pass. Most sites should keep the defaults. Advanced sites can adjust the Cloudflare Edge minimum score and Edge forgiveness priority cutoff options.
XenForo-to-XenForo unfurl support
The default URL unfurl light-response handling now recognises XenForo/2.* user agents. This helps XenForo forum link previews receive safe metadata-only responses without exposing protected page body content. Existing default pattern lists are updated automatically; customised lists can add XenForo/2.* manually if required.
Clearer request gate fail-open reporting
XF Bot Guard’s request gate is designed to fail open rather than risk taking your forum offline if an internal protection branch hits an unexpected error. In 1.2.8, those fail-open events are now recorded in a bounded, privacy-conscious way and surfaced through health checks and event logging. There is nothing to enable; if the health check warns about request gate fail-open evidence, review the related event log entries.
Documentation, code efficiency, and hardening
This release also includes a broad documentation and hardening pass covering cache/CDN behaviour, CAPTCHA provider behaviour, AI crawler handling, contextual canaries, origin survival mode, privacy notes, troubleshooting, and release checks. Under the hood, 1.2.8 also improves request safety, event export handling, origin pressure checks, test coverage, and general code efficiency. Nothing needs to be enabled here; it makes the add-on easier to operate and more resilient in edge cases.
XF Bot Guard 1.2.9
Release type: bug fix
Fixed an issue where XF Bot Guard incorrectly fell back to XenForo’s default CAPTCHA provider when correctly configured custom CAPTCHA providers were used. XenForo-compliant custom CAPTCHA providers now operate correctly.
XF Bot Guard 1.3.0
Release type: minor
Important upgrade notes for existing customers:
Direct upgrades to XF Bot Guard 1.3.1 require XF Bot Guard 1.2.9 (1020970) or newer to already be installed. If your site is running an older XF Bot Guard version, upgrade through a bridge release that still contains the older legacy migrations first, confirm that upgrade completes successfully, then install 1.3.1. Customers already on 1.2.9, 1.3.0 or newer can upgrade normally.
Release type: minor
XF Bot Guard 1.3.1 focuses on safer upgrades, clearer dashboard reporting, more reliable contextual link canaries, better localisation support, privacy-safe diagnostics and lower database overhead. Most changes apply automatically after upgrading, with no new settings required.
Safer direct upgrades from supported versions
XF Bot Guard now clearly enforces the supported direct-upgrade baseline of 1.2.9 or newer. This prevents very old installs from attempting a direct jump into a newer schema without the legacy migration steps they still need. If your install is already on 1.2.9 or newer, just upgrade as normal; if it is older, upgrade through the required bridge release first.
Clearer dashboard snapshot coverage warnings
The dashboard now warns when the selected time range does not yet have complete trusted snapshot coverage. This helps avoid mistaking incomplete charts for “no bot activity” when the issue is actually missing, delayed or not-yet-built dashboard snapshots. Open the dashboard as normal; if a warning appears, check the selected range, snapshot retention, the hourly snapshot cron and health/status.
More accurate Observe-only dashboard reporting
Observe-only dashboard reporting now better matches the live enforcement dashboard while still keeping would-action data separate from real enforcement data. Route pressure and route outcome metrics now use the correct observe-only snapshot groups, so admins can more confidently test settings before enabling active enforcement. Enable Observe-only as usual, then review the dashboard’s would-challenge, would-deny and route-pressure sections.
More reliable contextual link canaries
Contextual link canary instrumentation has been rebuilt to modify eligible anchor tags without reserialising the whole HTML document. This makes canaries safer around scripts, styles, comments, templates, titles, textarea content, uppercase tags, unquoted attributes and more complex page markup. If contextual link canaries are already enabled, the fix applies automatically; otherwise enable them from XF Bot Guard’s settings when you want this extra bot-detection layer.
Faster database checks on busy forums
Several high-frequency queries have been tightened up to reduce unnecessary database work. This includes more index-friendly controller checks, deduplicated event-count queries, faster existence checks and request-level schema caching. There is nothing to enable; after upgrading, the improved query paths are used automatically.
Fully phrased admin and dashboard text
More XF Bot Guard admin, dashboard, health, Cloudflare, setup and JavaScript-facing text now uses XenForo phrases. This makes the add-on easier to translate, customise and keep consistent with your forum’s language setup. Use XenForo’s normal phrase/language tools to adjust wording where needed.
Privacy-safe browser support diagnostics
The browser debug buffer is now off by default and only activates when debug mode is explicitly set to true. When enabled for support troubleshooting, it keeps a small, sanitised recent log and avoids exposing sensitive values such as visitor IDs, tokens, CSRF values, return URLs, request paths, query strings, script URLs, localStorage values and raw browser signals. Leave it off for normal use; only enable it temporarily if support asks you to.
Cleaner supported upgrade path
Old legacy migration and compatibility-only paths that are no longer part of the supported direct-upgrade range have been retired. This reduces upgrade complexity and keeps the current code focused on supported installations instead of carrying old transitional storage, hash and option-repair logic forever. No setting is required; the only thing to remember is that installs older than 1.2.9 must upgrade through the required bridge release first.
XF Bot Guard 1.3.2
Release type: minor
XF Bot Guard 1.3.2 focuses on lower server load, smarter forum-specific bot detection, and better stability on larger sites. It expands cache-backed reads across more protection hot-paths, adds new Link Chronology and dwell-time behavioural signals, improves dashboard reliability, and adds a new health check for Board URL origin issues.
Faster protection with cheaper hot-path reads
XF Bot Guard already used XenForo’s application cache on its primary hot-path. In 1.3.2, that cache-backed approach has been extended across every compatible hot-path, including areas such as counters, verified crawler lookups, network matching, light-response pattern parsing, contextual link canaries, and Link Chronology state. In plain terms, this means Bot Guard can avoid many repeated database read queries during busy traffic by reusing short-lived cached data where available.
There is nothing new to enable inside Bot Guard. If XenForo application cache is configured and hydrated, Bot Guard will use it automatically. If not, Bot Guard remains database-backed and continues to work normally, but busier forums should strongly consider enabling XenForo application cache. Memcached is the preferred recommendation, followed by Redis. APC/APCu can be useful for smaller single-server installs, but it is not the preferred recommendation for larger or busier communities.
Smarter forum-specific link journey checks
Link Chronology helps Bot Guard tell the difference between normal browsing and scraper-style URL traversal. When a visitor views a protected page, Bot Guard keeps a short-lived record of the protected internal links that were actually visible on that page. On the next protected request, it can tell whether the visitor is following a link they were recently shown, reloading the same page, or jumping directly to another protected URL that was not part of their recent journey.
This matters because real users usually browse through visible forum links, while bots often work from URL lists, guessed paths, scraped routes, or direct protected-page traversal. The signal is tailored to each forum because it is built from that forum’s actual pages, links, and route structure. It is enabled by default and can be tuned or disabled from the Link Chronology options. It adds bounded risk only; it does not hard-block anyone by itself.
Forum-specific dwell-time learning
Dwell-time learning gives Link Chronology a better idea of what “normal” browsing looks like on each individual community. Bot Guard samples eligible registered-user navigation to learn rough local bounds for how long people usually spend between protected page transitions. A fast-moving support forum, a long-form discussion forum, and a media-heavy community may all have different normal behaviour, so Bot Guard learns from the forum itself rather than relying on one fixed global rule.
This is designed to be privacy-preserving. Bot Guard does not need to identify individual members, store personal browsing histories, or know what someone personally read to build this model. It uses local aggregate behaviour to understand the forum’s normal rhythm, then adds bounded risk only when a protected link journey is unusually fast or unusually slow compared with that forum’s own normal pattern. If there is not enough local sample data yet, dwell-time scoring simply does not apply.
More reliable dashboard on larger sites
The dashboard now avoids loading unbounded route and timing metric rows into memory. Route reports are limited to the most relevant routes, route outcomes are fetched only for those selected routes, and timing summaries are calculated in a more memory-safe way.
This resolves dashboard memory exhaustion on larger or busier installations. There is nothing to enable; upgrade and use the dashboard as normal.
Board URL origin health check
The health check now validates XenForo’s Board URL origin against the current public request origin. This helps catch common configuration problems such as HTTP/HTTPS mismatch, wrong host, www/non-www mismatch, port mismatch, or proxy handling issues.
This matters because origin mismatches can affect same-origin browser validation, challenge URLs, and asset URLs. To use it, open the XF Bot Guard health/status page after upgrading and review the Board URL origin result. If it reports a problem, fix XenForo’s Board URL or your proxy HTTPS/host configuration, then re-run the check.
More consistent members online counts
Bot Guard’s online count adjustment now uses one consistent aggregate of XenForo session activity instead of combining separate reads that could briefly disagree under movement or load.
This fixes transient inconsistent public online totals, including member, guest, and challenged counts. It applies automatically when Bot Guard is enabled and the online count adjustment option is enabled.
Release type: Minor, with major reliability improvements
This release introduces intelligent event-detail buffering to help protect database performance during periods of heavy traffic or bot activity. XF Bot Guard can now automatically detect database pressure and temporarily shift write-heavy event-detail storage to disk, importing data back into the database smoothly over time without affecting protection decisions, telemetry, detection signals, suspicion scoring, or reporting.
The release also adds a dedicated Admin Control Panel section, granular admin permissions, improved Cloudflare Edge safeguards, and a range of reliability and maintenance improvements.
Added
- Added a dedicated XF Bot Guard section in the Admin Control Panel, with direct links for the dashboard, event log, health/status, Cloudflare Edge tools, Edge candidates, and sync logs.
- Added dedicated XF Bot Guard admin permissions, making it easier to control who can view logs, manage Bot Guard, manage Cloudflare Edge, and access sensitive investigation details.
- Added safer separation between general Bot Guard visibility and sensitive investigation data such as request paths, hashes, raw IP storage state, crawler diagnostics, Edge candidate detail, and sync diagnostics.
- Added event-detail buffering to reduce database pressure during high-traffic or bot-heavy periods.
- Added automatic database pressure detection so Bot Guard can buffer supplementary event details when needed, while keeping important protection decisions immediate.
- Added health/status visibility for event-detail buffering, database pressure state, and pending buffer activity.
- Added clearer admin messages when recent event detail is still being processed.
- Added documentation covering the new admin permission model, event-detail buffering, health checks, cron flushing, and troubleshooting.
- Improved Admin Control Panel permission checks so Bot Guard pages and actions are protected directly, rather than relying on menu visibility or broad XenForo permissions.
- Improved Cloudflare Edge safety by limiting setup, credentials, repair, sync, disable/remove, and candidate changes to admins with the dedicated Edge management permission.
- Improved health/status and dashboard behaviour so normal page loads no longer perform Cloudflare diagnostics, create Cloudflare configuration rows, or mutate compatibility state.
- Improved dashboard snapshot reliability by waiting for pending buffered event details before processing affected hours.
- Improved reason-code filtering with clearer warnings when very recent buffered details may not yet be searchable.
Release type: bug fix
This patch resolves a dashboard snapshot cron issue introduced with event-detail buffering in XF Bot Guard 1.2.4.
In some cases, when buffered event details were still pending, the dashboard snapshot cron could attempt to write an internal status value that was too long for the snapshot status column. This could trigger a MySQL “Data too long for column 'status'” server error.
This patch also improves dashboard snapshot timing so snapshots are generated only for completed reporting hours, with the existing buffer grace period applied.
Fixed
- Fixed a dashboard snapshot cron error that could occur when recent event-detail buffer files were still pending import.
- Fixed an internal snapshot status value that could exceed the expected database column length.
- Fixed dashboard snapshot eligibility so the current in-progress hour is not processed too early.
Important upgrade notice for Cloudflare / trusted proxy customers: Before upgrading, please review the upgrade notes and ensure the existing Origin lockdown acknowledged for trusted proxy signals option is correctly set where applicable.
Release type: Minor feature release
This release adds a new Quick settings workflow to make XF Bot Guard easier to configure safely, especially for first rollout, normal production use, active bot attacks, and SEO-sensitive sites. The new workflow previews what will change before applying settings, highlights blockers and warnings, and preserves sensitive or site-specific configuration that should not be overwritten by a preset.
The release also includes bundled documentation, improved Admin Control Panel navigation, better event log filtering, safer trusted proxy signal handling, dashboard/UI polish, and Cloudflare Edge Enforcement reliability improvements.
Added
- Added a new Quick settings page in the XF Bot Guard Admin Control Panel section.
- Added guided configuration profiles for cautious first rollout, balanced production use, active bot storm protection, and SEO-sensitive overlay protection.
- Added a settings preview before applying recommended profiles, making it easier to see exactly what will change.
- Added checks for blockers, warnings, and preserved settings before recommended settings are applied.
- Added bundled local documentation covering installation, upgrading, setup, protected areas, exclusions, crawler handling, cache/CDN behaviour, dashboard use, event logs, Cloudflare Edge Enforcement, privacy, retention, troubleshooting, and testing.
- Added improved reason-code lookup support for event log filtering and reporting.
- Improved the Admin Control Panel navigation by organising Bot Guard pages into clearer sections for Quick settings, Dashboard, Advanced tools, and Cloudflare Edge Enforcement.
- Improved recommended-settings safety by preserving sensitive and site-specific options such as Cloudflare Edge settings, raw IP storage, custom exclusions, protected routes, content types, user groups, IP exclusions, and custom trusted crawler domains.
- Improved setup readiness checks around cache behaviour, CAPTCHA availability, Bot Guard assets, template modifications, crawler data, and required Bot Guard data stores.
- Improved raw event log filtering with clearer selectable filters for decisions, event types, and reason codes.
- Improved event log investigation tools with better support for reason-code filtering and guarded route/path searches.
- Improved dashboard presentation and admin styling, including better dark-mode-friendly chart behaviour and more consistent XenForo theme integration.
- Improved table and admin page usability with better scrolling, layout, and action-link handling.
- Improved Cloudflare Edge Enforcement sync handling, including clearer handling of in-progress operations, rate limits, deleted candidates, suppressed candidates, pending states, and retry states.
- Improved Cloudflare Edge sync logs so progress and failure states are easier to understand.
- Improved trusted proxy safeguards for Cloudflare and other trusted proxy setups.
- Changed the Bot Guard add-on links to focus on built-in documentation and support, rather than listing multiple direct admin URLs.
- Changed the options layout to make related settings easier to find and understand.
- Cloudflare and trusted proxy customers should review the important upgrade notice above before upgrading.
- Minimum XenForo and PHP requirements are unchanged.
- Default option values are unchanged.
- Existing retained event data may be backfilled for improved reason-code filtering during the upgrade process.
Important upgrade notes for existing customers:
- Social media URL previews: This release adds optional, default-off metadata-only URL preview handling for selected social media and messaging preview agents, including WhatsApp. If link previews for protected public pages matter on your site, review the new light valid response options after upgrading.
- Expanded network controls: IP/CIDR exclusions now support decimal ASNs, and a new forced challenge network list has been added. Use decimal ASN syntax such as 32934, not AS32934.
This release focuses on practical controls for existing installations: safer social media unfurling, broader IP/CIDR/ASN handling, an observe-only rollout mode, clearer reporting for fake crawler claims, more accurate dashboard counts, and safer diagnostic output for support.
Added
- Added optional light valid responses for selected URL unfurl user agents.
- Added a configurable user-agent pattern list for metadata-only URL preview handling, with included patterns for Facebook/Meta, X/Twitter Cards, LinkedIn, Slack, Discord, Telegram, Yahoo Mail, Bluesky, WhatsApp and Skype previews.
- Added ASN support to Bot Guard network-list matching.
- Added a new Forced challenge IPs/CIDRs/ASNs option for deliberately challenging selected IP addresses, CIDR ranges or decimal ASNs.
- Added a local ASN range cache, refreshed by the scheduled crawler/network refresh process, so request-time matching can use local CIDR ranges instead of live lookups.
- Added an optional Observe-only overlay for testing what Bot Guard would have done without taking visitor-altering actions.
- Added observe-only event types for would-have-challenged, would-have-denied, would-have-shown browser validation, would-have-served a light response, and would-have-synced to Cloudflare outcomes.
- Added privacy-safe reporting for requests that claim to be known crawlers or bots but still reach CAPTCHA or feed deny handling.
- Added dashboard reporting for claimed crawler/bot challenge activity.
- Added dashboard reporting for URL unfurl light-response activity.
- Added a redacted support bundle workflow for admins with the sensitive Bot Guard permission.
- Added support bundle access from Health/status, filtered raw event log views, and individual event detail views.
- Improved dashboard accuracy for retained risk, route, outcome and timing metrics.
- Improved dashboard timing panels with recent decision timing metadata and nearest-rank 95th percentile calculations.
- Improved event log filtering so the new light-response, observe-only and crawler-claim events are easier to investigate.
- Improved Cloudflare Edge Enforcement status reporting, including clearer saved dry-run versus effective dry-run state.
- Improved Cloudflare sync logs and failure handling around lock checks, rate limits, pending states, deleted candidates, suppressed candidates and retry states.
- Improved Health/status reporting for ASN range cache state, secure random generator availability, Cloudflare diagnostics and dashboard snapshot health.
- Improved compatibility coverage for supported XenForo 2.1, 2.2 and 2.3 installations.
- Improved continued PHP 7.2+ compatibility checks.
- Changed Cloudflare Edge Enforcement to use effective dry-run while Observe-only is active, without changing the saved Cloudflare dry-run option.
- Changed the deprecated strict no-proof challenge option out of the active option set.
- Hardened Cloudflare API, sync log, health-check and support-output redaction for API tokens, credentials, cookies, CSRF tokens, URL credentials and private-key style values.
- Hardened browser validation replay protection with short-lived, one-use, session-backed collector tokens.
- Hardened event audit text handling so malformed request-derived encoding is cleaned before storage.
- Hardened Cloudflare token diagnostics so undecryptable stored token material is handled more clearly after local key-material changes.
- Minimum XenForo and PHP requirements are unchanged.
- Observe-only is off by default.
- Light valid responses for selected URL unfurl user agents are off by default.
- If URL previews are important for your forum, review and test the new light valid response options after upgrading.
- If you use IP/CIDR exclusions, review the renamed Excluded IPs/CIDRs/ASNs option after upgrading.
- If you add ASN entries, use plain decimal ASN syntax such as 32934, not AS32934.
- ASN entries depend on the scheduled refresh process. If an ASN has no active cached ranges yet, it cannot match request IPs until the cache has been populated.
- If you use Cloudflare Edge Enforcement, note that enabling Observe-only forces Cloudflare sync into effective dry-run until Observe-only is disabled.
- After upgrading, review Health/status, especially if you use Cloudflare Edge Enforcement, ASN-based network controls, URL unfurl handling, or trusted proxy signals.
Release type: minor
XF Bot Guard 1.2.8 is a protection, crawler-control, and operations release. It adds stronger bot-detection signals, safer AI crawler handling, configurable CAPTCHA and Edge behaviour, emergency origin protection, better investigation tools, and a broad documentation, performance, and hardening pass.
Contextual link canaries
XF Bot Guard can now place temporary canary aliases on a very small number of eligible public internal links. Real visitors are safely resolved back to the normal XenForo URL before navigation, while bots that scrape and fetch the canary URL directly create high-quality risk evidence. This helps catch crawlers that behave differently from real users without punishing verified crawlers or excluded traffic. This is enabled by default and can be controlled from the XF Bot Guard options.
Verified AI crawler and AI fetcher controls
AI crawler handling is now available with precise verification controls. XF Bot Guard can separately allow selected verified AI search crawlers and user-triggered AI fetchers, such as supported OpenAI and Anthropic sources, only when the official IP range and expected user-agent evidence both match. AI user-fetchers are human-aided services that retrieve content because a real user has requested it (for example, asking an AI assistant to summarise or analyse a page), which is different from AI crawlers that systematically collect content for model training or dataset building. This helps keep legitimate user-requested AI fetch behaviour working without blindly trusting every AI-looking bot, while still allowing you to control broader AI crawling activity separately. Use the verified AI crawler and AI user-fetcher options, with the main verified crawler option enabled.
Choose a Bot Guard CAPTCHA provider
Bot Guard challenges can now use their own CAPTCHA provider instead of always inheriting XenForo’s global CAPTCHA setting. Leave the setting blank to keep using the XenForo default, or select a supported XenForo-compatible provider specifically for Bot Guard challenges. This is useful if you want registration, contact forms, and bot challenges to use different CAPTCHA setups. Configure it under the XF Bot Guard CAPTCHA provider option.
Origin survival mode
Origin survival mode is a new emergency load-shedding option for bot storms or origin pressure. When enabled, it does not immediately start blocking visitors. Instead, XF Bot Guard continuously monitors a range of server health signals, such as CPU load, memory pressure, PHP worker availability, and request queue pressure, to determine when the origin is genuinely under strain. Only when those conditions are detected does it intelligently begin taking preventative action, temporarily returning lightweight 503 Retry-After responses to unknown, low-trust public page requests before they consume additional origin resources. This helps preserve availability for known users, trusted visitors, and verified bots during severe spikes, while temporarily shedding traffic that cannot be confidently identified. Because it can affect real unknown visitors during emergency conditions, it is disabled by default. Enable it from Quick Settings or the advanced Origin Survival options when needed.
Updated recommended presets
The recommended Quick Settings presets have been refreshed to account for newer protections, including canaries, light responses, verified AI crawler choices, crawler discovery paths, event detail handling, and origin survival mode. This makes the Cautious, Balanced, Active Bot Storm, and SEO-sensitive overlays safer and more complete. Use Quick Settings to preview and apply the posture that best matches your forum’s current risk level.
Remote CIDR JSON sources
You can now connect trusted remote HTTPS CIDR JSON sources for additional excluded networks or forced-challenge networks. XF Bot Guard refreshes these lists on a schedule, stores a local cache, and uses the local cache at request time. This is helpful for admins who maintain network ranges externally or want to sync trusted/challenged ranges without manually pasting CIDRs into XenForo. Add one trusted source per line in the remote CIDR source options.
Flag suspicious visitors from the Online page
Admins can now flag a suspicious visitor directly from XenForo’s Online page. A confirmed report records Bot Guard evidence and can add a configurable risk score for that visitor/session identity for the next 24 hours. This gives staff a practical way to turn live observations into protection signals without needing raw IP access. Use the Flag Visitor action on eligible online visitors, and adjust the report score in the XF Bot Guard options.
Sharper Event Log filtering and CSV export
The Event Log now has stronger filtering, including “not this” filters, below-threshold score searches, outside-date-range searches, guest/member/user filters, cohort filters, and filtered CSV export. This makes it much easier to investigate what happened, find patterns, and share a focused export without dumping the full log. Use the Event Log filters as normal, then export the currently filtered results when needed.
Faster dashboard snapshot reads
Dashboard snapshot reads have been optimised so XF Bot Guard now queries and aggregates only the metrics needed for the dashboard view. On busier forums, this should reduce unnecessary database work, lower PHP memory usage, and make dashboard views feel lighter. There is nothing to enable; the improvement is automatic after upgrade.
Configurable Cloudflare Edge thresholds
Cloudflare Edge candidate scoring is now configurable instead of being locked to fixed internal thresholds. This gives advanced admins more control over how strong local Bot Guard evidence must be before an IP becomes an Edge candidate, and how forgiving behaviour should be after a successful CAPTCHA pass. Most sites should keep the defaults. Advanced sites can adjust the Cloudflare Edge minimum score and Edge forgiveness priority cutoff options.
XenForo-to-XenForo unfurl support
The default URL unfurl light-response handling now recognises XenForo/2.* user agents. This helps XenForo forum link previews receive safe metadata-only responses without exposing protected page body content. Existing default pattern lists are updated automatically; customised lists can add XenForo/2.* manually if required.
Clearer request gate fail-open reporting
XF Bot Guard’s request gate is designed to fail open rather than risk taking your forum offline if an internal protection branch hits an unexpected error. In 1.2.8, those fail-open events are now recorded in a bounded, privacy-conscious way and surfaced through health checks and event logging. There is nothing to enable; if the health check warns about request gate fail-open evidence, review the related event log entries.
Documentation, code efficiency, and hardening
This release also includes a broad documentation and hardening pass covering cache/CDN behaviour, CAPTCHA provider behaviour, AI crawler handling, contextual canaries, origin survival mode, privacy notes, troubleshooting, and release checks. Under the hood, 1.2.8 also improves request safety, event export handling, origin pressure checks, test coverage, and general code efficiency. Nothing needs to be enabled here; it makes the add-on easier to operate and more resilient in edge cases.
XF Bot Guard 1.2.9
Release type: bug fix
Fixed an issue where XF Bot Guard incorrectly fell back to XenForo’s default CAPTCHA provider when correctly configured custom CAPTCHA providers were used. XenForo-compliant custom CAPTCHA providers now operate correctly.
XF Bot Guard 1.3.0
Release type: minor
- Sets the X-Robots-Tag: noindex, nofollow, noarchive header on bot-guard/ routes, making a stronger effort to ensure well-behaved bots ignore Bot Guard routes instead of attempting to crawl AJAX endpoints and challenge pages.
- Introduces a new option, Preserve inactive XenForo CAPTCHA keys. When enabled, which is off by default, this adjusts the standard XenForo CAPTCHA options area so inactive CAPTCHA configurations are preserved instead of being removed. This allows multiple CAPTCHA configurations to be entered and retained, so one can be used for XenForo generally while another can be selected specifically for Bot Guard. Without this option, XenForo only retains the active CAPTCHA configuration and silently deletes the others.
- Data pruning now handles much larger data clean-up volumes on a far more frequent cycle. This should better support very large sites and datasets. If your forum is currently behind on data pruning, it should now become more proactive in keeping table sizes within the configured retention periods. Initial pruning may still take some time, as it still does not execute everything at once to avoid unnecessary server load, but it will now be far more aggressive about keeping retained data under control.
- Fixes a bug where nginx rewrite configurations could cause Bot Guard to miscalculate its collector nonce paths. This caused a nonce mismatch for every visitor, resulting in Bot Guard challenging every single visitor. nginx rewrite configurations are now specifically accounted for, and Bot Guard should now operate cleanly on those installation configurations.
Important upgrade notes for existing customers:
Direct upgrades to XF Bot Guard 1.3.1 require XF Bot Guard 1.2.9 (1020970) or newer to already be installed. If your site is running an older XF Bot Guard version, upgrade through a bridge release that still contains the older legacy migrations first, confirm that upgrade completes successfully, then install 1.3.1. Customers already on 1.2.9, 1.3.0 or newer can upgrade normally.
Release type: minor
XF Bot Guard 1.3.1 focuses on safer upgrades, clearer dashboard reporting, more reliable contextual link canaries, better localisation support, privacy-safe diagnostics and lower database overhead. Most changes apply automatically after upgrading, with no new settings required.
Safer direct upgrades from supported versions
XF Bot Guard now clearly enforces the supported direct-upgrade baseline of 1.2.9 or newer. This prevents very old installs from attempting a direct jump into a newer schema without the legacy migration steps they still need. If your install is already on 1.2.9 or newer, just upgrade as normal; if it is older, upgrade through the required bridge release first.
Clearer dashboard snapshot coverage warnings
The dashboard now warns when the selected time range does not yet have complete trusted snapshot coverage. This helps avoid mistaking incomplete charts for “no bot activity” when the issue is actually missing, delayed or not-yet-built dashboard snapshots. Open the dashboard as normal; if a warning appears, check the selected range, snapshot retention, the hourly snapshot cron and health/status.
More accurate Observe-only dashboard reporting
Observe-only dashboard reporting now better matches the live enforcement dashboard while still keeping would-action data separate from real enforcement data. Route pressure and route outcome metrics now use the correct observe-only snapshot groups, so admins can more confidently test settings before enabling active enforcement. Enable Observe-only as usual, then review the dashboard’s would-challenge, would-deny and route-pressure sections.
More reliable contextual link canaries
Contextual link canary instrumentation has been rebuilt to modify eligible anchor tags without reserialising the whole HTML document. This makes canaries safer around scripts, styles, comments, templates, titles, textarea content, uppercase tags, unquoted attributes and more complex page markup. If contextual link canaries are already enabled, the fix applies automatically; otherwise enable them from XF Bot Guard’s settings when you want this extra bot-detection layer.
Faster database checks on busy forums
Several high-frequency queries have been tightened up to reduce unnecessary database work. This includes more index-friendly controller checks, deduplicated event-count queries, faster existence checks and request-level schema caching. There is nothing to enable; after upgrading, the improved query paths are used automatically.
Fully phrased admin and dashboard text
More XF Bot Guard admin, dashboard, health, Cloudflare, setup and JavaScript-facing text now uses XenForo phrases. This makes the add-on easier to translate, customise and keep consistent with your forum’s language setup. Use XenForo’s normal phrase/language tools to adjust wording where needed.
Privacy-safe browser support diagnostics
The browser debug buffer is now off by default and only activates when debug mode is explicitly set to true. When enabled for support troubleshooting, it keeps a small, sanitised recent log and avoids exposing sensitive values such as visitor IDs, tokens, CSRF values, return URLs, request paths, query strings, script URLs, localStorage values and raw browser signals. Leave it off for normal use; only enable it temporarily if support asks you to.
Cleaner supported upgrade path
Old legacy migration and compatibility-only paths that are no longer part of the supported direct-upgrade range have been retired. This reduces upgrade complexity and keeps the current code focused on supported installations instead of carrying old transitional storage, hash and option-repair logic forever. No setting is required; the only thing to remember is that installs older than 1.2.9 must upgrade through the required bridge release first.
XF Bot Guard 1.3.2
Release type: minor
XF Bot Guard 1.3.2 focuses on lower server load, smarter forum-specific bot detection, and better stability on larger sites. It expands cache-backed reads across more protection hot-paths, adds new Link Chronology and dwell-time behavioural signals, improves dashboard reliability, and adds a new health check for Board URL origin issues.
Faster protection with cheaper hot-path reads
XF Bot Guard already used XenForo’s application cache on its primary hot-path. In 1.3.2, that cache-backed approach has been extended across every compatible hot-path, including areas such as counters, verified crawler lookups, network matching, light-response pattern parsing, contextual link canaries, and Link Chronology state. In plain terms, this means Bot Guard can avoid many repeated database read queries during busy traffic by reusing short-lived cached data where available.
There is nothing new to enable inside Bot Guard. If XenForo application cache is configured and hydrated, Bot Guard will use it automatically. If not, Bot Guard remains database-backed and continues to work normally, but busier forums should strongly consider enabling XenForo application cache. Memcached is the preferred recommendation, followed by Redis. APC/APCu can be useful for smaller single-server installs, but it is not the preferred recommendation for larger or busier communities.
Smarter forum-specific link journey checks
Link Chronology helps Bot Guard tell the difference between normal browsing and scraper-style URL traversal. When a visitor views a protected page, Bot Guard keeps a short-lived record of the protected internal links that were actually visible on that page. On the next protected request, it can tell whether the visitor is following a link they were recently shown, reloading the same page, or jumping directly to another protected URL that was not part of their recent journey.
This matters because real users usually browse through visible forum links, while bots often work from URL lists, guessed paths, scraped routes, or direct protected-page traversal. The signal is tailored to each forum because it is built from that forum’s actual pages, links, and route structure. It is enabled by default and can be tuned or disabled from the Link Chronology options. It adds bounded risk only; it does not hard-block anyone by itself.
Forum-specific dwell-time learning
Dwell-time learning gives Link Chronology a better idea of what “normal” browsing looks like on each individual community. Bot Guard samples eligible registered-user navigation to learn rough local bounds for how long people usually spend between protected page transitions. A fast-moving support forum, a long-form discussion forum, and a media-heavy community may all have different normal behaviour, so Bot Guard learns from the forum itself rather than relying on one fixed global rule.
This is designed to be privacy-preserving. Bot Guard does not need to identify individual members, store personal browsing histories, or know what someone personally read to build this model. It uses local aggregate behaviour to understand the forum’s normal rhythm, then adds bounded risk only when a protected link journey is unusually fast or unusually slow compared with that forum’s own normal pattern. If there is not enough local sample data yet, dwell-time scoring simply does not apply.
More reliable dashboard on larger sites
The dashboard now avoids loading unbounded route and timing metric rows into memory. Route reports are limited to the most relevant routes, route outcomes are fetched only for those selected routes, and timing summaries are calculated in a more memory-safe way.
This resolves dashboard memory exhaustion on larger or busier installations. There is nothing to enable; upgrade and use the dashboard as normal.
Board URL origin health check
The health check now validates XenForo’s Board URL origin against the current public request origin. This helps catch common configuration problems such as HTTP/HTTPS mismatch, wrong host, www/non-www mismatch, port mismatch, or proxy handling issues.
This matters because origin mismatches can affect same-origin browser validation, challenge URLs, and asset URLs. To use it, open the XF Bot Guard health/status page after upgrading and review the Board URL origin result. If it reports a problem, fix XenForo’s Board URL or your proxy HTTPS/host configuration, then re-run the check.
More consistent members online counts
Bot Guard’s online count adjustment now uses one consistent aggregate of XenForo session activity instead of combining separate reads that could briefly disagree under movement or load.
This fixes transient inconsistent public online totals, including member, guest, and challenged counts. It applies automatically when Bot Guard is enabled and the online count adjustment option is enabled.
Pour consulter le contenu, vous devez : Se connecter ou S'inscrire.

