As far as their use within WordPress, there is no native method to use $_SESSION. This means it is entirely on you to mitigate any security issues this presents.
Other problems depend on how your session data is saved. One problem I’m aware of is when the allocated memory for memcache is reached, it will drop the least recently used objects to make room for new ones1. But then, this also shouldn’t a problem for $_SESSION if you can allocate the appropriate amount of memory to support your site’s level of traffic.
WordPress has an API for transients where the data is stored in the database unless a caching plugin is used (I believe this is ultimately determined by wp_using_ext_object_cache2). When stored in the database, the loss of least recently used data shouldn’t be an issue with transients. There may be advantages and disadvantages to this (database vs fast memory), but I just wanted to demonstrate an example of WordPress’s native stateless design solution to storing temporary data. This problem would have to be solved on the server side, outside of WordPress if it should arise while using $_SESSION.
There are performance advantages/disadvantages depending on whether session is saved in hard disk files, RAM, database or other. These relate more to how the server is set up than the use of $_SESSION in WordPress though, since WordPress is essentially blind to the use of $_SESSION.
WP Engine has posted a good outline for why they don’t recommend the use of $_SESSION with WordPress3, which I’ve posted below. Some of these are more applicable to how the server is set up, but take a look and decide how they might affect your site and if you think $_SESSION is a good solution for you. As I said, WordPress is blind to the use of $_SESSION, it’s not handled natively, which leaves this open to the broader scope debate of whether it should be used in your PHP code at all.
PHP Sessions
We do not currently recommend using $_SESSION variables
at all. This is for a number of reasons:
While WordPress itself supports the use of $_SESSION, WordPress is stateless and does not natively use $_SESSION. The proper way to work
with WordPress is using cookies.There are a number of security concerns when using $_SESSION.:
- Session Poisoning
- The attacker first visits the victim’s page, and e.g. logs on. Attacker then uploads a PHP script to his account, and has it display
context of $_SESSION (set by victim script).- Attacker determines which variable needs to be changed, uploads a script which sets this variable, executes it.
- Attacker visits victim pages to see if anticipated exploit worked.
- This attack only requires that victim and attacker share the same PHP server.
- The attack is not dependent on victim and attacker having the same virtual hostname, as it is trivial for attacker to move the
session identifier cookie from one cookie domain to another.Session Fixation (on shared servers) For more information, see these two links:
- http://phpsec.org/projects/guide/4.html
- http://phpsec.org/projects/guide/5.html Session ID Hijacking (on shared servers)
Session ID hijacking can be a problem with PHP Websites. The PHP session tracking component uses a unique ID for each user’s session,
but if this ID is known to another user, that person can hijack the
user’s session and see information that should be confidential.
Session ID hijacking cannot completely be prevented; you should know
the risks so you can mitigate them. Depending on what plan you’re on
with us, your site may run on a shared Web server. Be aware that any
session variables can easily be viewed by any other users on the same
server. Generally, the best way to mitigate this vulnerability by
storing all sensitive data in a database record that’s keyed to the
session ID rather than as a session variable. Non-sensitive data can
be stored in cookies.- For our customers who are set up on clusters, we would have to completely change how our load balancers work, just to make sure that
$_SESSION variables were available between different servers.