One of the most useful applications of cookies is the capability to create sessions, which truly allow you to overcome the state-less nature of the HTTP protocol. When working with sessions in PHP, you are given the capability to store variables (including arrays and classes) between script executions and recall them later. For this system to function, the Web server must be able to identify one Web browser from another, and this is where cookies play their role. Unlike my previous example of using cookies to identify a user, sessions do not actually store any significant information on the client machine. As with the car valet analogy, sessions work on the concept that each individual client browser is given a "ticket" (called a session ID), which is then presented to the Web server during every request. This session ID is then matched up with the relevant data and that data is again made available from within your PHP scripts.
Although sessions do offer a fair amount of security (because no sensitive information is being stored on the client browser itself), sessions are by no means completely secure. Because all the data for a particular user is tied to a single identifying string, it is possible (although unlikely) for a malicious user to hijack a session by guessing or otherwise acquiring a valid session ID. This may or may not be a serious issue, depending on the need for security on your website. It is generally considered good practice to develop a website under the assumption that a session will be hijacked; thus all critical pieces of data (credit card numbers, for example) should always be inaccessible if the session ID is compromised.
