Skip to main content

​
Email addresses

Addresses are extracted from the rendered page: the visible text, mailto: links, and inline script data. They are lower-cased and de-duplicated. The user:password@host part of a URL, as in a database connection string, is not an address and is left to the credential scan. Every plan sees the full list on an app page and in the API, and the email: filter is available to everyone. An address on a page is not proof of anything beyond its presence there. Contact addresses, marketing footers, and example data all appear.

​
Credentials

After the page is rendered, its source is scanned for strings that match the shape of an API key, token, or secret: cloud provider keys, payment and messaging service tokens, database URIs, and hundreds of other formats. Each match is a finding with the name of the detector that matched it. A finding is verified when the scanner was able to confirm it with its issuer at snapshot time, for example by making an authenticated call that succeeded. Unverified findings are kept too; they may be revoked, malformed, or placeholders, and the format alone is no guarantee. Verification happened at snapshot time. A verified credential may have been revoked since; an unverified one may never have been valid. The list of findings never shows a credential in full. On Plus each finding comes masked: up to the first 8 and last 4 characters around a fixed-width mask, such as sk_live_••••••••0000. That is enough to match it against the keys in the issuer’s dashboard, which list keys the same way. Shorter secrets show fewer characters. The page source the scan ran over is never shown, in the console or the API. The extracted text and the screenshot show what the page displayed when it was captured, so a secret the page printed on screen appears in them as shown. Treat them as sensitive.

​
What each plan sees

On the Free plan an app page shows the detector names with a lock in place of the masked values. The API, available on Plus, includes the credentials array once the page has been scanned for credentials, empty when nothing was found.

​
Using what you find

A credential surfaced by Periphery may be used only to notify its owner. Using it to access, change, or disrupt a system you are not authorised to test breaches the acceptable use policy and, in most places, the law. If you are the owner, treat a verified finding as evidence that the credential worked at snapshot time, not as a reason to test it again. Revoke or rotate it first, update the systems that depend on it, and then remove the secret from the public page or build output. Taking the page down does not revoke the key. For a step-by-step response, see Respond to findings.