What your frontend bundle gives away

Everything your app ships to the browser is readable by anyone who opens it. Minification is not concealment: a bundle is a text file served to the public, and searching it takes seconds.

Not every key in a bundle is a problem

This is the distinction that matters most, and the one most checklists get wrong. Some keys are designed to be public. A Supabase anon key, a Stripe publishable key, a Firebase web config: these are meant to ship, and finding one in a bundle is not by itself a finding.

What makes them safe is what stands behind them. An anon key is safe because row-level security decides what it can read. Turn that off and the same key is a public read of your database. The key was never the control. The policy was.

The keys that are always a problem

A service key is the opposite kind of object. It is designed to bypass policy, which is exactly why it must never reach a browser. A service_role key in a client bundle is not a misconfiguration to schedule, it is a live credential published to everyone who loads the page.

Things that are served without anybody deciding to serve them

Most exposure is not a decision. It is a default nobody turned off, or a file that ended up inside the directory the web server publishes.

Assessing a hole is not the same as opening one

A reading of a site should never change it. Leakpeek is GET only, through one request primitive, with no code path that writes. Where a finding could only be proven by writing, it is reported as unverified rather than proven.

Evidence is redacted where it is produced, too. A readable table is reported as a row count and column names, never values, and a key is masked. A report gets read on sites the reader does not own, and a report that quotes the secret back has become the leak.

Read a site with Readout