fix: enforce rate limit on all webhook events regardless of installation ID

[diksha78dev]

Summary

Fixed a rate limiting bypass vulnerability where GitHub webhooks lacking an installation.id (such as meta or security_advisory events) completely skipped the rate limiter.

Type of Change

• Bug fix
• New feature
• UI / UX improvement
• Refactor
• Documentation
• Other

Related Issue

Closes #391

What was changed?

• Removed the conditional check if (installationId) that skipped rate-limiting.
• Added a fallback rate limit key using the x-forwarded-for header for events that do not contain an installation.id.
• Webhook endpoints are now unconditionally rate-limited.

Screenshots

N/A

Checklist

• My code follows the project structure and conventions
• I tested this locally (npm run dev & npm run test)
• No hardcoded secrets or credentials
• I have updated documentation if needed

[vercel]

@diksha78dev is attempting to deploy a commit to the codersogs-3057's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Ayush-Patel-56]

x-forwarded-for is taken as the raw header value, but that's attacker-controlled in this exact threat model (leaked secret, forged requests) and can have multiple comma-separated hops. Need to confirm Vercel doesn't just append to it, and parse out the trusted IP rather than using the raw string. Also no test for the new fallback path.

[diksha78dev]

@Ayush-Patel-56 Thanks for review.Relying on x-forwarded-for as a fallback leaves us vulnerable to IP spoofing since attackers can manipulate those headers.
I've pushed a commit that completely removes the IP-based rate limiting fallback. Instead, the rate limit now falls back to a global bucket scoped to the specific eventType (e.g., global:meta). Since uninstalled events happen very infrequently, a global limit of 100/minute is generous enough for normal operation but completely immune to IP spoofing during an attack. I also added a test for this fallback path

[Ayush-Patel-56]

Solid fix. LGTM. Thanks!