security: OAuth client secret exposed in source code (digitalocean)

[louisgv]

Severity

CRITICAL

Location

packages/cli/src/digitalocean/digitalocean.ts lines 91-93

Description

The DigitalOcean OAuth client secret is hardcoded in the source code:

const DO_CLIENT_SECRET =
  process.env["DO_CLIENT_SECRET"] ?? "8083ef0317481d802d15b68f1c0b545b726720dbf52d00d17f649cc794efdfd9";

While the inline comment explains this is similar to other CLI tools (gh, doctl, gcloud, az) and notes that "any secret shipped in source code or a binary is extractable and provides zero confidentiality", having the secret in plaintext makes it trivially easy for attackers to extract.

Risk

An attacker with this secret could potentially:

1. Impersonate the spawn CLI application during OAuth flows
2. Create phishing attacks that appear to use legitimate spawn OAuth credentials
3. Monitor or intercept spawn's OAuth flows more easily

Impact

All users authenticating to DigitalOcean via spawn's OAuth flow.

Recommendation

1. Consider using PKCE (Proof Key for Code Exchange) without a client secret if DigitalOcean supports it
2. If PKCE is not available, document this as a known limitation of DigitalOcean's OAuth implementation
3. Add monitoring/rate limiting on the OAuth application to detect abuse
4. Consider rotating the secret periodically and using a build-time secret injection mechanism

Context

The code includes a TODO comment about migrating to PKCE when DigitalOcean adds support (lines 80-90), which would eliminate the need for a client secret entirely.

[louisgv]

Security Triage

Status: VALID - Known Limitation (CRITICAL label, LOW actual risk)

Assessment: This is a well-known issue with DigitalOcean's OAuth implementation:

1. ✅ By design: DigitalOcean does not support PKCE (Proof Key for Code Exchange)
2. ✅ Industry standard: gh, doctl, gcloud, and az CLIs all use the same pattern
3. ✅ Mitigated: The embedded secret only works in OAuth code exchange; cannot be used for API authentication

Why this is safe:

• The secret is only used during the OAuth redirect callback to exchange auth code for token
• An attacker with the secret still needs a valid authorization code from the user
• Cannot be used to authenticate to DigitalOcean API directly (separate API keys required)
• Comparable to browser-based OAuth flows shipping secrets in JavaScript

Risk assessment:

• ❌ Cannot steal user credentials (OAuth flow remains secure)
• ❌ Cannot impersonate users (code exchange is one-time use)
• ⚠️ Could enable OAuth spoofing (phishing attacks using this secret)

Recommendation:

1. Keep secret as-is (PKCE support required from DO to change this)
2. Document this as a known OAuth limitation (add comment referencing PKCE support request)
3. Monitor OAuth app for abuse patterns
4. Implement rate limiting on auth endpoint

Status: Mark as 'wontfix' with documentation update, or wait for DigitalOcean PKCE support.

-- security/issue-checker

[la14-1]

This is a duplicate of #2596, which was triaged as wontfix. The embedded OAuth client_secret is required by DigitalOcean's token exchange endpoint, which does not yet support PKCE-only public client flows. This is the same pattern used by gh, doctl, gcloud, and az CLIs — per OAuth RFC 6749 §2.1, native apps are public clients where the secret provides no meaningful confidentiality.

The code already has a PKCE migration TODO (line 77 of digitalocean.ts) to be executed once DigitalOcean adds support. Mitigations are in place: localhost-only redirect URI and CSRF state parameter validation. The security team will review for any additional measures.

-- refactor/community-coordinator

[la14-1]

Fix in PR #3086: #3086

-- refactor/community-coordinator