Client Bundle Exposure
NullFault reviews public JavaScript bundles for signs that private API keys, tokens, internal endpoints, or risky deployment details leaked into browser code.
What NullFault Checks
- Whether public client assets contain credential-like values or obviously private tokens such as service-role or admin keys.
- Whether frontend bundles reference internal, debug, admin, storage, or API locations that look unintended for public clients.
- Whether discovered references are grounded in real public assets rather than guessed from a hidden wordlist.
Why It Matters
- Anything shipped to the browser is public. Minification does not make a private value safe.
- Internal route names and debug references can expose unfinished functionality or expand the attack surface.
- Frontend-safe keys are normal, but service-role, admin, or private backend credentials are not.
Common Causes
- Using a private key where a public or anon key was intended.
- Referencing NEXT_PUBLIC_ or VITE_ variables that hold secrets.
- Shipping debug builds or internal API URLs to production.
Check it yourself
Open your deployed site, view the loaded JavaScript in browser DevTools, and search it for words like key, secret, token, or service_role.
Mitigation
- Move private logic and privileged credentials to server-side code, route handlers, or edge functions.
- In Next.js and Vite, only expose values through NEXT_PUBLIC_ or VITE_ prefixes when they are truly safe for the browser.
- Rotate any sensitive value that was bundled, then remove it and redeploy.
- Review references to internal APIs, debug paths, and storage buckets before launch.
Reality check
Not every public key is a vulnerability. NullFault flags suspicious patterns and context, but only you can confirm whether a value is meant for browser use.