fix(webhooks): stop provider challenges from intercepting other providers' deliveries

The challenge handlers run before webhook lookup and are provider-blind, so two
query parameter names are effectively reserved across every path. Now that a
generic webhook can be triggered by a URL fetch, a link carrying either name
answers the challenge instead of running the workflow:

- `?validationToken=x` is echoed back as a Microsoft Graph subscription
  validation. Graph sends that validation as a POST, so ignore the parameter on
  every other method.
- `hub.mode`, `hub.verify_token` and `hub.challenge` answer 403 when no WhatsApp
  webhook on the path expects a token. A path with no such webhook is not a
  failed verification - the parameters belong to whoever owns that path - so fall
  through and let the delivery route normally. A token mismatch against a
  WhatsApp webhook still fails with 403.

Refs #6888

Signed-off-by: mini.jeong <mini.jeong@navercorp.com>

Author: minijeong-log

apps/sim/lib/webhooks/providers/microsoft-teams.test.ts

@@ -219,4 +219,39 @@ describe('microsoftTeamsHandler formatInput (outgoing webhook channelData)', ()
       teamsChannelId: 'channel-1',
     })
   })
+
+  describe('handleChallenge', () => {
+    function challengeRequest(method: string): NextRequest {
+      return new NextRequest(
+        'https://app.example.com/api/webhooks/trigger/abc?validationToken=token-123',
+        { method }
+      )
+    }
+
+    it('echoes the validation token for the POST Microsoft Graph sends', async () => {
+      const response = microsoftTeamsHandler.handleChallenge!(
+        {},
+        challengeRequest('POST'),
+        'teams-challenge-post',
+        'abc'
+      )
+
+      expect(response?.status).toBe(200)
+      await expect(response?.text()).resolves.toBe('token-123')
+    })
+
+    it.each(['GET', 'PUT', 'PATCH', 'DELETE'])(
+      'ignores a validationToken query parameter on a %s delivery',
+      (method) => {
+        expect(
+          microsoftTeamsHandler.handleChallenge!(
+            {},
+            challengeRequest(method),
+            'teams-challenge-other-method',
+            'abc'
+          )
+        ).toBeNull()
+      }
+    )
+  })
 })

apps/sim/lib/webhooks/providers/microsoft-teams.ts

@@ -479,6 +479,15 @@ async function formatTeamsGraphNotification(
 
 export const microsoftTeamsHandler: WebhookProviderHandler = {
   handleChallenge(_body: unknown, request: NextRequest, requestId: string, path: string) {
+    /**
+     * Microsoft Graph sends the subscription validation as a POST. Answering it for any method
+     * would let a `validationToken` query parameter on a GET, PUT, PATCH or DELETE delivery to
+     * another provider's path be echoed back instead of triggering that workflow.
+     */
+    if (request.method !== 'POST') {
+      return null
+    }
+
     const url = new URL(request.url)
     const validationToken = url.searchParams.get('validationToken')
     if (validationToken) {

apps/sim/lib/webhooks/providers/whatsapp.test.ts

@@ -2,7 +2,7 @@
  * @vitest-environment node
  */
 import { createHmac } from 'node:crypto'
-import { dbChainMock, schemaMock } from '@sim/testing'
+import { dbChainMock, queueTableRows, schemaMock } from '@sim/testing'
 import { NextRequest } from 'next/server'
 import { describe, expect, it, vi } from 'vitest'
 
@@ -265,6 +265,42 @@ describe('WhatsApp webhook provider', () => {
     expect(input.caption).toBeUndefined()
   })
 
+  describe('handleChallenge', () => {
+    function verificationRequest(): NextRequest {
+      return new NextRequest(
+        'http://localhost/api/webhooks/trigger/abc?hub.mode=subscribe&hub.verify_token=t&hub.challenge=c'
+      )
+    }
+
+    it('falls through when no WhatsApp webhook on the path expects a token', async () => {
+      queueTableRows(schemaMock.webhook, [])
+
+      const response = await whatsappHandler.handleChallenge!(
+        {},
+        verificationRequest(),
+        'wa-challenge-no-webhook',
+        'abc'
+      )
+
+      expect(response).toBeNull()
+    })
+
+    it('still fails verification when a WhatsApp webhook expects a different token', async () => {
+      queueTableRows(schemaMock.webhook, [
+        { webhook: { id: 'wh_1', providerConfig: { verificationToken: 'other' } } },
+      ])
+
+      const response = await whatsappHandler.handleChallenge!(
+        {},
+        verificationRequest(),
+        'wa-challenge-token-mismatch',
+        'abc'
+      )
+
+      expect(response?.status).toBe(403)
+    })
+  })
+
   it('ignores a media type whose payload object is missing', async () => {
     const input = await formatMediaMessage({
       id: 'wamid.image.2',

apps/sim/lib/webhooks/providers/whatsapp.ts

@@ -202,6 +202,8 @@ async function handleWhatsAppVerification(
         )
       )
 
+    let candidates = 0
+
     for (const row of webhooks) {
       const wh = row.webhook
       const providerConfig = (wh.providerConfig as Record<string, unknown>) || {}
@@ -211,6 +213,8 @@ async function handleWhatsAppVerification(
         continue
       }
 
+      candidates++
+
       if (safeCompare(token, verificationToken as string)) {
         logger.info(`[${requestId}] WhatsApp verification successful for webhook ${wh.id}`)
         return new NextResponse(challenge, {
@@ -222,6 +226,15 @@ async function handleWhatsAppVerification(
       }
     }
 
+    /**
+     * A path with no WhatsApp webhook expecting a token is not a failed verification: the
+     * `hub.*` parameters belong to whoever owns that path. Fall through so the delivery is
+     * routed normally instead of answering 403 for someone else's query parameters.
+     */
+    if (candidates === 0) {
+      return null
+    }
+
     logger.warn(`[${requestId}] No matching WhatsApp verification token found`)
     return new NextResponse('Verification failed', { status: 403 })
   }