I'll have to answer this based on a lot of assumptions, but I'll update my answer if you edit your question and let me know.
What is UserId
?
If this is a cleartext ID of the user then it could be a risk to your system.
e.g. if your admin account had ID 0
and then a malicious user set their UserId
cookie to 0
- would this enable the malicious user to act admin?
You haven't said what tokenId
or sessionId
are either so it is difficult to comment further, but for the purposes of this answer I will assume that tokenId
is an Anti-CRSF token and sessionId
is the authentication session ID.
If this is the case, then UserId
should not come from a cookie value or from a hidden field on your page - it should be derived server-side from sessionId
and should come from whichever session the current user has authenticated with.
There is no inherent risk of displaying tokenId
and sessionId
in source if you have set the appropriate headers to disable public caching, but if these values are already available in cookies then there is no need to set them again in code. This smells of a potential business logic flaw as your AJAX request will be sending the values in two ways (request and cookie) - so make sure that you are only using one way to ensure all your logic is consistent.
So to summarise, the most "secure" place for session data is actually in cookies because they will not be cached outside of the cookie mechanism (such as within the source of cached pages). However, make sure that these cookies are only sent over HTTPS and are not available over the DOM by setting the Secure and HTTP Only flags.