Acme Inc. — Latest news
A boring marketing page. No login. No account. No passkey functionality. Nothing here should ever invoke WebAuthn.
But a third-party analytics tag has been compromised and is now attempting to register a passkey on your account whenever you interact with the page. Click any of these innocuous-looking buttons to see what happens:
evil-cyber-hacker.com has hooked every interactive
element on the page. When you click, it calls navigator.credentials.create()
using the parent site's RP ID. The browser fires a real passkey prompt, branded for this
site, that you never asked for. If you complete the ceremony out of confusion, an
attacker-controlled credential is silently registered to your account.
💡 CSP is not the answer here — in this realistic scenario the script is from a CDN you've already trusted. The right defence is to remove the capability from pages that have no business with it.
The compromised analytics tag is allowed to load (whatever your CSP says about
script-src, this CDN was on the allowlist). Once running, it has the
same privileges as your own page code — including the ability to call
navigator.credentials.create(). There's nothing about being "third-party"
that PP can use to deny it, because PP gates per-document, not per-script. The
only way to stop this attack is to remove the capability for the whole
document — which is fine, because this page never legitimately needs it.
Why CSP doesn't fit: CSP script-src gates where code
comes from. If you've allowlisted the CDN (or the script was injected via some other
allowed channel), CSP has nothing to say. CSP and PP are answering different questions.
Activity log
Real-time trace of what the analytics tag tried to do, and how the browser responded.