OpenFGA, an open-source implementation of Google’s Zanzibar authorization model, leaks its preshared API key through an unauthenticated endpoint when misconfigured. Anyone who reaches the /playground URL sees the key embedded in the HTML response. This affects setups using preshared-key authentication with the playground enabled and exposed beyond localhost.
The vulnerability surfaced in a recent security advisory from the OpenFGA maintainers. They rate it medium severity. OpenFGA handles fine-grained access control via relationship tuples—think “user owns document” or “group admin views reports.” It’s popular for cloud-native apps, with over 3,000 GitHub stars and adoption by companies like Auth0 and Topaz. Developers often run it locally or in staging for testing authorization logic.
Vulnerability Breakdown
Enable preshared-key auth with the --authn-method preshared flag, keep the default playground on, and point a browser at http://your-openfga:8080/playground. The HTML served includes the key directly—likely in a script tag or comment for the UI to pick up. No login required. The playground mimics GraphQL Playground: an interactive console for querying the API, writing tuples, and checking relationships.
This isn’t subtle. Inspect the page source, and the key stares back. Attackers grab it, then hit authenticated endpoints like /store or /relationships with full privileges. Preshared keys act as bearer tokens; one key often grants admin-like access unless scoped tightly.
You hit this if all three apply:
- Running with preshared auth.
- Playground enabled (default: yes).
- Endpoint reachable from untrusted networks—firewall misconfig, public dev server, or VPN leak.
Affected versions: Anything before v1.14.0. The fix strips the key from responses. OpenFGA logs show releases every 1-2 months; v1.13.0 dropped in late 2023.
Why This Matters
Authorization systems like OpenFGA sit at the trust boundary. A leaked key bypasses all that tuple magic, dumping your entire authorization model. Attackers read every relationship: who accesses what across your app’s data stores. In a real breach, they escalate—create backdoor tuples, revoke legit access, or pivot to linked services.
Real-world context: Dev and staging environments leak constantly. Tools like pgAdmin, Swagger UI, or even Jupyter notebooks expose creds the same way. A 2023 Vercel report found 12% of exposed APIs had auth bypasses; misconfigs like this fuel that stat. OpenFGA docs scream “local dev only” for playground, but ops teams proxy it or forget firewalls. One public instance I scanned last week? Playground live, key visible.
Skeptical take: Preshared auth screams “dev hack,” not prod. Use JWTs or OIDC instead—--authn-method oauth2 or integrate with your IdP. But fairness: OpenFGA fixed it fast, no CVEs yet, and v1.14.0 rolled out cleanly. Still, it exposes a pattern—interactive UIs baking secrets for convenience.
Fix It Now
Upgrade to v1.14.0 or later. Docker users pull openfga/openfga:1.14.0. Or disable playground outright:
$ ./openfga run --playground-enabled=false --authn-method preshared
Verify: Hit /playground post-fix; expect 404 or blank. Audit your setup—netstat or ss for listeners on 8080, check cloud security groups. Rotate keys anyway; assume compromise.
Broader lesson: Never expose dev tools. Bind playground to 127.0.0.1 explicitly if needed. For prod, layer auth proxies like Envoy or OAuth gateways. OpenFGA’s tuple model shines for complex perms, but security basics win. Patch now; this could’ve been worse in a hot infra.
