AI provider client is configured to run in the browser
Your client-side JavaScript creates an AI provider client with `dangerouslyAllowBrowser` enabled.
Why it matters
Your client-side JavaScript creates an AI provider client with `dangerouslyAllowBrowser` enabled. The SDK blocks this by default for one reason: it means the API key travels to the browser, where any visitor can read it from the page source or the network tab. No baseURL pointing at your own server was found alongside it, so requests go straight to the provider and the key must be a real one. Anyone who loads the page can spend against your account until the quota or your card runs out. Treat the key as compromised and rotate it — removing the flag does not un-publish what has already been served.
How ShipReady detects it
AI-specific exposure — the product's differentiating module. Covers two distinct failure modes of AI-built applications: 1. Tooling artifacts deployed by accident. AI coding tools generate config and instruction files at the repo root; developers who push a whole repo (rather than just its build output) to static hosting serve them publicly. Some are merely instructions; others hold live API keys. 2. Secrets promoted into the client bundle via a PUBLIC env var prefix. This is the single most characteristic AI-app mistake: AI assistants correctly explain that a variable must be prefixed (NEXT_PUBLIC_, VITE_, ...) to be readable in the browser, and developers apply that prefix to a *server* secret. The bundler then inlines the real value into JavaScript that anyone can read. Both are confirmed by observation, never inferred from framework fingerprints alone.
Detection is deterministic. ShipReady reports this only when it observes the condition directly, and prefers to miss a real problem over inventing one. Rule version 1.3.0.
How to fix it
This is the prompt ShipReady puts in your report — written to be pasted straight into Cursor, Claude Code, or whichever assistant built the app.
Your frontend constructs an AI provider client with dangerouslyAllowBrowser enabled, which means the API key it uses is shipped to and readable by every visitor. Remove that option and delete the key from any client-side or NEXT_PUBLIC_/VITE_ prefixed environment variable. Move the call to a server route (a Next.js route handler, server action, or your backend) that reads the key from a server-only environment variable, and have the browser call that route instead. Then rotate the exposed key in your provider dashboard — assume it is already compromised, because anyone who loaded the page could read it.
Frequently asked questions
- What does "AI provider client is configured to run in the browser" mean?
- Your client-side JavaScript creates an AI provider client with `dangerouslyAllowBrowser` enabled.
- How serious is it?
- ShipReady rates this high. Fix before launch. A real weakness that an attacker can act on.
- How do I fix it?
- Paste the fix prompt on this page into Cursor, Claude Code or your AI editor. It is the same prompt ShipReady puts in your report.
- Can I check my own site?
- Yes — ShipReady scans up to ten pages of any public site for free and reports this alongside every other check.
Related checks
Does your site have this?
ShipReady checks this and 73 other things across up to ten pages of your site. Free, no signup.
Scan my site