Add Cloudflare Turnstile to grant applications

[dergigi]

Adds Cloudflare Turnstile to the grant application form. Submit stays disabled until the challenge succeeds, then /api/github and /api/sendgrid verify the token server-side before creating the issue or sending mail. CSP is updated so the widget can load.

• embeds cf-turnstile on the final apply step
• refreshes the token between GitHub and SendGrid (single-use)
• requires NEXT_PUBLIC_TURNSTILE_SITE_KEY and TURNSTILE_SECRET

Build preview:

• /apply/grant
• /apply/lts
• /apply/red

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
os-website	Ready	Preview	Aug 8, 2026 1:20pm

[Copilot]

Pull request overview

Adds Cloudflare Turnstile bot protection to the shared grant application flow, enforcing server-side verification on both application submission endpoints while keeping the client submit button gated on token readiness.

Changes:

• Introduces shared Turnstile utilities for token extraction, client IP detection, and canonical siteverify (fail-closed).
• Updates client submission flow to require Turnstile and refresh the challenge between /api/github and /api/sendgrid calls (single-use tokens).
• Gates both API routes with Turnstile verification, strips the token from the SendGrid internal email body, and adds Jest coverage.

Reviewed changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
utils/turnstile.ts	Adds shared Turnstile helpers (token extraction, IP detection, siteverify, API-route assertion).
utils/turnstile.test.js	Unit tests for Turnstile helpers and fail-closed behavior.
utils/application-submission.ts	Submits with Turnstile tokens; refreshes token between GitHub and SendGrid submissions.
utils/application-submission.test.js	Tests fresh-token behavior and token-required gating in submission flow.
tests/api/sendgrid.test.js	Adds Turnstile gating tests and asserts token is removed from internal email content.
tests/api/github.test.js	Adds Turnstile gating tests for GitHub issue creation endpoint.
pages/api/sendgrid.ts	Enforces Turnstile verification and filters token out of the internal email body.
pages/api/github.ts	Enforces Turnstile verification before creating GitHub issues.
components/grant-application/TurnstileWidget.tsx	New explicit-render Turnstile widget with imperative handle (wait/reset).
components/grant-application/MultiStepApplicationForm.tsx	Renders Turnstile on the final step and disables submit until verification is ready.
.env.example	Documents NEXT_PUBLIC_TURNSTILE_SITE_KEY and TURNSTILE_SECRET.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 12 out of 12 changed files in this pull request and generated no new comments.

Suppressed comments (4)

utils/application-submission.ts:67

• githubToken falls back to String(data[TURNSTILE_TOKEN_FIELD] || ''), which treats non-string values (e.g. an object) as a non-empty token ("[object Object]") and skips the "complete the bot verification" error, leading to a misleading submission failure. Since the submission data is unknown, the fallback should only accept a non-empty string token.

  const githubToken = turnstile
    ? await turnstile.waitForToken()
    : String(data[TURNSTILE_TOKEN_FIELD] || '')

utils/turnstile.ts:60

• verifyTurnstileToken has no timeout; if Cloudflare stalls, the API route can hang until the platform kills the request, tying up resources and increasing tail latency. Add a short abort timeout so verification fails closed quickly on slow upstream responses.

    const response = await fetchImpl(
      'https://challenges.cloudflare.com/turnstile/v0/siteverify',
      {
        method: 'POST',
        headers: { 'Content-Type': 'application/x-www-form-urlencoded' },

pages/api/sendgrid.ts:277

• If TURNSTILE_SECRET is missing/misconfigured, assertTurnstile returns false and the handler responds 403, which is indistinguishable from a real bot failure and will cause users to retry indefinitely. Consider treating a missing secret as an internal misconfiguration (500) and only returning 403 when verification genuinely fails.

  if (!(await assertTurnstile(req))) {
    return res.status(403).json({ message: TURNSTILE_FAILURE_MESSAGE })
  }

  if (!SENDGRID_API_KEY || !TO_ADDRESS || !FROM_ADDRESS) {
    throw new Error('Env misconfigured')

pages/api/github.ts:22

• If TURNSTILE_SECRET is missing/misconfigured, assertTurnstile returns false and this route responds 403, which will look like a user/bot problem rather than an internal deployment problem. Consider validating required env (including TURNSTILE_SECRET) first and only returning 403 when siteverify actually fails.

    if (!(await assertTurnstile(req))) {
      return res.status(403).json({ message: TURNSTILE_FAILURE_MESSAGE })
    }

    if (!GH_ACCESS_TOKEN || !GH_ORG || !GH_APP_REPO) {
      throw new Error('Env misconfigured')

[Copilot]

Pull request overview

Copilot reviewed 12 out of 13 changed files in this pull request and generated no new comments.

Suppressed comments (2)

utils/application-submission.ts:85

• Same issue as githubToken: String(data[TURNSTILE_TOKEN_FIELD] || '') can produce a non-empty string for non-string values. Restrict this to a non-empty string token.

  const emailToken = turnstile
    ? await turnstile.resetAndWaitForToken()
    : String(data[TURNSTILE_TOKEN_FIELD] || '')

utils/application-submission.ts:67

• When turnstile controls aren't provided, String(data[TURNSTILE_TOKEN_FIELD] || '') can turn non-string values into a non-empty token (e.g. [object Object]), which bypasses the "complete the challenge" check and leads to a confusing server-side 403. Only accept a non-empty string here.

This issue also appears on line 82 of the same file.

  const githubToken = turnstile
    ? await turnstile.waitForToken()
    : String(data[TURNSTILE_TOKEN_FIELD] || '')

[BoltTouring]

• If you click the cloudflare box, then hit back and hit review application again, there is no box and you can't submit.
• Same thing happens if you don't click the box so clicking back on the final screen removes the cloudflare check.
• Happens for both General and Red applications

[BoltTouring]

Tried submitting after clicking verify (happy path) and it didn't work. The green check disappeared and the verify box comes back, and it also shows as submitting.

If I click the box again it submits (without clicking the orange button) and I receive an email notification. Also shows up in Github.

[dergigi]

Thanks @BoltTouring - should be fixed now/soon, please have another look.

We are in no rush to merge this btw, applications should be fine, this is just a proper anti-spam measure. Even if we merge this on Monday (or even Wednesday or whatever) - that's soon enough.

[Arvin21M]

Tested on mobile view:

• We should consider adding "Security Auditing/Testing" as an option under the "Main Focus" dropdown if we want to accept Red Team or similar applications through this channel as well.
• I encountered Cloudflare error code 600010 during testing. This may be related to using the real configuration in the build preview instead of dummy/test credentials, so may not be an issue once pushed to production.
• Console message screenshot attached for reference fwiw.
• Test application is not coming through on the back end, likely due to the cloudflare fail/error issue described above (which is good, anti-spam wise).
• Otherwise, the application experience looks good from a user perspective,

Superseded by follow-up Security grant focus work in PR #911.

[dergigi]

Let's make sure this works properly before we merge.

[BoltTouring]

All of the issues I found have been resolved. LGTM