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 :
- 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.
![[OzzModz] New Posts Button Bottom Of Thread 2.0.2](https://www.societyfrenchmodding.net/data/attachments/4/4605-953bc1282090c6a0955567e32267081a.jpg){kind=small}