Is there any security benefit to not using cookies?

Why cookies, and what are the alternatives?

HTTP is stateless. A webpage that remembers you (so you don't have to reenter your password every time you visit a new page) is stateful. To bridge the gap between the stateless protocol and the stateful applicaiton you need some kind of session identifier that is included in every request.

The standard way to do this is with a cookie. But you could put it anywhere in the HTTP request. Some examples:

• A common practice back in the day was to put the session identifier in the URL, but this meant it ended up in all sorts of logs and leaked via the referer header. Not so good.

• A single page app could just store the identifier (e.g. an authentication token) in a JavaScript variable on the client, and then send it in a custom header with every request. It would be like a cookie that only lives for one page load. (As Marko Vodopija points out, the security would be somewhat weaker here, since the identifier could not be protected by http-only like a cookie can.)

You can think of these as different ways of "simulating" a limited version of a cookie.

PHP uses cookies for its sessions, by the way.

Why do some people dislike cookies?

There is nothing inherently insecure about cookies, and using them is not less secure than any of the more contrieved alternative methods. On the contrary, as we have seen, some replacements are worse.

The reason some hate cookies is the same reason they are so useful - they make the web stateful. This means that they can be used to track you, with all the privacy implications that comes with. So some might want to disable cookies completely.

That is probably the reason why a privacy focused site would offer a cookie free alternative. It doesn't make the site itself any safer, but it can service users who have cookies turned off for privacy reasons.

Just a complement to @Anders's answer.

Cookies are one way to have stateful sessions in HTTP which by itself is a non connected stateless protocol. Sessions are necessary for web applications, and any in line business.

Cookies used to be frowned upon as was javascript in the early times, because first is a way to collect usage statistics and has privacy concerns, while the other allows the server to control the browser, which has security concerns. Nowadays, many sites are simply not useable with cookies or javascript disabled, and disabling them in a browser is not always a trivial task. So my opinion is that is fine to provide a service requiring cookies. Just display a warning page saying that your service requires cookies if you cannot establish a session.

URL rewriting is (was?) an alternative to cookies to provide sessions in HTTP. In that mode, you consistently add a parameter consisting of a key and the session identifier. All session data should be carried server side in that mode. That way there is no additional risk of data leakage because only the identifier is exchanged in the URL. The downside is that it is not bookmark friendly: the URL does contain the session id, so if you bookmark the URL of a page including it, you will get an invalid session error when you try to use it later. And it is much harder to use than a cookie to pass information between sites of same domain. For that reason cookies is now the standard way to have a stateful HTTP site or application.

People that do not like cookies will also argue that as there is no persistent equivalent in URL rewriting, and that persistent cookies are highly used to collect data on client behaviour, major Web companies (Google, Facebook, Amazon, etc.) willingly only allowed cookies to browse their sites, and that because of that URL rewriting has been more or less abandoned. Be it true or false, it is just now meaningless because the fact is that cookies are required by most sited and allowed by most users.