A public-health app stores LLM provider API keys in the frontend JavaScript bundle. What architectural fix best protects those credentials?
Select an answer to reveal the explanation.
Short Explanation
Anything shipped in the browser bundle is a souvenir for anyone with DevTools. Park provider keys behind a server-side BFF or gateway the public never downloads. Encoding or weekly rotation while still embedding keys is theater, not architecture.
Full Explanation
LLM provider API keys embedded in a public-health frontend JavaScript bundle are extractable by any resident or attacker with DevTools or cached assets, enabling budget abuse, quota exhaustion, and unauthorized API use against municipal accounts. The architectural fix is to keep provider keys exclusively on a server-side backend-for-frontend (BFF) or gateway that residents never download, with the browser calling only the city's authenticated endpoints. Secrets belong in server environment stores and secrets managers, not in static or SPA bundles.
Rotating keys weekly but keeping them embedded still leaves extractable secrets in each published bundle until rotation completes—and historical bundles may remain cached. Base64-encoding keys in the frontend fails as obscurity, not cryptography; browsers decode trivially. Publishing keys in a clinic waiting-room QR code maximizes exposure and conflates support convenience with credential distribution.
Exam caveat: "frontend-only" GenAI demos that call providers directly are unsuitable for civic public-health apps handling resident traffic. Operational check: scan public-health builds for provider key patterns, move calls behind a BFF, store keys in a secrets manager with short-lived credentials where supported, and verify the browser network tab never shows provider Authorization headers.