Shared Site And Administrator Sessions
Shared Sessions lets one cookie log you into both your Joomla site and /administrator, so a front-end XSS bug can reach an authenticated admin session.
How common is this?
- 4.2% of the Joomla sites we have this data for fail this check. Platform: Joomla.
Measured across the sites we audit, on each site's most recent snapshot.
What this check and mySites.guru tool looks at on your site
This check reads the $shared_session setting in your site’s configuration.php file. Shared Sessions has been available since Joomla 3.7.0. When it’s enabled, your public site and your /administrator area share a single session cookie, rather than keeping two separate ones.
How a front-end bug becomes an admin breach
With Shared Sessions on, logging in once logs you in everywhere the account has access, front end and administrator alike. That sounds convenient, and it is, right up until something goes wrong on the public side of the site.
Normally, a cross-site scripting flaw in a vulnerable Joomla extension, a compromised template, or a stolen cookie on the front end can only ever compromise a front-end session, an authenticated visitor account at worst. With sessions shared, the same session cookie is valid in /administrator too. The exact same bug that would ordinarily be a minor front-end nuisance becomes a route straight into an authenticated administrator session, with no separate step required. The front end stops being a lower-trust surface than the back end, because one session cookie now speaks for both.
Walk through the actual sequence, because the individual steps are each ordinary on their own, and it’s only the combination that turns dangerous. First, a vulnerable extension, a comment field, a contact form, a user-profile field, accepts input it should have escaped and renders it back to other visitors unescaped. That’s an everyday, well-documented bug class, and it exists in some extension on some Joomla site every single day; it is not exotic. Second, a Super User with Shared Sessions on happens to browse the front end of their own site, as site owners routinely do, while their administrator login is still active from earlier. Third, the malicious script runs in their browser with the same session cookie their /administrator login is using, because that’s precisely what Shared Sessions means: one cookie, valid everywhere. The script can now make requests as that authenticated administrator. Nobody had to break into /administrator directly, guess a password, or bypass MFA. A minor content bug on the public side became a fully authenticated administrative session, because the one setting that would have kept the two separate wasn’t there to stop it.
With Shared Sessions off, the exact same vulnerable extension and the exact same malicious script only ever reach a front-end session. Still worth fixing, but no longer a route into the administrator area on its own.
Quick test: log in to /administrator, then open your site’s front end in the same browser. If you’re logged in there too, sessions are shared.
Two cookies, not one
Shared Sessions is off. The site and /administrator use separate session cookies with separate names, so a compromise reaching the front end doesn’t automatically reach the back end as well.
It’s worth understanding why the setting exists at all, since it isn’t there by accident. On a site where the same people log in on the front end (as a member, a subscriber, a forum user) and separately administer the back end, Shared Sessions removes the need to log in twice. That convenience is real. It’s also a poor trade against what it costs: the front end of any site, by its nature, has to accept more untrusted input and run more third-party extension code than the administrator area does, which is exactly why keeping the two separated is worth more than the login it saves.
How to fix it
- Login to the Joomla administration, e.g.
https://yoursite.com/administrator. - Go to System, then Global Configuration.
- Open the System tab and find the Session panel.
- Set Shared Sessions to No.
- Click the Save button.
Flipping this setting in either direction ends every active session on the site, including your own, because the session cookie name changes for both the site and the administrator. Expect to be logged out and have to sign back in straight after, and warn any other administrators before you make the change so nobody mistakes it for the site being hacked.
Do this alongside a proper look for the vulnerability that would otherwise exploit it, rather than instead of one. Turning Shared Sessions off closes the specific route from a front-end bug to an authenticated administrator session, but it doesn’t fix whatever front-end bug might exist in the first place. If an extension has an unpatched cross-site scripting flaw, that’s still worth finding and updating on its own merits; Shared Sessions being off just means that flaw, if it exists, stops being an automatic route to full administrative access.
Shared Sessions and MFA address different stages of the same problem, and are worth treating as a pair rather than a choice between them. Forcing Multi-Factor Authentication on Super Users raises the bar on an attacker obtaining a valid session in the first place. Keeping sessions separate limits what a session that does get stolen or hijacked, by whatever means, can actually reach once they have it.
What mySites.guru does about it
mySites.guru checks every connected site for this setting and can turn Shared Sessions off across every connected site with one click.
Shared Site And Administrator Sessions
mySites.guru checks every connected site for this automatically and flags it the moment it appears. These run twice a day on every connected site.
It can also fix this across every connected site with one click.