feat: add passkey (WebAuthn) authentication support - #79

Similar to the registration options endpoint, the accountId from request.body is used without authentication. An attacker could register passkeys for arbitrary accounts. This endpoint needs authentication middleware or session validation to ensure the accountId matches the authenticated user.

The accountId and uid are both embedded directly in JavaScript template literals without escaping, creating XSS vulnerabilities. An attacker who can control these values could inject malicious JavaScript. Use HTML escaping for all dynamic values or pass them through data attributes.

The passkeyIcon SVG is embedded in multiple button restoration calls without escaping. If an attacker modifies btn.innerHTML to include this unescaped icon variable, it could lead to injection issues. Consider creating the icon as a constant or using safer DOM manipulation methods.

The handlePasskeySkip function retrieves the interaction result but doesn't validate that the interaction is in the expected state (passkeyPromptPending = true). An attacker could potentially call this endpoint to skip passkey setup even when not in the passkey prompt flow, or manipulate the stored result. Add validation to ensure the interaction is in the correct state before proceeding.

The regex pattern has double backslashes (\+, \/) which will match literal backslashes followed by the character, not the + or / characters themselves. In JavaScript template literals, this should be single backslash. Change /\+/g to /+/g and /\//g to ///g for correct base64url encoding.

The regex pattern has double backslashes (\+, \/) which will match literal backslashes followed by the character, not the + or / characters themselves. In JavaScript template literals, this should be single backslash. Change /\+/g to /+/g and /\//g to ///g for correct base64url encoding.

The accountId is passed in the request body without authentication checks. An attacker could attempt to register passkeys for other users' accounts by providing arbitrary accountIds. The endpoint should verify that the accountId matches the currently authenticated session or require additional authorization.

The accountId is embedded directly in the client-side JavaScript without proper escaping, creating a potential XSS vulnerability. If an accountId contains special characters, quotes, or HTML/JavaScript code, it could break out of the string context and execute arbitrary code. Consider using proper HTML escaping or passing the accountId through a data attribute instead.

The uid variable is embedded in the JavaScript template literal without escaping. If an attacker can control the uid value (e.g., through URL manipulation), they could inject malicious JavaScript code. The uid should be properly escaped or passed through a data attribute.

The /idp/passkey/login/options endpoint lacks rate limiting. An attacker could spam this endpoint to generate challenges and potentially exhaust memory or perform enumeration attacks. Consider adding rate limiting similar to the verify endpoint.

The challenge is stored using accountId as the key, which means if the same user initiates multiple registration attempts (e.g., from different tabs or devices), the older challenge will be overwritten. This could lead to race conditions or allow an attacker to invalidate a legitimate registration attempt by starting their own. Consider using a unique random key for each challenge and returning it to the client, similar to how authentication uses challengeKey.

Error handling at line 270 exposes the internal error message directly to the client. This could leak sensitive information about the server's internal workings. Consider using a generic error message for the response while logging the detailed error server-side.

The passkey prompt condition checks request.passkeyEnabled which is not a standard HTTP request property. This property is not set anywhere in the provided code, so this condition will always evaluate to undefined !== false, which is true. This means passkeys can't be disabled via this mechanism. If this is intended to be a feature flag, it should be properly documented and initialized, or this check should be removed.

Similar to the addPasskey function, there's a potential race condition here. Between reading the account at line 352 and saving it at line 359, another concurrent operation could modify the account. This could result in lost updates or incorrect counter values. Consider implementing optimistic locking or ensuring atomic updates for critical passkey operations like counter updates which are important for security (preventing replay attacks).

The addPasskey function doesn't check if a passkey with the same credentialId already exists before adding it. While the excludeCredentials in the registration options should prevent this in normal flows, a malicious client could potentially bypass client-side checks and register duplicate credentials. Consider adding a check to ensure the credentialId doesn't already exist in the account's passkeys array before adding it.

The client-side JavaScript exposes the INTERACTION_UID in a global variable. While the UID is already part of the URL and not particularly sensitive, using a more scoped approach (e.g., an IIFE or module pattern) would be better practice to avoid polluting the global namespace and potential conflicts with other scripts.

The error message from the server is directly interpolated into the alert without sanitization. If the server returns an error message containing special characters or potentially malicious content, it could be displayed in an unsafe way. While alert() is generally safe from XSS, it's better practice to sanitize or limit the error messages displayed to users.

There's a potential race condition in the passkey registration flow. Between reading the account at line 309 and saving it at line 323, another concurrent request could modify the same account (e.g., another passkey registration). This could result in lost updates where one passkey overwrites another. Consider implementing optimistic locking or using a transaction/lock mechanism to prevent concurrent modifications to the same account.

The comment states that in-memory challenge storage is cleared on restart and suggests using Redis or session storage for production clusters. However, there's no documentation or configuration option provided to actually use an alternative storage mechanism. For a production-ready feature, either implement the Redis/session storage option or document clearly that this is a single-instance limitation and won't work in clustered deployments.

The registrationVerify endpoint accepts accountId from the request body without verifying the request is authenticated or that the requester has permission to complete passkey registration for that account. This allows an attacker to complete passkey registration for any account by providing a valid credential from their own device. The endpoint should verify that the user is authenticated and authorized to add a passkey to the specified account.

The credential object from request.body is passed directly to verifyRegistrationResponse without validating its structure. While @simplewebauthn/server likely performs its own validation, it's good practice to validate that the credential object has the expected shape before processing to fail fast on malformed requests.

Similar to the registration options endpoint, the registration verify endpoint does not validate that the user is authenticated or that they own the account they're registering a passkey for. This allows an attacker to add a passkey to any account if they know the accountId.

There's a potential race condition in the challenge cleanup logic. If multiple requests try to store challenges while at capacity, the cleanup loop might not fully clean up before the second request checks the size, potentially causing valid requests to be rejected unnecessarily. While this is unlikely to be a major issue in practice, consider implementing a more robust cleanup strategy or using a LRU cache.

The registration endpoints do not validate that the user is authenticated before allowing passkey registration. An attacker could potentially register a passkey for any accountId they know, even if they don't control that account. The endpoints should verify that the request comes from an authenticated session and that the session's accountId matches the requested accountId.

The origin and RP ID extraction do not respect proxy headers like x-forwarded-proto and x-forwarded-host. When the server is behind a reverse proxy (common in production), request.protocol and request.hostname may not reflect the actual public-facing URL. This could cause WebAuthn verification to fail or, worse, allow credentials to be registered for the wrong origin. The code should check x-forwarded-proto and x-forwarded-host headers, similar to how other parts of the codebase handle this.