vulns.co
/
GKData.io MCP

Back to Playbooks

Passkeys and WebAuthn

A passkey is an origin-bound credential. The finding is usually the path around it: recovery, a second factor that still mints a full session, or a registration that attaches a credential to the wrong account.

Tags: passkey, webauthn, ato, session

Level: advanced

Method

  1. Map the ceremonies

    Find registration, assertion, and any conditional UI. Note the relying party id and the page origin. Those two have to agree.

    Tools: browser, Burp Suite

  2. See what registration attaches to

    Create a credential only from a session you already proved. If a logged-out or unverified flow can register a passkey onto an account, write down which session the server trusted.

    Tools: Burp Suite

  3. Inventory as two users

    List, rename, and remove credentials as two accounts you own. User B should not see or delete user A's credential ids.

    Tools: Burp Suite

  4. Walk recovery

    Password reset, magic link, backup code, and support unlock. Record whether any of them mint a session even when the account was passkey-only. A documented backup factor is not a bug.

    Tools: Burp Suite

  5. Check the session the assertion returns

    After a successful assertion, record the cookie or token. Log out, remove the passkey, and see whether the old session still works.

    Tools: browser

  6. Step-up on sibling apps

    If the passkey is meant to gate email change, payment, or admin, try the same action on a sibling host or API. The ceremony on the website does not count if the API skips it.

    Tools: Burp Suite

Field notes

  • Use authenticators you own. Do not enroll a credential on someone else's account.
  • User verification and a signature counter are server checks. A browser prompt is not proof the server required them.
  • Hybrid and QR flows should finish in the browser that started them.

References