<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Fedcm on bytemastermind's blog</title><link>https://bytemastermind.github.io/tags/fedcm/</link><description>Recent content in Fedcm on bytemastermind's blog</description><generator>Hugo</generator><language>en-us</language><copyright>© bytemastermind</copyright><lastBuildDate>Tue, 06 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://bytemastermind.github.io/tags/fedcm/index.xml" rel="self" type="application/rss+xml"/><item><title>FedCM as a Session Hijacking Gadget</title><link>https://bytemastermind.github.io/posts/writeups/web/fedcm-xss-session-hijacking/</link><pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate><guid>https://bytemastermind.github.io/posts/writeups/web/fedcm-xss-session-hijacking/</guid><description>&lt;p>An XSS on a relying party using FedCM leads to session hijacking, even when its session cookies are HttpOnly. This is an already documented consequence of exposing login credentials to JavaScript, and something worth remembering when assessing XSS impact.&lt;/p>
&lt;p>Let&amp;rsquo;s say &lt;code>example.com&lt;/code> uses Google to sign users in through FedCM in Chrome. Here, &lt;code>example.com&lt;/code> is the relying party (RP), and Google is the identity provider (IdP). The browser mediates the login, but ultimately returns a credential to the RP&amp;rsquo;s JavaScript through &lt;code>navigator.credentials.get()&lt;/code>. Its &lt;code>token&lt;/code> property contains the login assertion. This handoff is shown in &lt;a href="https://developer.chrome.com/docs/identity/fedcm/implement/relying-party">Chrome&amp;rsquo;s RP implementation guide&lt;/a>.&lt;/p></description></item></channel></rss>