First-party cookie received on initial contact.
Secure and HttpOnly were not set.
When we open a registration page, we see a form, a few fields and a button to create an account. What we do not see is the information exchanged between the browser and the server at that same moment.
This story began with a registration page for an international technology event. The service was hosted on a widely used B2B platform. On the first visit, before the form was completed, the server returned an identifier cookie designed to remain in the browser until September 10, 2027.
The name of the platform is not the important part. What matters is what the audit made visible.
A persistent identifier on first contact
The cookie was first-party, expired in September 2027 and used SameSite Lax. Secure and HttpOnly were missing, two attributes with a precise role in cookie protection.
Secure restricts transmission to encrypted connections. HttpOnly prevents page scripts from reading the cookie directly through browser APIs. Their absence does not mean an attack occurred, but it does mean those two protections were not active.
The initial HTTP response and static HTML contained no third-party cookies and no references to known marketing, analytics or profiling services. This is useful information, although a modern page may load additional elements later through JavaScript.
The question left by the report
Why does a visitor receive an identifier lasting one year before creating an account?
Lifetime alone does not reveal the cookie's purpose. It may serve a technical function or support other activities. Understanding it requires comparing observed behaviour with the privacy notice and the provider's explanation.
We do not know, from these data alone, what the cookie's purpose is. We do know, however, that the cookie was present and we can document its characteristics.
Making the invisible visible
This need led to Cookie Tracker, the open-source tool developed by MCProjectLab to make the first exchange with a website easier to understand.
Cookie Tracker visits a page, collects the cookies it receives and shows their domain, lifetime and main security attributes. It also examines scripts referenced in the initial HTML and flags links to known analytics, advertising, tag-management and session-recording services.
Cookie Tracker analyses the initial HTTP response and static HTML without executing JavaScript.
Results can be saved as JSON or CSV and retained as technical evidence. Cookie values are excluded because documenting a cookie's properties does not require storing the identifier itself.
The tool goes beyond the generic statement that a site “uses cookiesâ€. It shows which cookies were actually received, how long they may last and which protections are active.
Cookie Tracker
Open-source inspection of HTTP cookies, security attributes and tracker references.
From perception to evidence
Privacy notices and banners are necessary, but they describe what a service declares. An audit observes what the system actually does. A serious assessment begins by bringing those two layers together.
Cookie Tracker does not issue legal verdicts and cannot replace a complete browser analysis. Its role is more concrete. It turns an invisible exchange into data that can be read, compared and discussed.
In this case it documented an identifier expiring on September 10, 2027 without Secure and HttpOnly. A simple finding, but enough to ask precise questions about its purpose, duration and protections.
It is precisely this difference between assuming and measuring that gave rise to Cookie Tracker.
Digital transparency begins when what happens behind a web page stops being invisible and becomes verifiable.
Sources
Italian Data Protection Authority, Guidelines on cookies and other tracking tools, June 10, 2021.
RFC 6265 HTTP State Management Mechanism, sections covering Secure and HttpOnly.
IETF draft-ietf-httpbis-rfc6265bis-22, section covering SameSite. Sources accessed September 11, 2026.