Staying connected to MWP dashboard: how about the threat of stolen session cookies?

after reading about the threat of stolen session cookies when not logging out from a wordpress site, I asked myself how secure it is to stay connected to the MWP dashboard all day long.
If would miss it very much to be able to jump to the backend of every child site easily from the dashboard.
Looking forward to learn,

1 Like

Hey @lhberg

Signing out of any WordPress site after use is a good security practice, and that includes sites with MainWP Dashboard installed.

Other best practices also naturally apply, such as keeping everything up to date, using HTTPS for the Dashboard site, and so on.
The only difference is that because of its importance, one will want to be even more sure to follow those best practices with the Dashboard site.

It’s certainly a balance between convenience and security.

Hi Bojan,
thanks for your reply.
Sure I’ve implemented all the best practices you mentioned plus 2FA.
But, afaik, apart from partly https those don’t contribute to security and twhart stealing the session cookie.
If I understand you right, there is no additional hardening possible from MWP’s side.
Is running the dashboard from a local setup with a fixed IP address a more secure way?

1 Like

That is correct.

Yes, running the Dashboard from a local setup will help with the session cookie theft, but only if the local setup is not exposed to outside connections.

However, using a server-side IP whitelist might help regardless of whether you’re using a local host or a web host.


MainWP dashboard creates session cookies for each child site when you click through to the admin side. So, for what it’s worth, logging out of each child site when you’re done with it is helpful as well.

As far as the dashboard site itself, and my understanding of how session cookies can be stolen, there are two attack vectors. One is intercepting the network traffic. If you’re using HTTPS, this should be a minimal issue. If you’re on a local network or a VPN, that would help too. Or in my case, the same physical computer runs the dashboard site and the browser I use to access it, so there’s no network traffic at all. Which leads to the second vector, gaining access to the client computer. From what I understand, this is by far the more common attack vector. If an attacker can get malware onto the computer that you use to access your dashboard, they can lift the session cookie(s) out of the browser data stored on that computer. To mitigate against this, it is important to keep that computer secure and to limit its network access (both sending and receiving connections with arbitrary remote hosts).

Bojan also mentioned an IP whitelist on your dashboard server. The idea here is to limit what hosts can connect to the dashboard site at all. Even if they steal a session cookie, if there is a firewall or other mechanism (like a local-only network) that prevents bad actors from accessing the server at all, they can’t do anythign with the session cookie.

Another way to mitigate against this kind of attack is to have WordPress verify the IP address using a particular session cookie and invalidate it if there is an unexpected change in the address. For example, if the session is created with a New York IP address but then later an attempt is made to use the same session cookie from Australia, invalidate that cookie. I am told there are plugins that can do this. It’s impractical to always restrict a session to a particular IP address because some clients and some networks routinely move around. (e.g. I want my phone to stay authenticated whether I am on my home wifi or if I am on the cell data network.) However, if you know this is not the case, you could use a technique like this.


Hi Kenneth,
thanks for elaborating!
I fully agree with all your arguments.
I digged deeper as well and found this article, putting the threat into perspective.
And I searched for a plug-in to invalidate the session cookie on an IP address change to no avail. The only solution I found is to invalidate it after a certain time of inactivity but I wouldn’t like to be disconnected perpetually.
Looks like there is no recipe for total security as a last point.


Thank you for this article and its perspective. I heard about the session cookie issue (and the 60% figure) from Thomas J. Raef on the WP Tavern podcast. Those who are curious can listen to his account and make their own judgement on the validity of his research methods.

Sorry for not giving the details in the earlier post. Thomas recommended Solid Security from SolidWP (evidently formerly iThemes Security), claiming that this plugin will limit a session cookied to a particular IP address. He also recommended Calvin Alkan’s Snicco Fortress as a good security plugin. It addresses the issue by managing logins and sessions in a completely different way that effectively renders stolen session cookies useless.

Unfortunately, both of those plugins are expensive. My advice, to the extent that it is possible, and specific to MainWP Dashboard, is to restrict the whole site by IP. As Bojan suggested, using an IP allow list to only allow people on your trusted network to access the dashboard also renders stolen session cookies useless, and it’s a much cheaper and simpler solution. Of course, this only works if your team doesn’t need to access the dashboard from outside the office, so to speak. If they do, maybe a VPN for those cases would be a good option to consider.

I appreciate the reminder that stolen session cookies are only one of many possibly security threats to WordPress broadly and MainWP dashboard in particular. It is one that has gotten some attention recently, but it is not the only vulnerability out there by a long shot. I always learned that the biggest security threat is the user (weak passwords, sessions left open on a public computer, vulnerability to phishing, etc.) so kudos to all those here thinking about keeping things tight.


thanks for the additional remarks.
I happen to be a longtime iThemes Security Pro user and Solid Security Pro is active on the dashboard site and most of the sites I maintain from there.
Kind regards,
PS: the same kudos also from my end


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.