I'm developing a social network and to my knowledge, the best way of storing between pages which user is logged on is using cookies. So, suppose I'm storing a cookie of the user ID which is logged in.

Anyway, what's stopping the user from changing the cookie's value in order to trick the website into thinking they're logged in as someone else?

  • 2
    the short answer is "session tokens"
    – schroeder
    Jun 7, 2017 at 19:11
  • 3
    you don't put sensitive data in the cookie, you have to acknowledge that any cookie value can be changed
    – schroeder
    Jun 7, 2017 at 19:12

3 Answers 3


So, suppose I'm storing a cookie of the user ID which is logged in.

That's not how session cookies work. The cookie shoudn't just contain the ID of the current user since that would obviously allow an attacker to tamper with the value.

Instead, a common approach is that the web application issues a sufficiently long, random session ID to the user and internally associates this session ID with the actual user account. Since a user is then assigned a new session ID after each login, it won't be feasible to predict the session IDs of other users or manipulate user-specific values by modifying the cookie.

Generally, you shouldn't have to invent your own session management scheme. If you think about how to store a user ID in a cookie, you're probably doing it wrong. Many frameworks already provide abstractions for cookie-based sessions. E.g., PHP has built-in support for session handling. Also have a look at the OWASP Session Management Cheat Sheet to learn about security considerations.

  • Okay, thanks. Would the session ID generally be associated with the user in the database? Jun 7, 2017 at 19:18
  • @JacobGarby Yes, depending on your architecture that's an option.
    – Arminius
    Jun 7, 2017 at 19:21
  • What would other options be? Jun 7, 2017 at 19:22
  • @JacobGarby You could store it in memory.
    – Arminius
    Jun 7, 2017 at 19:23

It is possible to store information in cookies and prevent users from tampetering with the data in the cookies. The way to do this is to create a HMAC of the cookie value and store that along with the cookie. Then whenever you receive a cookie value, check if it has the correct HMAC. Since HMACs need a secret key to create which only the server has, you know for sure that the cookie value was created by the server.

Some frameworks have this built in (expressjs, rails). This question discusses the concept of signed cookies some more.


If you authenticate a user based on a plaintext cookie with a username then you can't ensure whoever has the cookie is the person they say they are. Anyone can create a cookie with whatever username they want. It's up to you to ensure that they are who they say they are.

If I knew someone's username I could create a cookie with their username and bypass the login of the application and be whoever I wanted to be if there were no server side checks.

Instead of authenticating a user using a cookie I would suggest using a server side session, and pass an identifier of this session to the user to store as a cookie. Then when they request your page you can identify who the user is using their server-side session variables. The issue with this method is if your session identifier is easily guessable another user's session could be hijacked, but at least in this case the session could be cleared on the server.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .