CRED-URL Hardcoded Credentials in URLs
What this means
SiteShadow found credentials embedded directly in a URL (common examples: postgres://user:pass@host, https://user:pass@…).
Why it matters
- URLs leak easily (logs, crash reports, proxies, browser history, monitoring).
- Even if you "don't log it," third-party tooling often will.
- Rotation becomes urgent and disruptive once the URL has spread.
Safer examples
1) Use env vars + a URL without inline creds
DB_HOST=db.example.com
DB_USER=app_user
DB_PASSWORD=...import os
dsn = f"postgres://{os.environ['DB_USER']}:{os.environ['DB_PASSWORD']}@{os.environ['DB_HOST']}/app"2) Prefer a secret manager in production
Inject credentials at runtime from a secret manager rather than storing them in code or in a committed URL.
3) If it ever leaked: rotate
If the URL (with creds) was committed or shared, assume compromise and rotate immediately.
How SiteShadow detects it (high level)
- Recognizes credential-in-URL patterns (userinfo before
@). - Prioritizes common schemes like database URLs and basic-auth URLs.
References
- OWASP Secrets Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
---