WebAuthn and Passkey Bypass Testing for Bug Bounty Hunters
Passkeys remove shared secrets from the happy path. Attackers then aim at the ceremony glue: challenge reuse, origin binding, backup codes, and account linking that silently reintroduces password-only login.
If you only poke the Authenticator UI, you will miss the bugs. Instrument the WebAuthn options and the server verification responses.
Learn the normal ceremony
Register a passkey on an account you own. Capture navigator.credentials.create options and the attestation the client POSTs back. Then capture an assertion during login. Record rpId, origin, challenge, user.id, allowCredentials, and whether resident keys are required.
Questions to answer:
- Is the challenge single-use and short-lived on the server?
- Does verification bind to the expected origin and RP ID?
- Can you register a second authenticator without recent reauthentication?
- Does "use password instead" undo the whole benefit?
Copy the ceremony into Repeater-friendly JSON so you can mutate one field at a time. Browser tooling makes it easy to confuse a successful prompt with a successful server check.
High-signal bypass tests
Replay an old challenge with a fresh assertion if you can generate one in a controlled lab. The server should reject reused challenges. Swap the credential ID from account A's passkey into B's login ceremony while keeping cookies separate—credential ownership must be checked server-side against the account.
Cross-origin tricks matter when wildcards or related-subdomain RP IDs are sloppy. A token accepted on evil.example.com that was registered for app.example.com is a serious binding failure. Only test hosts in scope.
Device-loss and recovery flows are where passkey deployments quietly collapse. Backup codes emailed in plaintext, SMS fallback without rate limits, or support tools that disable WebAuthn without audit trails can be easier to abuse than forging an authenticator response. Document the downgrade path as its own issue when it yields a full session without the registered passkey.
Also try completing registration twice with the same challenge, and registering while a second owned session is mid-login. Race-friendly session binding mistakes show up here.
Attestation and client tricks
Most consumer apps accept none attestation. That is normal. Enterprise apps that claim hardware attestation need server-side validation of the attestation statement—not a Boolean the browser echoed. Flip attestation fields and authenticator attachment hints only if the server reads them for security decisions.
Conditional UI and autofill make it easy to confuse "browser showed a passkey prompt" with "server verified assertion." Always confirm session elevation with a protected API call after your manipulation.
Report shape
Explain which ceremony step the server skipped. Attach the options JSON, the assertion payload (redacted), and the subsequent authenticated request. Do not claim platform authenticator bugs you cannot reproduce outside your own device lab.
Fixes belong on the server: strict origin/RP ID checks, one-time challenges, credential-to-user binding, step-up before adding authenticators, and recovery paths that are rate-limited, audited, and at least as strong as the passkey. WebAuthn.guide is a readable companion when you need shared terminology for attestation versus assertion. When the product syncs passkeys across devices, confirm revocation on one device invalidates assertions from another. Stale credential rows are a quiet bypass class.