Content Security Policy blocks the OpenFGA Playground in production environment

[corentin59]

When I deploy OpenFGA in a production environment and try to access the Playground, the browser throws a Content Security Policy (CSP) error, preventing the play.fga.dev Playground from being embedded in an iframe.

Refused to frame 'https://play.fga.dev/' because an ancestor violates the following Content Security Policy directive: "frame-ancestors http://localhost:*".

This issue occurs because the current CSP configuration allows only localhost to embed the Playground, which is not suitable for a production environment. As a result, the Playground can't be accessed within OpenFGA deployed in production.

Steps to reproduce

1. Deploy OpenFGA using Helm in a production environment.
2. Attempt to access the Playground in the browser.
3. Observe the CSP error in the console.
4. Expected behavior : The Playground should be accessible in a production environment without violating the CSP policy.

Actual behavior The browser refuses to load the Playground due to a restrictive CSP configuration that only allows embedding from localhost.

Solution Proposal To fix this issue, the Content Security Policy should be updated to allow the production domain to embed the play.fga.dev Playground. In values.yaml, the following CSP configuration should be added to allow the production domain to use the Playground:

playground: csp: frame-ancestors: "https://yourdomain.com https://play.fga.dev"

This change would allow both the production domain (yourdomain.com) and https://play.fga.dev to embed the Playground within an iframe. Additional Considerations An alternative solution could be to host the Playground locally within the infrastructure, which would eliminate the need to reference https://play.fga.dev and give more control over the CSP.

[stefan505]

We have the same requirement. The helm chart already supports the playground config to be set and with the correct ingress configured, it should be accessible on any hosted domain.

[aaguiarz]

Can you expand on how you can see this working if play.fga.dev is hosted externally?

We need to have a CSP in play.fga.dev, and it can't be set to an arbitrary domain.

Running play.fga.dev locally is something we want to do, but we need to open source the Playground and in the current state it would require a rewrite. We'll do that eventually, but not in the short term.

What are the use cases you want to enable by using the playground for production?

Most OpenFGA users end up interacting with production stores using the CLI, which is more secure and has better capabilities.

[corentin59]

The problem is that there may be other types of users besides developers, and when I mention production, I’m also referring to intermediate environments (e.g., integration, staging, etc.). There can also be shared development environments where having dev environments installed locally isn’t necessary, as they can instead be hosted on a remote development server—similar to what can be done with phpMyAdmin or the Kubernetes dashboard. It seems odd to question whether a GUI has a place in production due to security concerns or the potential for hacking, as it also opens up additional possibilities. However, we could also host the GUI on a separate route and secure it to allow less technical users to verify assertions.

It is true that the playground feels more like a sandbox and doesn’t seem to be a sufficiently mature management tool, but it’s the best option we have for now. I understand that you have security constraints and that you host the tool on your servers, and the ideal solution would indeed be to make it open-source to enable the integration of the GUI. Therefore, there is currently no solution in this state.

[aaguiarz]

No, there's no solution for providing a UI for OpenFGA instances hosted in a domain different than localhost, and we don't have a target date for whenever we'll have one.

They playground's goal is to let developers learn how to better use OpenFGA and we don't have plans to convert it into a management tool (e.g. implement authentication, implement authorization to decide who can do what).

[rhamzeh]

@corentin59 will close this issue to move the discussion to the original ticket here

As @aaguiarz mentioned, for various security reasons, we go to great lengths to ensure Playground cannot be enabled in prod.

Some folks, like here have worked around it.

From our perspective, this is risky for you - only do this if you are sure this is not being used for production.

The way to manage this that we recommend is through our VS Code/IntelliJ extensions coupled with the FGA CLI

That flow grants you the ability to managing the store, including in ways not possible in the Playground with support for modular models and a more powerful testing framework

In the future - once we get the chance to fully re-architect the Playground as an OSS offering, we may revisit this.