I was going to add this as a comment on Alexander, a great answer, but it will be a little detailed.
How long a cookie is stored in the browser and how long the session data is stored by the server in the absence of a request are two separate and independent things. This cannot be avoided due to the statelessness of HTTP - although there are some things you can do to mitigate what you perceive as a security flaw.
In order for the browser to access the same session after it is closed and for a certain delay, it is required that both cookies are stored in the browser (which Alexander has already explained), and the server saved the session data.
The behavior that you describe can be much more pronounced on systems that process a low volume of requests and where the session handler does not check the TTL of the session data (I'm not sure if the handlers are executed by default, or if they just assume that any recovered session data is considered current).
You did not provide any information about configuring 2 servers, in particular session.gc_maxlifetime.
If session.gc_maxlifetime has timed out between requests, but the session data is still available, this means that the session handler simply considers this as the time when the session is considered suitable for garbage collection (which in semantics is what the configuration option is for). However, there is a strong argument in favor of this value as TTL. To solve this problem, you can either make garbage collection work more often, or delete session data, or use a session handler that ignores session data that exceeds the specified limit.
What you see the difference between the two systems may be due to different values for session.gc_maxlifetime or differences in the frequency of garbage collection or even different session handlers.
source share