Cookie Detection: How Cookie Names Reveal the Platform

## Why it matters

Session and platform cookies are named by convention. PHP defaults to PHPSESSID; WordPress uses wordpress_logged_in_*; Shopify uses _shopify_s. These are not secrets. They're set by the server and visible to any JavaScript running on the page. Because the platform controls the cookie name, it's a reliable signal. And because Scalpel Stack reads only the cookies your browser already sees (via document.cookie), it carries no privacy cost: you're not sending anything anywhere, just reading what's already yours.

## How it works

Scalpel Stack maintains a map of known platform cookies: their names and what they reveal. When you scan a page, the extension reads the current tab's cookies using the browser's native document.cookie API. It then matches each cookie name against the known patterns.

PHPSESSID matches a simple string lookup: PHP found. wordpress_logged_in_* uses a glob pattern to catch wordpress_logged_in_1a2b3c4d, wordpress_logged_in_example_com, and other variants. _shopify_* similarly catches all Shopify-set cookies starting with that prefix.

The cookie's value is never examined. Only the name matters. This is intentional: many cookies contain session tokens or personal data. Reading only the name means Scalpel Stack never touches sensitive information. A cookie named _ga (Google Analytics client ID) reveals Google Analytics; the cryptic value inside is irrelevant and never read.

## What does not matter

Cookie lifetime, domain, secure and HttpOnly flags: none of these affect detection. A cookie with a one-hour lifetime and one with a two-year lifetime are both equally informative if their names match known patterns.

First-party vs. third-party doesn't matter either. Scalpel Stack detects based on cookie name alone. If a third-party script sets a platform-specific cookie (rare but possible), it still signals that platform.

Also worth noting: the absence of a cookie doesn't prove a platform absent. Many platforms ship without setting cookies at all, or set them only after an action. An absence is not evidence.

## Code example

Opening the DevTools console on a WordPress site and typing document.cookie yields:

wordpress_logged_in_abc123=user_data; wordpress_nonce_abc123=nonce_value; _ga=GA1.2.123456789.1234567890
Copy

Scalpel Stack parses this and detects:

• wordpress_logged_in_abc123 → WordPress (auth cookie)
• wordpress_nonce_abc123 → WordPress (CSRF nonce)
• _ga → Google Analytics

A Shopify storefront might show:

_shopify_s=session_id; _shopify_y=analytics_id; _fb.1.987654321=facebook
Copy

Matching:

• _shopify_s → Shopify (session)
• _shopify_y → Shopify (analytics)
• _fb.1.* → Meta Pixel

The values themselves are opaque and safely ignored.

## How Scalpel shows it

Expanded evidence trails list each detected cookie under a cookies vector badge. The cookie name appears as the key, and a truncated, obfuscated version of the value (if shown at all) appears for reference. Because values are rendered via textContent, not innerHTML, no hostile cookie value can execute. A separate "Cookie (local-only)" note reminds you that nothing was sent anywhere.