Batter Auth Complete Documentation

• Outcome: Pass
• Latest audit: May 28, 2026, 8:20 AM
• Version:
  1.4.18

Overview

This is a documentation-only Better Auth skill with some security-sensitive examples to review carefully, but no executable or hidden behavior was found.

Install only if you want an offline Better Auth documentation pack. Treat its code examples as reference material, not production-ready security guidance; verify authentication, token, migration, MFA, CORS, and logging patterns against current Better Auth docs and your own security requirements before using them in an application.

SkillSpector

By NVIDIA

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (42)

Intent-Code Divergence

Medium

• Confidence: 93% confidence
• Finding: The documentation says `input: false` prevents users from setting the `role` field during signup, but the very next example shows `res.user.role` evaluating to `admin` despite no admin input being supplied. This contradictory example can mislead developers into assuming privileged fields are safely controlled when the example suggests unexpected elevation, increasing the risk of insecure role-handling implementations.

Intent-Code Divergence

Medium

• Confidence: 94% confidence
• Finding: The documentation marks the magic-link sign-in endpoint as requiring an existing session even though the feature is explicitly intended for unauthenticated login initiation. This contradiction can cause integrators to enforce authentication middleware on the endpoint, breaking login flows or leading developers to add insecure workarounds to bypass session checks on authentication routes.

Intent-Code Divergence

Medium

• Confidence: 95% confidence
• Finding: The verification endpoint is documented as requiring a session despite describing the link-click step that creates the authenticated session. This is a security-relevant documentation flaw because implementers may gate the verification route behind authentication, preventing users from completing login or encouraging unsafe custom handling of tokens and redirects.

Intent-Code Divergence

Medium

• Confidence: 95% confidence
• Finding: The domain verification section states that new providers are initially untrusted, then immediately says sign-ups and sign-ins are still allowed until ownership is verified. In an SSO/account-linking context, that contradiction can cause operators to deploy unsafe assumptions about when a provider becomes trusted, increasing the risk of unauthorized sign-in or unintended account linking for attacker-controlled domains.

Intent-Code Divergence

Medium

• Confidence: 92% confidence
• Finding: The document first instructs users to create an explicit GET handler for the SAML callback route, but later states no additional configuration is required because the callback route already handles GET and POST automatically. Conflicting callback guidance in authentication docs can lead to broken SAML flows, insecure custom handlers, or accidental bypass of framework-integrated protections.

Vague Triggers

Medium

• Confidence: 90% confidence
• Finding: The README states that the skill triggers automatically for broad topics like authentication, OAuth setup, database configuration, session management, and framework integration. Because these are very common developer queries, the skill may activate in many contexts where its large documentation payload is unnecessary, increasing prompt-surface area and the chance of irrelevant or adversarial content influencing an agent's behavior.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The documentation shows a hardcoded MySQL password (`password`) directly in sample configuration without any accompanying warning to use environment variables or secret management. Although likely intended as a placeholder, readers frequently copy examples verbatim, which can normalize insecure credential handling and lead to real deployments with embedded secrets in source control.

Missing User Warnings

Medium

• Confidence: 79% confidence
• Finding: The documentation tells developers they can use the access token to read and write Notion workspace content, but it does not prominently warn about the sensitivity of that access or the need for least-privilege and clear user disclosure. In an authentication-focused skill, this can normalize treating an auth token as a general data-access token without adequate safeguards, increasing the risk of over-collection or misuse of user workspace data.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The documentation instructs users to copy and configure a Zoom OAuth client secret but never explicitly warns that the secret must remain server-side and must not be committed to source control or exposed in frontend bundles. In an authentication skill, this omission is meaningful because developers may copy examples into insecure contexts, leading to credential leakage and takeover of the OAuth integration.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The documentation repeatedly uses a plain HTTP auth server URL without clearly warning that this is only acceptable for local development. If copied into production-like setups, credentials, session tokens, and other authentication traffic could be exposed to interception or manipulation over the network.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The example exposes a `/migrate` HTTP endpoint that executes schema-changing operations on demand, but it does not include authentication, authorization, environment gating, or a prominent warning not to expose it publicly. If copied into production, an attacker could trigger migrations repeatedly or at unsafe times, causing schema corruption, availability issues, or unauthorized database modification.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The documentation explicitly shows how to disable session freshness checks by setting `freshAge: 0` but does not pair that guidance with a clear warning that freshness gates are commonly used to protect sensitive actions such as password changes, MFA enrollment, or account recovery. This can lead implementers to weaken re-authentication safeguards and increase the window in which a stolen or long-lived session can be used for high-risk operations.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The embedded StackBlitz iframe grants a very broad set of permissions, including camera, microphone, geolocation, payment, USB, HID, and other powerful browser capabilities, even though a documentation demo does not appear to require them. In a documentation context, this unnecessarily expands the attack surface: if the third-party content is compromised or behaves unexpectedly, users could be prompted for sensitive device access or exposed to phishing-style permission requests from within the docs page.

