Will It Vibe?Sensitive value stored directly in session/cookies
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
A value with a name like password, ssn, or api_key is assigned straight into session[...] or cookies[...]. A plain cookie is stored client-side, readable and tamperable by anyone with access to the browser, and even the session store bypasses the encrypted/signed accessors Rails provides for exactly this kind of data.
Why it matters
A plain cookies[...] value is stored in the browser and is readable, and if not otherwise protected, editable, by the user it belongs to or by anything with access to their browser or network. Putting a password, SSN, card number, or API key there directly, instead of through Rails' encrypted or signed cookie jars, means that value is sitting in the clear on the client for anyone with browser access to read.
How to fix it
Move the value out of the plain cookies/session accessor and into cookies.encrypted[...] (or cookies.signed[...] if tamper-detection without confidentiality is enough), which Rails already provides for exactly this purpose. Better still, avoid storing the raw sensitive value client-side at all: keep a reference (a token or id) in the cookie and look the real value up server-side when needed.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo