Link fragment carries a session token — deprecated OAuth shape, now a SPA phishing pattern

A link href has a fragment (the part after `#`) that contains a session token, access_token, id_token, JWT, or auth blob. Legitimate "click here to verify your email" links always put their tokens in the query string because the destination server needs to read them — fragments are NEVER sent to the server in an HTTP request, they are only readable by JavaScript running on the landing page. So a token in a fragment can only be consumed by client-side code, which is exactly the shape of a SPA phishing page that reads the fragment, pre-fills a credential-harvest form with the victim's email, and ships the stolen credentials to the attacker server via XHR. Historical note: OAuth 2.0 Implicit Flow used fragments for access_token and id_token, but the OAuth 2.0 Security Best Current Practice (RFC 8252, 2017) deprecated it and RFC 9700 (2024) formally retired it — every modern OAuth-using app migrated to Authorization Code Flow with PKCE years ago, which returns tokens via POST body to a backend. A legitimate email from 2025+ effectively never links to a URL with a token in the fragment. Detection matches the following fragment parameter names (case-insensitive): access_token, id_token, token, session, auth, jwt. Weight: +3 — moderate, combines with other URL signals rather than solo-triggering.