AI endpoints are reachable from your client code

Why it matters

Your client-side JavaScript references first-party AI/LLM API routes, which means anyone who reads the bundle knows they exist and can send requests to them. This scan did NOT call these endpoints — doing so would spend your model budget — so it cannot tell whether they require authentication or enforce rate limiting, and this is not a finding that something is wrong. Treat it as a checklist: an AI endpoint reachable without a login is a public, billable API, and one without per-user rate limiting lets a single abuser run up your provider bill (a cost-based denial of service). Confirm each of these requires authentication before any model call and has a per-user rate limit and spend cap.

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.7.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.

ShipReady found first-party AI/LLM API routes referenced in your client-side JavaScript (one or more first-party AI API routes) but did not call them — that would spend your model budget — so this is a checklist, not a confirmed problem. For each endpoint: require authentication and reject unauthenticated requests before any model call runs; add per-user rate limiting and a spend cap so one abuser cannot run up your provider bill (a cost-based denial of service); and validate and bound the input size. Treat any AI endpoint reachable without a login as a public, billable API.

Frequently asked questions

What does "AI endpoints are reachable from your client code" mean?

Your client-side JavaScript references first-party AI/LLM API routes, which means anyone who reads the bundle knows they exist and can send requests to them.

How serious is it?

ShipReady rates this info. Informational. No action strictly required.

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. The free report lists every issue it finds and shows full evidence and a fix prompt for the critical and high-severity ones; medium and low findings are counted and unlock on Pro.

Related checks

• Secret published through a browser-exposed environment variablecritical
• AI provider client is configured to run in the browserhigh
• AI system prompt is hardcoded in the browser bundlemedium
• AI widget missing SRIlow
• Exposed AI tooling config that can contain credentialshigh
• MCP server is reachable without authenticationhigh