A PHP Sessions is a series of random characters that form a unique identifier for each visitor (which we will call “session-id”). When a user is assigned a session id, the webserver creates a file in his system where he will enter all the data that we want to save. But how does the website recognize the user in serial connections? Well, using one of the two previous methods, that is, by making the user send their session id in the URL or by sending a cookie with it and with a duration of “until the browser is closed.”

In short, the ways that a website has to propagate data about a visitor are the URL or cookies. The problem with both resources is that they are easily modifiable by the user: the URL can be changed directly in the browser’s address bar, and cookies, being data on the user’s computer, can also be modified.

So, to save more critical data, a method that was not modifiable by users as needed (to avoid, for example, an authenticated user posing as another). Thus the sessions were born.

In this article, we will try to explain, in the simplest possible way, what PHP sessions are, how they work, and how the web server implements them. The purpose of this article is not to explain how to use courses, but to understand the mechanics of how they work, to understand how attacks work against them.

This article we try at people with little knowledge on the subject, so sometimes I will simplify specific details, knowing that what I say is an only half-truth (as when they taught you that the square root of a negative number did not exist).

View more about PHP Sessions below:


The protocol used by the web ( HTTP ) is stateless; that is, it does not save any information about previous connections: it does not know what web page you were on before or if you have already sent data to the website. The only thing the site knows is the data that reaches it through the URL.

Since some web pages wanted to be able to recognize visitors and save their data from one connection to another without dragging a lot of parameters in the URL, the already famous cookies were invented. 

A cookie is a piece of information that is saved on the user’s computer and is associated with the browser with which you visited the website. 

It means that each browser saves its cookies and does not share them with other browsers. How this information is collected depends on the browser, although many stores it as text files in a given directory.

When a browser is going to open a web page, if it has any saved cookies associated with that website (actually, that domain ), it takes the data from it and sends them to the web server together with the request for the page.

The website that sets a cookie also tells the browser how long it should last (maximum): from “until the browser is closed” to any amount of time. A domain can only access cookies that it set itself in the browser; that is, an area cannot access cookies from other fields.

Let’s see an example: let’s say that we have a multi-language website and that when we choose a different language, it wants to remember it, always to serve us its web pages on it. So what you would do would be to send a cookie to our browser, with the name “language” and data “English.”

The browser will create a file for that cookie and save the data inside. When the user makes a new request for a web page, the browser will send something like “language = English.”

How do sessions in PHP Sessions work?

We better explain it with an example: we have just authenticated ourselves on a page with our username (Webfrog) and password (******). The website verifies that they are correct and wants to recognize us in the following connections.

The data you want to save is “user = Webfrog”. You cannot use the URL for this because anyone who puts in the address bar “user = Webfrog” could access our account. For the same reason, you cannot use cookies, since any user would only have to find the file of their cookie and modify it so that it says “user = Webfrog”. So what you have left are the sessions.

Using PHP, the web server assigns this user a session id (for example: “31d7bgphebfemb55311b1cger6”), creates a file on your system (in this example with the name “sess_31d7bgphebfemb55311b1cger6”) and enters “user = Webfrog”. Since this file is not on the user’s computer, but on the server itself, it can only be modified by the website.

Then, the server sends a cookie to the browser named the session name (by default and for this example “PHPSESSID”) and value the session id (“31d7bgphebfemb55311b1cger6”).

Thus, when the user goes to another page within the same website, they will send the server the value of their cookie: “PHPSESSID = 31d7bgphebfemb55311b1cger6” (this same effect can be achieved using the URL ).

In this way, the server knows that the user is the one with session-id “31d7bgphebfemb55311b1cger6”, so it will search for the file with its data (“sess_31d7bgphebfemb55311b1cger6”) and pass them to the web page.