My approach is similar. The session cookie (id-cookie) just represents a unique id that maps to a session on the server. So, as soon as the handler starts running, the flashes are popped from the session, regardless of if the cookie ever gets back to the user.

I do update the session cookie’s expiration time with every visit so I don’t extend session cookies past the point when they expire.

> I only need to reset the cookie when the (short) expiration has been exceeded, I’ve validated with the database again, and I have a newly-timestamped cookie. This seems like it could be subject to a sort of replay attack, if I understand correctly. I’m guessing it’s probably not much of a concern for your app, but someone could conceivably mine expired cookies off of your users’ computers and then use them to log in.

I see your point. There is a mitigation in that an unused session is expired after a much longer timeout (30 days, currently), and can also be explicitly logged out (including from another session, where you can see a log of all activity). But I think it would make sense to add a protection against this specific replay attack. We already log in the database each time we refresh an expired cookie. My initial thought is that we should check that time and refuse to renew the cookie if we have granted a more recent one, with some small tolerance for being roughly at the same time. And then we should revoke the session if it looks like someone is trying to replay an old cookie.