A public git-credentials path returned credential-bearing URL-shaped entries
The .git-credentials path returned non-HTML content containing one or more credential-bearing URL-shaped entries.
Why it matters
A public response containing embedded user-and-password URL syntax warrants prompt review of why the artifact is served and what the entries represent.
How ShipReady detects it
What it inspects
ShipReady sends one bounded probe to /.git-credentials on the scanned origin.
What triggers a finding
The rule requires HTTP 200, non-HTML, non-SPA-fallback content with at least one HTTP or HTTPS URL-shaped entry containing a non-empty user, password, and host.
What the evidence shows
The reported path returned a credential-bearing URL-shaped string. ShipReady records only a count, never the entry or credential values.
Limits of this check
ShipReady does not validate a credential, contact the named host, determine whether the response is a canonical Git credentials file, or establish repository access. It does not follow redirects; non-200, HTML, fallback-like, unanswered, or edge-blocked responses do not trigger the rule.
How to fix it
Stop serving the unintended artifact
Remove the public file and configure deployment output to exclude working-copy and credential artifacts.
Review entries through the owning service
Use the owner-controlled provider or repository account to determine whether the confirmed entries remain active before taking credential action.
How to verify the change
Request the reported path after deployment
Fetch /.git-credentials without credentials after deploying the fix.
Expected: The path no longer returns credential-bearing URL-shaped content.