Incomplete fix: when the server accepted an empty cookie

A session cookie present on the web side. An API fully accessible without it. And a deployed fix that only went halfway. What this case illustrates goes beyond the technical vulnerability: it's a lesson in how fixes can fail to resolve what they claim to resolve.

Context

A retail SME commissioned the development of an internal application (web and mobile) to let employees check available stock across their stores. Read-only: no writes, no transactions. But the data has value: stock levels by reference, availability by location. The client's requirement was clear: this information should only be accessible to authenticated employees.

The web discovery

I start by analysing the traffic between the browser and the API. The application sets a session cookie after login, nothing unusual. What is unusual: stripping that cookie from subsequent requests and replaying them manually, the API responds normally. All stock data is accessible, with no cookie, no session.

The server was accepting requests without checking whether the caller was authenticated.

The issue was not in the interface: it was the underlying API that failed to check the session. The web application created the illusion of protection because the frontend required a login, but server-side, no check was performed on the API endpoints.

Why it matters even for an «internal» app

The application is accessible only on the company's network. But that doesn't change the fundamental: any employee, contractor, or visitor on the WiFi can access all the data without identifying themselves. If an attacker reaches the network (through a compromised workstation, physical connection, or poorly segmented Wi-Fi), they reach the data.

The fix… and the mobile app test

A week later, the fix is deployed. I test the mobile application, which uses the same API. This time, the cookie is correctly expected by the server: a request without a cookie is rejected. Progress.

But testing with a cookie present but empty (value: empty string), the server accepts the request. Stock data is still accessible.

The fix had added a check for the cookie's presence. It had not added a check for its validity.

An empty cookie is not a session. Checking that a token exists is not checking that it is valid.

What this illustrates

Testing the remediation is part of the pentest. A partial fix can create false security: the team thinks the problem is solved, the cookie is "there", basic tests pass. But an attacker who knows this class of vulnerability will specifically test edge cases: missing cookie, empty cookie, malformed cookie, expired token.

The right practice for developers: authentication verification should be middleware applied systematically to all relevant endpoints, not an ad-hoc check added case by case. A central function, unit-tested, that validates the session completely: existence, format, signature, expiration.

This case didn't come from a negligent team. It came from a fix made under time pressure, without a precise specification of the expected behaviour, and without an external eye to validate that the result matched the intent.