Security: API keys exposed to client-side — risk when deploying publicly over internet

Summary

Perplexica (Vane) exposes AI provider API keys client-side (in the browser), creating an inherent security risk when deploying the application over the public internet.

Problem

When configuring Vane through the browser-based setup wizard, users enter their AI provider API keys (OpenAI, Anthropic, Ollama, Groq, LM Studio, etc.). These keys are then:

1. Stored/transmitted in a way that is accessible to the client-side JavaScript — meaning any visitor to a publicly deployed instance can inspect network requests, browser localStorage, or bundle source code to extract valid API keys.

2. Used to make direct API calls from the browser to AI provider endpoints. Since the keys must be sent with each request, they are inherently exposed to anyone who can intercept or inspect browser traffic.

This means that anyone who deploys Vane publicly over the internet is effectively donating their API keys to the world, enabling:

• API key theft and abuse — attackers can use stolen keys to run their own AI queries at the owner's expense
• Financial damage — especially with providers like OpenAI/Anthropic where costs scale with usage
• Rate limiting / account bans — abuse of stolen keys can lead to account suspension

Root Cause

This is an architectural design issue: the current architecture appears to use the user's browser as the proxy for AI API calls, rather than routing all AI requests through a secure backend/server-side proxy that keeps credentials secret.

Suggested Mitigations

1. Server-side API proxy — Route all AI provider API calls through the backend (Next.js API routes or a dedicated proxy). The frontend should never see or handle raw API keys.

   • Keys stored only server-side (environment variables / encrypted database)
   • Frontend sends search queries to Vane's own backend; backend forwards to AI provider with secret key

2. Authentication + authorization layer — If public access is desired, require users to bring their own API keys (with per-session scoping) or implement an auth system so only trusted users can leverage hosted keys.

3. Clear security warning — At minimum, display a prominent warning during setup when selecting a deployment mode that will expose keys publicly.

Environment

• Version: Latest (itzcrazykns/vane:latest)
• Deployment: Docker (single-container with bundled SearxNG)
• Architecture: Next.js 16 standalone + SearxNG
• Setup method: Browser-based wizard

Severity

High — This affects every user who deploys Vane publicly and configures it with paid AI provider API keys. The impact includes financial loss, credential compromise, and potential account suspension.