WebAuthn testing emerged as FIDO2 standards replaced legacy U2F, introducing complex ceremony state machines involving client data, attestation objects, and cryptographic challenges. The core problem lies in authenticator heterogeneity; platform authenticators like Windows Hello differ radically from roaming hardware like YubiKey regarding resident key storage, transport protocols (USB, NFC, BLE), and UV requirements, while browsers enforce differing permission policies for cross-origin contexts. A systematic manual methodology requires authenticator taxonomy mapping, where each device is classified by its attestation format (packed, tpm, fido-u2f), capabilities, and transport availability. Testers must manually execute registration and authentication ceremonies across Chrome, Safari, Firefox, and Edge, inspecting the CBOR-encoded attestation objects via browser DevTools to verify the fmt and attStmt structure against the FIDO Metadata Service (MDS). Special attention must be paid to cross-origin iframe contexts, validating that allow="publickey-credentials-create" and allow="publickey-credentials-get" permissions are correctly enforced, and that resident key flows handle the excludeCredentials filter properly to prevent duplicate registrations.
A healthcare portal embedded WebAuthn registration inside a React widget served from a CDN subdomain, allowing physicians to use YubiKey 5 NFC for second-factor authentication or macOS Touch ID for passwordless login. Physicians reported intermittent failures where Safari on iOS would not recognize the YubiKey via NFC after successful registration on desktop Chrome, and Touch ID prompts failed silently when the widget was loaded in a cross-origin iframe inside the hospital's Epic electronic health record system. We considered three distinct approaches to isolate the root cause of these hardware-specific integration failures.
The first solution involved automated testing with virtual authenticators via Puppeteer or Selenium using the WebDriver virtual authenticator protocol. This method offers high speed and perfect repeatability for regression testing server-side challenge-response handling and CBOR parsing logic. However, it fails to reproduce hardware-specific quirks—such as YubiKey transport hints conflicting with Safari's NFC implementation or the iframe permission policy differences between Chrome and Safari—and cannot simulate biometric UV prompts or physical tap interactions.
The second solution proposed ad-hoc manual testing using whatever devices were available in the office to provide immediate feedback on user experience. While this approach captures real-world browser behavior, it results in inconsistent coverage and reproducibility; testers often missed that Android devices require BLE pairing for security keys while iOS prefers NFC, leading to false negatives. Furthermore, the lack of structured attestation verification meant we could not distinguish between a genuine YubiKey and a compromised firmware clone returning invalid X.509 certificate chains or incorrect AAGUID values.
The third solution implemented a structured authenticator matrix testing regimen with physical devices, where we cataloged each authenticator's capabilities (resident key support, attestation format, transport types) and manually executed ceremonies across browser and OS combinations. We intercepted traffic with Burp Suite and browser DevTools to inspect the clientDataJSON and attestationObject, specifically testing cross-origin scenarios by embedding the registration flow in iframes with varying allow attributes and verifying resident key behavior by setting requireResidentKey: true and attempting authentication with an empty allowCredentials array.
Chosen solution and result
We selected the structured matrix approach because WebAuthn behavior is fundamentally tied to hardware implementation and browser security policies that virtual environments cannot emulate. This methodology revealed that Safari requires explicit allow="publickey-credentials-get" attributes for cross-origin iframes, which Chrome infers automatically, causing the silent failures in the Epic integration. Additionally, we discovered that YubiKey 5 NFC returns transports: ["nfc", "usb"] but iOS Safari only enumerates nfc during the ceremony, causing the server-side allowCredentials filter to reject the credential when transport validation was strictly enforced. After relaxing the transport validation on the server to accept any transport advertised by the authenticator and adding iframe permission checks to our manual test checklist, cross-device authentication succeeded consistently across the hospital's mixed device ecosystem.
How do you manually verify the cryptographic integrity of an attestation object to ensure the authenticator is genuine and not a compromised firmware or emulator during black-box testing?
Many candidates assume attestation verification is purely a server-side concern. To manually validate, extract the attestationObject from the browser's PublicKeyCredential response (base64url decode to binary), parse it with a CBOR debugger (such as cbor.me), and inspect the fmt field. For packed attestation, verify the X.509 certificate chain against the FIDO Alliance Metadata Service (MDS) to check for revoked authenticators or self-attestation flags. For tpm attestation, validate that the TPM certificate includes the EK (Endorsement Key) and that the certInfo structure matches the expected hash algorithm. This manual inspection catches authenticators returning malformed signatures or incorrect AAGUID values that automated scripts might overlook if they skip strict attestation verification.
What is the precise distinction between User Presence (UP) and User Verification (UV), and how does this impact testing of resident keys (discoverable credentials) across platform vs. roaming authenticators?
Candidates often conflate the simple touch on a YubiKey (UP) with PIN entry (UV). In manual testing, you must verify that setting userVerification: "discouraged" still allows registration on a YubiKey (which only does UP), but setting residentKey: "required" forces UV on most authenticators because resident keys require protection. Testers miss that Windows Hello always performs UV (biometric or PIN) even when discouraged, while macOS Touch ID respects the flag but fails resident key creation without UV. You must manually test the ceremony with both required and preferred resident keys, observing whether the authenticator returns a credentialId during authentication without allowCredentials (proving it was resident), and checking the authenticatorData flags byte (bit 0 for UP, bit 2 for UV) using a CBOR parser to confirm the authenticator's behavior matches the options.
How do you test the excludeCredentials functionality to prevent duplicate registration when you only have one physical security key, ensuring the authenticator correctly identifies existing credentials?
This tests understanding of the client-side discovery mechanism. Manually register a credential, capture the rawId, then initiate a new registration ceremony with excludeCredentials containing that ID and the same user.id. A compliant authenticator should return a DOMException named InvalidStateError. However, candidates miss that Windows Hello and some Android keystores may return the existing credential instead of an error (which is valid per WebAuthn Level 2 spec if the authenticator does not support exclude lists). You must verify both outcomes: that the server handles the error gracefully, and that if a credential is returned, it matches the excluded ID and is rejected server-side. Additionally, test with a different user.id to ensure the authenticator does not incorrectly exclude credentials from different user accounts, which would indicate a severe privacy vulnerability.