OpenRouter API-key pattern appears in public content
ShipReady found a non-placeholder string matching its supported OpenRouter API-key pattern in scanned page or script content.
Why it matters
If the matched string is a real credential, it should be held in server-side configuration instead of a browser-delivered asset.
How ShipReady detects it
What it inspects
ShipReady scans fetched page content and discovered script content for its supported OpenRouter sk-or-v1- pattern and applies its placeholder guard.
What triggers a finding
The rule triggers when a non-placeholder string satisfies the supported OpenRouter format.
What the evidence shows
The scanner observed a string matching its OpenRouter-specific format. The report retains a redacted prefix rather than the full value.
Limits of this check
ShipReady does not call OpenRouter, validate the value, inspect credits or provider routing, or invoke a model. The match does not prove that the value is active, usable, or tied to a particular account.
How to fix it
Find the source of the value
Trace the generated asset to its source and build configuration so an intentional example is not confused with a credential.
Keep real keys server-side
Remove confirmed credentials from browser code and provide them only to trusted server-side code through secret storage.
Review confirmed account credentials
If the value is confirmed to be real, follow the account owner's credential-review and replacement process.
How to verify the change
Check the deployed bundle
Search the deployed HTML and JavaScript after release.
Expected: No unintended OpenRouter-format string remains in public content.