secret.url_credentials
A username and password embedded in an http(s) URL or an HTTP Basic Authorization header appears in the text.
What it looks at#
Two shapes. A URL such as https://user:password@host/, and an Authorization: Basic <base64> header whose base64 decodes (bounded to 512 characters) to user:password. The
reported span is the password, or the base64 value.
Skipped: an empty or very short password, a password equal to the user name, stock defaults
(password, pass, admin, changeme, …), template placeholders (<token>,
shell-variable references, {{ ... }}, xxxx, REDACTED), and a Basic value with no colon. When a curl
command also matches gitleaks’ curl-auth-header rule on the same Basic value, you get one
secret.provider_token finding for it, not two.
Why it matters#
The credentials work wherever the URL or header is accepted, and they travel in logs, browser history and referrers in plain sight. Unlike a named provider token, what they unlock is unknown: sometimes a throwaway staging box, sometimes a package registry.
What to do#
Medium severity. Rotate the password if the host is real, and move the credential out of
the URL into a header or credential helper (git credential, a .netrc, a secret store).
Example#
curl -s -X POST https://api.stormdoor.dev/v1/secrets \
-H "Authorization: Bearer sk_live_..." \
-H "content-type: application/json" \
-d '{"text":"git clone https://deploy:Xk9sLm2Qw7Vb@git.example.org/team/repo.git"}'The response carries one secret.url_credentials finding.