I allow guests to post threads and replies in certain forums, and whilst I block just about everything known to man at Cloudflare already, and other means, at times something automated can still slip through and I want to basically close, what I think, is the last hole in my strategy.
If I use this Security Rule:
Code:
(http.request.method eq "POST" and (http.request.uri.path contains "/add-reply" or http.request.uri.path contains "/post-thread" or http.request.uri.path contains "/post/") and not http.cookie contains "xf_user" and not http.referer contains "myptsd.com")
I just want to confirm whether I have the /create-thread and /add-reply correct so it blocks on a Managed Challenge automated spam. Why this last approach? Because I have had a few occasions where someone has use a valid ISP IP and spammed a hundred automated comments onto the site. Whilst they all endup in moderation from other rules, I would prefer automation can't do this to begin with, hence this final rule.
I added "and" logic to ensure it targets the right situations, excludes logged in users and added referrer mydomain to block direct bot posts.
Thoughts from the experts?
Based on the XenForo routing:
/post-thread — Correct.
The URL for creating a new thread is forums/{forum-slug}.{id}/post-thread, which maps to ForumController::actionPostThread(). Your contains "/post-thread" will match this.
/add-reply — Correct.
Thread replies POST to threads/{thread-slug}.{id}/add-reply, which maps to ThreadController::actionAddReply(). Same pattern is used for conversation replies at direct-messages/{id}/add-reply. Your contains "/add-reply" catches both.
/post/ — This one is problematic.
The route prefix for individual posts is posts (plural), so post URLs look like /posts/123/edit, /posts/123/react, etc. The substring /post/ won't match /posts/ — the s comes before the /. So this condition isn't really catching anything useful in default XenForo routing. If you intended it to catch post edits or other post actions, you'd want "/posts/" instead. However, post edits require authentication anyway, so it's less of a spam vector.
A few other thoughts on the overall approach:
Additional paths to consider.
If you allow guests to interact with profile posts, the path for posting on profiles uses /members/{name}.{id}/ with POST, and profile post comments use /profile-posts/{id}/add-comment. Depending on your setup you might want those too.
The referrer check is easily spoofed.
Bots that are sophisticated enough to bypass your other Cloudflare rules can trivially set a Referer header. It's a useful low-effort filter against dumb bots but won't stop anything determined. Still worth keeping as a layer.
The xf_user cookie check is solid for guest detection.
That cookie is only set on login, so it reliably distinguishes guests from logged-in users at the Cloudflare layer.
XenForo's own CSRF protection.
Keep in mind XF already requires a valid _xfToken on every POST. Automated bots that don't first load the form page and parse the token will get rejected by XF itself with a security error. If bots are getting past that, they're likely loading the page first (which would also set a valid referrer), meaning your referrer check won't help against those. The Managed Challenge is the real value-add here — it forces browser verification before the POST reaches XF at all.
Refined rule suggestion:
Code:
(http.request.method eq "POST"
and (http.request.uri.path contains "/add-reply"
or http.request.uri.path contains "/post-thread")
and not http.cookie contains "xf_user")
I'd drop the /post/ condition since it doesn't match anything useful, and consider dropping the referrer check since it's easily spoofed and could cause false positives (some privacy browsers/extensions strip referrers). The core logic of "POST to thread-creation or reply endpoints + no logged-in cookie = Managed Challenge" is clean and effective.
