Will It Vibe?Sensitive field passed as a URL query parameter
Part of Documentation, UX & Accessibility, which counts for 15% 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 URL is built with a password/token/card/SSN-named query parameter. Query strings land in server access logs, proxy logs, browser history, and outgoing Referer headers.
Why it matters
Putting a password, token, or other sensitive field into a URL's query string means it gets written wherever URLs get logged: web server access logs, CDN and proxy logs, browser history, and the Referer header sent to any third-party resource the page loads. Query strings are also commonly cached and can be bookmarked or shared without the sensitive part being obvious. This is a well-documented class of exposure (CWE-598) and is why sensitive values belong in a request body or an Authorization header instead.
How to fix it
Move the sensitive value out of the URL and into the request body for a POST/PUT request, or into an Authorization header for a token. If the value must be short-lived, use a one-time reference id in the URL that the server exchanges for the real value server-side rather than passing the sensitive value itself.
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