# oauth@0.9.15 security report (npm)

- Verdict: **Needs review** (risk level: medium)
- Scanned: 2026-10-06T14:23:40.000Z
- Files reviewed: 9
- Findings: 7 medium, 6 low severity findings
- Report: https://security.togoder.click/npm/oauth
- Source: Togoder Security (https://security.togoder.click), AI source-code review

## Summary

Togoder Security scanned the npm package oauth@0.9.15 on Oct 6, 2026. An AI review of 9 source files produced 7 medium, 6 low severity findings. The overall verdict is medium: the findings flag risky but common patterns (dynamic code, unsafe defaults, broad file or network access) rather than confirmed malware.

## Findings

### [medium] Hardcoded session secret

Finding ID: `NPS-05F065578075`

File: `examples/express-gdata/server.js:11`

The Express session middleware is configured with a hardcoded secret ('skjghskdjfhbqigohqdiouk'). This weakens session security and could allow session forgery if the source is exposed.

### [medium] Open redirect via unsanitized action parameter

Finding ID: `NPS-1EF06C7C755E`

File: `examples/express-gdata/server.js:96`

The 'action' query parameter is used directly in res.redirect() without validation. An attacker could craft a link with an external URL as the action, causing an open redirect after OAuth authorization.

### [medium] Unvalidated redirect URI and lack of state validation

Finding ID: `NPS-1D550CE0D73E`

File: `examples/github-example.js:24`

The redirect_uri is hardcoded and the state parameter is static, providing no real CSRF protection. The server does not validate the state parameter on callback, allowing potential CSRF attacks. Additionally, the code does not verify that the redirect_uri matches the one used in the authorization request.

### [medium] Potential exposure of access token in HTTP response

Finding ID: `NPS-FF1AE271701D`

File: `examples/github-example.js:62`

The server responds with the raw access_token in the HTTP response body (res.end(access_token)), which could be logged or exposed to the client. While this is an example, it demonstrates a bad practice of sending sensitive tokens in plaintext responses.

### [medium] Credential handling in example code

Finding ID: `NPS-74BA8639BACC`

File: `examples/twitter-example.js:4`

The file contains empty string placeholders for clientID, clientSecret, and callbackURL, indicating users are expected to hardcode OAuth credentials directly into source code. This promotes insecure credential storage practices and risks accidental credential exposure in version control if users follow this example pattern.

### [medium] Insecure Random Number Generation

Finding ID: `NPS-9F9CE78BF328`

File: `lib/oauth.js:309`

The _getNonce function uses Math.random() to generate the OAuth nonce. Math.random() is not cryptographically secure and is predictable. In OAuth, nonces must be unique and cryptographically random to prevent replay attacks. A predictable nonce weakens the security of the signature and could allow an attacker to replay requests or forge signatures.

### [medium] Potential Credential Leakage via Redirect Following

Finding ID: `NPS-190581858483`

File: `lib/oauth.js:424`

The _performSecureRequest method follows HTTP redirects (301/302) and resends the same OAuth-signed request (including the Authorization header) to the new location specified by the Location header. This can leak OAuth tokens and secrets to a malicious or compromised redirect target, especially if the redirect goes to a different origin. The followRedirects option is enabled by default.

### [low] Insecure OAuth callback URL

Finding ID: `NPS-69A56F6BD6BB`

File: `examples/express-gdata/server.js:39`

The OAuth callback is hardcoded to 'http://localhost:3000/google_cb', which uses HTTP instead of HTTPS. In a production environment this could expose OAuth tokens to interception.

### [low] Sensitive information logging

Finding ID: `NPS-2ADA2976F4E0`

File: `examples/express-gdata/server.js:70`

The OAuth object is logged via console.log(oa) on lines 70 and 107, potentially exposing tokens or secrets in logs.

### [low] Insecure default configuration and hardcoded secrets placeholders

Finding ID: `NPS-3553AFBBE787`

File: `examples/github-example.js:8`

The example uses empty strings for clientID and clientSecret, which if left in place would cause authentication failures. More importantly, the redirect_uri is hardcoded to http://localhost:8080/code without validation, and the state parameter is a static string ('some random string...') rather than a cryptographically random value, weakening CSRF protection. While this is an example file, it demonstrates insecure OAuth practices.

### [low] Undefined variable reference

Finding ID: `NPS-6EEAF5782446`

File: `examples/twitter-example.js:62`

Inside the callback error handler at line 62, 'res.end()' is called while the actual response object is named 'response'. This undefined reference would throw a runtime error and could indicate copied/modified code or an incomplete implementation.

### [low] Unvalidated query parameter usage

Finding ID: `NPS-91EA8C378796`

File: `examples/twitter-example.js:75`

The code passes urlObj.query.oauth_token and urlObj.query.oauth_verifier directly to the OAuth library without checking they exist or are strings. Malformed requests could cause unexpected behavior in the OAuth flow.

### [low] Insecure default server binding

Finding ID: `NPS-E60331953B95`

File: `examples/twitter-example.js:78`

The HTTP server listens on port 3000 without specifying a hostname, causing it to bind to all network interfaces (0.0.0.0) by default. This exposes the OAuth callback endpoint to the local network, potentially allowing other machines to trigger OAuth flows or observe tokens.

## Files reviewed

- `examples/express-gdata/server.js` (medium): No malicious patterns detected; however, the code contains security weaknesses including a hardcoded session secret, an open redirect risk, and insecure logging of OAuth objects.
- `examples/github-example.js` (medium): The file is an OAuth2 example with insecure practices (static state, hardcoded redirect, token exposure) but contains no malicious patterns such as data exfiltration, backdoors, or code execution.
- `examples/twitter-example.js` (medium): This is a legitimately functioning OAuth example for Twitter with no malicious intent, though it demonstrates poor security practices such as hardcoded credential placeholders and binds the server to all interfaces.
- `lib/oauth.js` (medium): The OAuth library contains no overtly malicious code, but uses insecure nonce generation and unsafe redirect following that could weaken security or leak credentials.
- `examples/term.ie.oauth-HMAC-SHA1.js` (safe): This is a standard OAuth example script that demonstrates OAuth 1.0a flow using the local oauth library; no malicious patterns, data exfiltration, credential harvesting, or other security concerns were identified.
- `index.js` (safe): Cleared by Jev triage; no further analysis needed
- `lib/_utils.js` (safe): Cleared by Jev triage; no further analysis needed
- `lib/oauth2.js` (safe): No malicious patterns detected; the code is a standard OAuth2 client library implementation with no data exfiltration, credential harvesting, obfuscation, or suspicious behavior.
- `lib/sha1.js` (safe): Cleared by Jev triage; no further analysis needed

AI analysis is guidance, not a guarantee. Methodology: https://security.togoder.click/methodology