Comments: Turnstile widget is rendered but its token is never verified server-side

[khoinguyenpham04]

This Roadmap discussion mirrors #1589: Comments: Turnstile widget is rendered but its token is never verified server-side.

Use this discussion to upvote the roadmap item and discuss priority, use cases, and product feedback. Keep implementation tracking, reproduction details, and PR-specific feedback on the source issue.

• Source issue: #1589
• Status: Open
• Labels: bot:failed, bot:enhancement
• Original author: marcusbellamyshaw-cell

Original Issue

Summary

The built-in comments UI renders a Cloudflare Turnstile widget and submits its token, but the public comment POST route never verifies that token server-side. Enabling Turnstile on comments therefore provides only client-side friction — a bot that POSTs directly to the API (skipping the widget) is not blocked.

Details

packages/core/src/components/CommentForm.astro:

• Renders <div class="cf-turnstile" data-sitekey={turnstileSiteKey}> when turnstileSiteKey is passed.
• Loads https://challenges.cloudflare.com/turnstile/v0/api.js.
• Its inline submit script reads [name='cf-turnstile-response'] and includes it as turnstileToken in the JSON POST body.

But packages/core/src/astro/routes/api/comments/[collection]/[contentId]/index.ts (the public POST handler) only runs:

• honeypot (website_url)
• IP-hash rate limiting

It parses the body but ignores turnstileToken — there is no siteverify call anywhere in packages/core (grep for turnstile/siteverify returns only CommentForm.astro).

Why this matters

A site owner who sets turnstileSiteKey reasonably assumes submissions are gated by Turnstile. They aren't. This is particularly dangerous combined with commentsModeration: "none" (auto-approve): direct-to-API spam is auto-published with no human review and no Turnstile enforcement.

The pattern already exists in-repo

@​emdash-cms/plugin-forms already verifies Turnstile correctly — src/turnstile.ts exposes verifyTurnstile(token, secretKey, httpFetch) hitting https://challenges.cloudflare.com/turnstile/v0/siteverify, used in handlers/submit.ts. Comments should do the same.

Suggested fix

In the comment POST route, when a Turnstile secret is configured (e.g. a TURNSTILE_SECRET secret / config field, mirroring ipSalt resolution), call siteverify with the submitted turnstileToken and reject on failure before persisting/moderating. Reuse the plugin-forms verifyTurnstile logic. Skip when no secret is configured so existing non-Turnstile sites are unaffected (backward compatible).

Happy to send a PR wiring this up if it's wanted.

Environment

• emdash 0.22.0