Missing User Warnings

Medium

• Confidence: 87% confidence
• Finding: The guide provides a production-style migration workflow that accesses Auth0 administrative credentials and bulk user data, but it does not clearly warn readers that they are handling highly sensitive identity data. In practice, this increases the likelihood that developers run the script with excessive privileges, weak operational controls, or insufficient logging/redaction safeguards, leading to accidental exposure of user records or secrets.

Missing User Warnings

High

• Confidence: 96% confidence
• Finding: The example script migrates and stores OAuth access tokens, refresh tokens, ID tokens, and TOTP secrets/backup codes in the destination system without prominently warning about the sensitivity and downstream risk of doing so. If copied as-is, this can unnecessarily centralize reusable credentials and MFA material in a new datastore, increasing the blast radius of any database compromise and potentially enabling account takeover or token replay.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The guide instructs users to export Clerk user data to a CSV and place it in the project root, which likely contains sensitive authentication-related fields such as email addresses, phone numbers, password digests, and TOTP secrets. Handling this material without explicit privacy, retention, access-control, and secure-disposal guidance increases the risk of credential exposure through source control, local compromise, backups, or accidental sharing.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The migration code uses a high-privilege Clerk secret key to call the user export API, but the guide does not clearly warn that this credential must be kept in secure environment storage and never hardcoded, logged, or exposed client-side. In documentation for authentication migration, omission of secret-handling guidance materially raises the risk of accidental credential leakage and downstream account compromise.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: The migration example logs each user's email address during processing, which exposes personally identifiable information in console output. In real migration environments, logs are often centralized, retained, and shared with operators, so this increases the risk of unnecessary PII disclosure even if it does not directly compromise authentication.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The failure path logs both the user's email address and the raw error object, which can disclose PII and potentially sensitive internal details such as stack traces, database errors, tokens, or upstream API response content. In a migration script handling authentication data, this is more dangerous because operational logs may be exported to third-party logging systems and retained long-term.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: The custom IPC bridge example retrieves an authentication cookie in the main process and forwards it in request headers, but does not emphasize that this is sensitive session material that must never be exposed to or controllable by untrusted renderer content. In an Electron context, IPC boundaries are security-critical; normalizing patterns that shuttle bearer-equivalent cookies through custom bridges can lead developers to build overly broad bridges or leak session credentials through compromised renderer code.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The documentation includes a ready-to-deploy `/migrate` endpoint that will execute database schema migrations when called. Although a later warning advises protecting or removing it, the example itself presents an unsafe pattern that readers may copy verbatim, leaving a production-accessible endpoint that can trigger privileged schema changes or disclose migration state.

Missing User Warnings

Low

• Confidence: 84% confidence
• Finding: Rendering the full session object with JSON.stringify can expose sensitive fields such as user identifiers, emails, session metadata, or tokens if present, especially in shared screens, screenshots, or production builds. In an authentication guide, readers may copy this pattern directly, making inadvertent data exposure more likely.

Missing User Warnings

Medium

• Confidence: 97% confidence
• Finding: The example configures CORS with `origin: "*"` for all routes, which normalizes an overly permissive cross-origin policy in authentication-related documentation. In a real app this can expose non-auth endpoints to untrusted origins and, depending on downstream configuration, increase the risk of cross-origin data access, unsafe API consumption patterns, and weakened browser-based trust boundaries.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: The documentation describes a server-only endpoint that returns raw backup codes, which are effectively recovery secrets equivalent to bypassing the second factor. Although it briefly says this should only be done with a fresh session, it does not prominently warn that exposing or logging these codes can enable full account takeover if mishandled.

Missing User Warnings

Medium

• Confidence: 80% confidence
• Finding: The docs state that the API key value is returned, but do not clearly warn that this secret may only be shown once and must be stored securely. In authentication documentation, omission of secret-handling guidance can cause developers to log, expose, or mishandle credentials, increasing the chance of API key compromise.

VirusTotal

65/65 vendors flagged this skill as clean.