Credential-bearing database connection URI pattern appears in public content
ShipReady found a supported credential-bearing database connection URI pattern in scanned page or script content.
Why it matters
Database connection material belongs in trusted server configuration. A public credential-bearing URI pattern deserves investigation even though the scanner does not connect to the database.
How ShipReady detects it
What it inspects
ShipReady scans fetched page HTML and linked JavaScript text available to the scan, with shared script fetching and analysis.
What triggers a finding
The rule matches supported postgres, postgresql, mysql, mongodb, mongodb+srv, redis, or amqp URI syntax containing non-empty user, password, and host components. Local-only host forms and placeholder passwords are suppressed.
What the evidence shows
Public content contained a supported credential-bearing database URI pattern. Evidence retains only the scheme and host while redacting the user and password.
Limits of this check
ShipReady does not resolve or contact the host, test the URI, validate credentials, inspect database permissions, or establish network reachability, data access, or compromise. It only scans the page and scripts it could fetch during this bounded scan.
How to fix it
Trace the public value to its build source
Locate the URI in source and deployment inputs, then remove unintended server connection material from browser-visible output.
Review confirmed credentials through the database owner
If the value is confirmed as a real connection credential, use the database owner's controls to assess and replace it.
How to verify the change
Inspect deployed client assets
Search representative deployed HTML and JavaScript for the pattern after release.
Expected: Public artifacts no longer contain unintended credential-bearing database URI patterns.