In most scenarios, the data in the session is itself secure against user tampering as it is only manipulated on the server (this assumes the server itself is secure). So there is no reason to treat the data stored in session as "dirty" as far as needing to cleanse/validate it.
The session itself is not inherently secure whether it is being propagated via cookies or via URL parameter. It can be impersonated via a session hijacking attack. There are a number of common techniques to prevent against this, including:
- using only secure cookies transmitted over SSL
- using sufficiently long session ID's (most default implementation uses in modern langugaes do this by default). This makes it harder to "guess" at a valid session id value and minimize collision of session ID's.
- regenerating session ID's after application login
- checking against secondary data (IP address, browser user agent, etc.) to see if there are changes during a session which may indicate a hijacking attempt. Probably best to use a combination of factors here (like a change in both IP address and user agent since with mobile devices IP addresses can and do change).
- active session id rotation (i.e rotate session id on each page load)