[Security] Missing timeout handling for outbound fetch requests in OAuth flow

[udaycodespace]

Describe the bug

While reviewing the OAuth authentication flow, I noticed that outbound fetch requests inside apps/dashboard-api/src/controllers/auth.controller.js currently do not use timeout handling through AbortController or similar mechanisms.

Because of this, if an upstream OAuth provider becomes slow or temporarily unresponsive, requests may remain pending for a long time and unnecessarily keep server resources occupied.

Where I found this

File:

apps/dashboard-api/src/controllers/auth.controller.js

Observed in outbound OAuth/profile-related fetch requests.

To Reproduce

1. Open apps/dashboard-api/src/controllers/auth.controller.js

2. Locate outbound fetch requests used in the OAuth flow

3. Observe that the requests currently do not configure:

   • AbortController
   • timeout handling
   • abort signals

Expected behavior

Outbound HTTP requests should include timeout protection so requests can fail gracefully instead of potentially hanging indefinitely when external services fail to respond.

Impact

Without timeout handling:

• requests may hang indefinitely
• external provider/network stalls can tie up backend resources
• auth-related flows may become unreliable during upstream failures

Proposed solution

I plan to add lightweight timeout protection around outbound fetch calls using AbortController.

Proposed changes:

• add timeout handling for external fetch requests
• abort long-running requests gracefully after a fixed duration
• properly clear timers after request completion
• keep existing auth flow behavior unchanged

ETA

I’ll work on this and try to raise a PR by tonight.

[udaycodespace]

Hi @yash-pouranik, I’m UDAY, a GGSOC 2026 contributor.

While reviewing the OAuth flow, I noticed these outbound fetch requests currently don’t use timeout handling. It looks like a small backend-side reliability/security fix, and I’ve already validated the affected area in auth.controller.js.

I’ll work on a lightweight fix using AbortController and try to raise a PR by tonight :)

[yash-pouranik]

@coderabbitai
Genuine??

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check issue `#208` details
gh issue view 208 --repo geturbackend/urBackend

echo "---"
# Check if udaycodespace has any PRs in the repo
gh pr list --repo geturbackend/urBackend --author udaycodespace --state all

echo "---"
# Check recent issues/PRs mentioning AbortController or timeout
gh search issues --repo geturbackend/urBackend "AbortController timeout" 2>/dev/null || echo "No results"

echo "---"
# Check udaycodespace's profile
gh api users/udaycodespace 2>/dev/null | jq '{login, name, bio, public_repos, created_at, followers}'

Length of output: 2812

---

---

@yash-pouranik, here's what I found:

About the issue itself: The technical concern is valid. Missing AbortController/timeout handling on outbound fetch calls in OAuth flows is a real reliability problem — pending requests can tie up server resources if an upstream provider is slow or unresponsive.

About the contributor (udaycodespace):

• The issue #208 was actually opened by udaycodespace themselves — it's a self-reported, self-assigned issue.
• Their GitHub account was created May 10, 2025 (~1 year old) with 18 public repos and 9 followers.
• They have no prior PRs submitted to this repository yet.

Context: This pattern — filing an issue and immediately claiming to work on the fix — is common in programs like GSSOC where contributors look for issues to claim for contribution credit. That doesn't make the issue invalid, but it's worth keeping in mind.

Recommendation for you as a maintainer:

• The fix itself (adding AbortController with a timeout) is straightforward and low-risk.
• You can assign the issue to them and wait to review the PR when it comes in.
• If no PR arrives within a reasonable timeframe, you can unassign and open it to others.

Ultimately, the proof will be in the PR quality. 🐇

[yash-pouranik]

I know thats low risk @coderabbitai
But is this issue valid?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Get full issue details
gh issue view 208 --repo geturbackend/urBackend --json title,body,labels,state

echo "==="
# Look for fetch calls in auth controller
fd -i "auth.controller" --exec cat {}

echo "==="
# Broader search for fetch calls without AbortController
rg -n "fetch(" --type js -A2 -B2 2>/dev/null | head -80

echo "==="
# Check if AbortController is used anywhere in the codebase
rg -n "AbortController" --type js 2>/dev/null

Length of output: 150079

---

---

@yash-pouranik, yes, the issue is technically valid — I verified it against the actual code.

What the code actually does:

The fetchJson helper in auth.controller.js and the standalone fetch calls in userAuth.controller.js all make raw fetch() calls with no timeout or AbortController:

// auth.controller.js - fetchJson helper
const fetchJson = async (url, options, defaultMessage) => {
    const response = await fetch(url, options); // ← no signal, no timeout
    ...
};

// userAuth.controller.js - exchangeGithubCodeForToken, exchangeGoogleCodeForToken, 
// fetchGithubProfile, getGooglePublicKeys — all the same pattern
const response = await fetch('https://github.com/login/oauth/access_token', { ... }); // ← no timeout

If GitHub, Google, or any upstream OAuth provider hangs, these requests will wait indefinitely, tying up Node.js event loop resources.

One nuance to push back on: The [Security] label in the issue title is overstated — this is really a reliability/availability concern (resource exhaustion under slow/unresponsive upstreams), not a classical security vulnerability.

What's reassuring: Your codebase already uses AbortController in webhook.controller.js and webhookQueue.js, so the fix pattern is already established. The contributor just needs to replicate it in the auth fetch helpers — it's a small, contained change. Worth reviewing the PR when it arrives. 🐇

[yash-pouranik]

u can strt working. @udaycodespace