A renamed cookie and a logout button that did nothing

After the first review I renamed the session cookie to __Host-session. The prefix makes the browser accept the cookie only over HTTPS, with no domain attribute and with the path set to the root, which closes a few ways of planting a fake session. Login and the password change both started using the new name.

The logout code kept the old one. It read a cookie called session, found nothing, deleted nothing on the server and cleared a cookie that no longer existed. The Exit button redirected to the login page and looked as if it had worked. The session row in the database stayed valid, and so did the cookie in the browser, for up to 14 days. On a salon computer that two people share, the second person would open the clients page and be logged in as the first.

Every automated test passed. I had tests for the password hash, for the rate limit, for the form validation. None of them pressed Exit and then asked whether the session still worked.

The reviewer found it by reading the logout file next to the login file. The two files used different names for the same thing, and that difference is easy to see when you read both in one sitting and easy to miss when you wrote them in different weeks.

The fix took one line. The logout now reads __Host-session, falls back to the old name for anyone still holding one, deletes the session row and clears both cookies. A new test checks that the logout file mentions the new cookie, which is a modest test, and it exists because I have seen what happens without it.

When I rename something that appears in several files, I search the whole project for the old name before I call the job finished. When a feature touches security, I also ask what a user does with it: log in, log out, log in again, and see if the old session still works.

Disclosure: drafted with a local AI model, then reviewed and approved by me. Originally published at https://bbal-blog.kairo-app.workers.dev/a-renamed-cookie-and-a-logout-button-that-did-nothing/