Much of the use case

Given that the id is not the sole criterion for user access to the system, there is no problem. Stack Overflow itself displays the user id in the URL, that is, it is not a confidential data. You will only need to take certain measures for security if at some point your application needs to grab the cookie id and send it to the server to fetch some user information.

Case example:

If it is to be used in this way, it is extremely unsafe, since anyone could change their own cookies to pick up data from any user on your system. Therefore, you would need one more security factor to ensure that only the user who logged in to that machine might be doing a data search.

We will have 2 possible solutions to have a secure system in this case:

• At the time the user logs in, create a token and store it linked to the user id in your server database and client cookie.
• Save the id of the user in the session, and when the user requests some information, check if the id that was passed is the same as in the session.

Using one of the 2 measures mentioned above you could safely store and use not just the id, but various data that you should save on the client side of your application.

I recommend that you study if it is really necessary to use cookies or session, and what is the best way to use it. Both are linked to the performance and security of your system.

Any data entered into a cookie is visible to the user (if he knows how to access it, of course), as well as being passive of being changed by the user. So to say whether it is safe or not depends on what the consequences of this exposure of the ID.

Rarely, a user ID is secret, so I do not see much of a problem with it being read. But if in a particular case this is a problem, it is better not to send it to the user, save it in the session for example (best option), or alternatively encrypt it before sending (worse option, only use if you have no alternative ).

As for being changed, it depends on how it is being used, as already discussed in the other answers. In general, the change can be problematic if it allows a user to impersonate other users. In this case, it is important to avoid this change.

A method, already mentioned, is the use of a session ID or other random access token that can not be "guessed" in practice (recommended, in particular because the vast majority of languages / frameworks support to this method, including PHP). Another would be to sign the cookie before sending it to the client (either using digital signature [asymmetric] or, simpler, an HMAC), checking the signature when receiving it back. In this way, the data can still be read by the user, but any changes in them would invalidate the signature, causing the cookie to be rejected by the server. This method is useful when you can not / do not want to store sessions on the server, but at the same time it is more complex to implement correctly (and easier to make mistakes!), So I leave it as an alternative.

No, it's not safe

cookie is clean text information that is stored in the user's browser, where there is no control at all. Not only can you see this data, but it's also easy to change . If your system relies on this field to identify the logged in user, simply change the user id to become another user without going through the password.

The safest method is to save the user id in a session , whose data is stored on the server, far from the possibility of being altered by the user.

For the user a random session ID goes. And by being random, trying to tinker with this ID will most likely result in an empty session, and therefore useless to a malicious user.