Summary
better-auth passkey versions before 1.4.0 contain an insecure direct object reference in the passkey deletion endpoint, allowing authenticated users to delete passkeys by ID.
When an attacker with a valid session can submit crafted requests with arbitrary passkey identifiers, they may remove other users' passkeys and disrupt account authentication.
Affected context
This vulnerability appears in applications that integrate better-auth passkey functionality and expose a delete-passkey endpoint relying on client-supplied identifiers.
It tends to occur when:
- Passkeys are referenced directly by an ID parameter in API calls
- Authorization checks only verify that the caller is authenticated, not that they own the targeted passkey
- Passkey IDs are predictable or enumerable in the data store
In such environments, any authenticated user could potentially target passkeys belonging to other accounts.
Exploit preconditions
- Attack surface: HTTP API endpoint for deleting passkeys (e.g.,
/delete-passkey). - Required access: An authenticated session in the application; no special privileges beyond standard user access.
- Trigger point: Submission of a deletion request containing the ID of a passkey owned by another user.
- Why exploitation is possible: The endpoint trusts the caller-supplied passkey ID and does not enforce ownership or object-level authorization, enabling users to operate on resources they do not control.
Why this happens
The underlying bug class is an insecure direct object reference (IDOR), mapped to CWE-639.
The application exposes internal resource identifiers (passkey IDs) and uses them directly to perform sensitive operations without verifying that the requesting user is authorized to act on that specific resource.
By coupling access control solely to authentication status and not to resource ownership, the system permits horizontal privilege abuse where one user can manipulate another user's passkeys.
Potential impact
- Attackers may delete other users' registered passkeys.
- Users can experience unexpected login failures or lockouts due to missing passkeys.
- Accounts may be forced to fall back to weaker or less secure authentication methods.
- Helpdesk and support workloads can increase due to account recovery and re-enrollment requests.
- In some workflows, attackers can disrupt multi-factor authentication setups or security policies that rely on passkeys.
General mitigation guidance
Effective mitigation focuses on enforcing object-level authorization and tightening how resource identifiers are used.
Common defensive patterns include:
- Validating that the authenticated user owns the passkey referenced by the incoming ID before performing any deletion.
- Implementing centralized access control checks for all operations on user-bound credentials rather than relying on endpoint-specific logic.
- Avoiding direct reliance on predictable or sequential identifiers; use opaque, hard-to-guess IDs that are bound to a user context.
- Designing APIs so that clients operate on "current user's resources" without supplying cross-tenant IDs wherever possible.
- Applying least privilege to credential-management operations and logging all changes to authentication factors for auditing.
How teams detect issues like this
Detection typically involves combining code-level analysis with runtime observation:
- Static analysis or manual code review to identify endpoints that accept resource IDs and perform sensitive actions without explicit ownership checks.
- Pattern-based review for calls that look up passkeys or similar credentials using user-supplied IDs without joining on the authenticated user's identity.
- Security test cases and automated integration tests that attempt operations on resources belonging to different users to verify enforcement of horizontal authorization.
- Application logging and anomaly detection that flag unusual patterns of passkey deletions spanning many different accounts from a single user session.
- Optional use of automated security review tools or API gateways enforcing policy rules around credential management endpoints.
