OAuth CSRF — State Nonce Never Validated Server-Side

[Ridanshi]

Summary

The GitHub OAuth connection flow generates a state nonce but never validates it server-side during the callback flow.

The callback handler currently trusts the decoded userId from the client-controlled state payload without verifying whether the nonce was ever issued by the server.

This allows forged OAuth state payloads and enables forced account-linking attacks.

---

Affected File

apps/backend/src/routes/connect.ts

---

Root Cause

The /api/connect/github route generates:

{
  userId,
  nonce
}

and base64-encodes it into the OAuth state parameter.

However, during callback handling:

/api/connect/github/callback

the backend only decodes and structurally validates the payload:

if (
  typeof decoded.userId !== 'string' ||
  typeof decoded.nonce !== 'string'
) {
  return null;
}

The nonce itself is never:

• stored server-side,
• cross-checked,
• expired,
• or invalidated.

A code comment already acknowledges the missing validation:

// In a real app, store this in Redis to cross-check in callback

---

Security Impact

This creates a CSRF-style OAuth account-linking vulnerability.

An attacker can:

1. obtain a victim's user ID,
2. forge a valid-looking OAuth state,
3. complete GitHub OAuth using their own GitHub account,
4. inject the forged state into the callback request.

The backend will then:

• trust the forged userId,
• exchange the OAuth code,
• and store the attacker's GitHub token under the victim's account.

This can result in:

• forced GitHub account linking,
• unauthorized follow actions,
• incorrect OAuth identity association,
• and compromised social integration integrity.

---

Example Attack Flow

const forgedState = Buffer.from(
  JSON.stringify({
    userId: "<victim-user-id>",
    nonce: "fake"
  })
).toString("base64");

The attacker then:

• authenticates normally with GitHub,
• intercepts the callback request,
• replaces the state parameter with the forged value.

The backend accepts the forged callback and associates the attacker's GitHub token with the victim account.

---

Proposed Fix

Implement proper server-side nonce validation.

Suggested approach:

During OAuth initiation

• generate a cryptographically secure nonce,
• store it in Redis:

oauth_nonce:{nonce} -> userId

with a short expiration (e.g. 5–10 minutes).

During callback

• look up the nonce,
• verify it matches the expected user,
• reject unknown/expired nonces,
• delete the nonce immediately after successful validation.

Additional recommendations:

• reject replayed nonces,
• fail closed on Redis lookup failure,
• add structured logging for invalid state attempts.

---

Acceptance Criteria

• OAuth nonce is persisted server-side before redirect.
• Callback validates nonce existence before trusting userId.
• Nonce is deleted after successful use.
• Expired or forged states are rejected.
• Replay attacks are prevented.
• Existing OAuth flows continue working normally.

---

Security Severity

High

This is a realistic OAuth state-validation vulnerability affecting account-linking integrity.

[Ridanshi]

Hi @Harxhit.
I’d like to work on this issue. The root cause and proposed fix path are clear, and I already have an implementation approach in mind for secure server-side nonce validation and replay protection in the OAuth callback flow.
Could you please assign this issue to me?

[Nightkilller]

Hi @Ridanshi,

I would like to work on this issue under GSSoC'26.

I reviewed the reported vulnerability and understand that the OAuth state parameter currently contains a generated nonce, but the nonce is never persisted or validated server-side during the callback flow. As a result, the callback trusts attacker-controlled state data after only structural validation, creating a potential OAuth account-linking/CSRF vulnerability.

My plan is to:

• Generate and persist OAuth nonces server-side during the GitHub connection initiation flow.
• Store the nonce with the associated user identifier in Redis using a short expiration window.
• Validate nonce existence and ownership during the callback before trusting any user information contained in the state payload.
• Reject forged, expired, unknown, or mismatched state values.
• Consume the nonce after successful validation to prevent replay attacks.
• Add test coverage for:
  • valid OAuth state flow
  • forged state payloads
  • expired or unknown nonces
  • replay attempts using previously consumed nonces
• Add appropriate logging for invalid state validation failures while preserving the existing successful OAuth flow.

I will keep the implementation focused on secure OAuth state validation and ensure there are no regressions to the current GitHub integration experience.

Please assign this issue to me. Thank you!

[Harxhit]

@Ridanshi I have assigned this issue to you.

[Ridanshi]

Implemented the OAuth state validation hardening fix and opened PR #273 for review.

The update adds server-side OAuth nonce persistence and validation, enforces single-use replay-safe nonce consumption, prevents forged account-linking attempts, and adds comprehensive regression coverage for malformed, expired, replayed, and tampered OAuth state flows.

Fixes #223.