Unauthenticated JWT issuance via /dev-login remains active in production

[Ridanshi]

Summary

The backend currently exposes a development-only login route in all environments, including production.

POST /auth/dev-login issues a valid 30-day JWT for a hardcoded demo user without requiring any authentication, password verification, feature flag, or environment guard.

This creates a complete authentication bypass vulnerability.

---

Affected File

apps/backend/src/routes/auth.ts

---

Root Cause

The route is registered unconditionally:

app.post('/dev-login', async (request, reply) => {
  const token = app.jwt.sign(
    {
      id: 'devcard-demo',
      username: 'demo',
    },
    { expiresIn: '30d' }
  );

  return reply.send({ token });
});

The endpoint:

• has no authentication checks,
• has no environment validation,
• has no feature flag,
• and is accessible to any caller.

Because it issues a fully valid JWT, the token bypasses every route protected by:

app.authenticate

---

Security Impact

Any unauthenticated attacker can:

• issue themselves a valid JWT,
• impersonate the demo account,
• access authenticated API routes,
• and bypass all normal login flows.

Potential impact:

• authenticated route access,
• analytics manipulation,
• unauthorized actions,
• privilege escalation depending on downstream authorization assumptions.

The issue is especially severe because exploitation requires only:

curl -X POST https://api.devcard.app/auth/dev-login

---

Reproduction

curl -X POST https://api.devcard.app/auth/dev-login

Response:

{
  "token": "eyJ..."
}

The returned token can immediately be used against protected endpoints.

---

Proposed Fix

Guard route registration behind a strict environment check.

Suggested approach:

if (process.env.NODE_ENV !== 'production') {
  app.post('/dev-login', async (request, reply) => {
    ...
  });
}

Additional recommendations:

• emit a startup warning when dev-login is enabled,
• require an explicit feature flag,
• and ensure the route is excluded from production builds entirely.

---

Acceptance Criteria

• /dev-login is unavailable in production
• production startup refuses unsafe configuration
• development behavior remains unchanged
• authenticated routes cannot be accessed using demo tokens in production
• regression coverage added for environment gating

---

Why This Matters

This is a direct authentication bypass vulnerability requiring no credentials and no special conditions to exploit.

[Ridanshi]

Hi @Harxhit,

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

I’ve already analyzed the affected authentication flow and understand the root cause, impact, and expected fix direction. I can work on implementing a safe environment-gated solution along with focused regression coverage while preserving the existing development workflow.

Could you please assign this issue to me?

[Harxhit]

@Ridanshi Quick question — we are planning to migrate authentication to Firebase and rely on the authenticate route/middleware for token verification. In that setup, would /auth/dev-login still be considered a valid auth bypass if app.authenticate only accepts Firebase-issued tokens (for example via Firebase Admin verification) and rejects locally signed JWTs? Trying to understand whether this is an active vulnerability or potentially legacy/dead code depending on the auth verification path.

[Ridanshi]

I agree the answer depends entirely on the active verification path.

If app.authenticate exclusively verifies Firebase-issued tokens via Firebase Admin verification and rejects locally signed JWTs unconditionally, then the token issued by /auth/dev-login would effectively be inert against protected routes. In that configuration, the original “active auth bypass” framing would indeed be too strong.

I want to be precise about that rather than overstate the severity.

The remaining concern I intended to highlight is more around exposing a production debug credential-issuance endpoint whose safety depends on assumptions elsewhere in the authentication stack.

Even if the current Firebase verification path makes the issued token unusable today, the endpoint still creates:

• migration/regression risk if any route or environment later reintroduces local JWT verification,
• ambiguous production security posture,
• and accidental reactivation risk during future auth changes or rollback scenarios.

So I’d be comfortable reframing the issue from:

“active authentication bypass”

to something closer to:

“unsafe production debug endpoint creating latent regression/security posture risk”

rather than treating it as a confirmed exploitable bypass under the Firebase-only verification model.

The remediation would remain the same either way:

• remove the route entirely,
• or strictly gate it behind non-production environment checks / explicit feature flags.

[Harxhit]

@Ridanshi I have assigned the issue to you.

[Ridanshi]

PR #353 addresses issue #298 by adding focused regression coverage for /auth/dev-login production gating.

The production guard is already present on latest upstream/main, so this PR intentionally avoids modifying authentication flow or middleware logic and instead protects the existing behavior against regressions.

Covered behavior:

• /auth/dev-login is available outside production
• /auth/dev-login returns 404 in production
• existing production auth routes continue functioning normally

No Firebase assumptions, token verification changes, or unrelated auth refactors were introduced.