Webhook rate limiting is skipped for event types without an installation field

[jakharmonika364]

What happened?

src/app/api/webhooks/github/route.ts only applies rate limiting when the incoming payload has an installation field:

const installationId = payload.installation?.id;
...
if (installationId) {
  // rate limit applied here
}

Several legitimate GitHub webhook event types don't carry an installation object at all (for example meta, security_advisory, github_app_authorization). Signature verification still runs first and is solid, so this isn't an auth bypass, but any event type that lacks installation skips the rate limiter entirely after that check passes, with no ceiling on how often it can be processed.

Steps to Reproduce

1. Send a validly signed webhook payload for an event type with no installation field
2. Repeat it as many times as you want
3. None of them get rate limited, unlike events that do carry an installation id

Expected Behavior

Rate limiting should apply to every webhook event regardless of payload shape, maybe keyed by something else (delivery id, source IP, event type) when there's no installation id to key on.

Where does this occur?

API (GitHub webhooks)

Additional Context

Low likelihood of abuse since it still requires a valid signature, but it's an inconsistency worth closing, especially since a leaked or rotated webhook secret would otherwise have no rate ceiling on this path.

[diksha78dev]

@Ayush-Patel-56 I would like to work on this issue under the GSSOC'26 and SSoC'26 programs.

Proposed Solution

To ensure that all webhook events are subject to rate limiting, I will refactor the rate-limiting logic in src/app/api/webhooks/github/route.ts to utilize a fallback key when an installationId is unavailable.

• Action: Update the rate-limiting implementation to handle payloads without an installationId.
• Implementation:
  • Key Selection Strategy: If installationId is null/undefined, I will fallback to using a combination of the X-GitHub-Delivery header (to uniquely identify the request) or the source IP address as the rate-limiting key.
  • Refactor: Modify the current conditional check to ensure the rateLimit() function is always called, passing the derived key.

  const installationId = payload.installation?.id;
  const deliveryId = request.headers.get('X-GitHub-Delivery') || 'unknown-delivery';
  const rateLimitKey = installationId ? `gh_inst_${installationId}` : `gh_delivery_${deliveryId}`;
  
  await rateLimit(rateLimitKey);

  • Security Consistency: This change ensures that even for meta or security events that lack an installation context, the API is protected against high-frequency flooding or potential abuse of the webhook endpoint.
• Testing: I will simulate valid webhook payloads that lack an installation object (e.g., meta events) and verify that they are correctly subjected to the same rate-limiting constraints as other events.

[Ayush-Patel-56]

One issue with the proposed key: X-GitHub-Delivery is unique per request by design (it's already used for idempotency dedup above), so keying the rate limiter on it means every fallback request gets its own bucket - the limiter would never actually trigger. Can you key the fallback on eventType (from x-github-event, already extracted in this file) instead? That buckets repeated deliveries of the same event type together, which is what actually gives it a ceiling. Also the rateLimit() call takes { namespace, key, limit, windowSec }, not a single string arg - check the existing installation branch for the shape.

[diksha78dev]

Thanks for the clarification. That makes perfect sense—using X-GitHub-Delivery would defeat the purpose of the rate limiter. I will update the key to use eventType instead to correctly bucket these requests, and I'll adjust the rateLimit() call to pass the { namespace, key, limit, windowSec } object as required. I'll get the PR updated shortly.