Enhancing Security and Efficiency with Separate Server and Client Evaluation Keys in Feature Management

Introduction

In FeatBit, as same as many other feature management tool provider, we separate the evaluation key for server and client. This is a common practice in the industry. But why? What's the benefit of doing so? In this article, we will discuss the reasons behind this practice.

Security

Server-side keys are typically more powerful and allow access to more features and data within the feature flagging system. Keeping these keys on the server side prevents exposure to the public, reducing the risk of unauthorized access or manipulation of feature flags, which could lead to data breaches or unwanted feature exposures.

Client-side keys, on the other hand, are designed to be used within client applications (e.g., web, desktop or mobile apps). These keys have limited permissions, ensuring that only the flags intended to be exposed to end-users are accessible. Client applications are often exposed to the public, including their feature flag evaluation keys. Using the same key for both server and client sides makes it easy for someone to obtain the key and gain unauthorized access to your server. By using different keys for the server and client, even if someone obtains the client key, they won't be able to access server-side features or data.

Permission Control

Separating keys enables more granular control over who has access to what features and data. It allows organizations to manage feature rollouts and testing scenarios differently across server and client contexts.

In some teams, client-side developers and backend developers are separate entities. If the same key is used for both client and server-side operations, it necessitates sharing the key with both teams. However, using different keys allows for distributing the client key to client-side developers and the server key to backend developers. This approach enhances security and simplifies management. Furthermore, it necessitates having robust permission control within your feature management service.

Troubleshooting and Debugging

When a request originates from a browser, mobile, or desktop app, the system can reject server keys, since these requests should only involve client-side operations, and vice versa. This distinction aids in minimizing confusion and enhancing the efficiency of troubleshooting efforts.

For example, if QA is running Selenium Grid against an application and the code is using a client key, the system can ignore exceptions like "Invalid message" from an administrative perspective, as the invalid data may be an intentional part of the test. However, with a server key, the system would want to reach out to the responsible development team to address the issue.

Conclusion

Separating server and client evaluation keys in feature management tools, such as FeatBit, is a crucial practice that enhances security, provides precise permission control, and facilitates efficient troubleshooting. This approach ensures a secure, manageable, and efficient feature flagging ecosystem, enabling teams to deploy user-centric applications with confidence and agility. Adopting distinct keys for different operational contexts helps mitigate risks and maximizes the potential of feature flags, streamlining deployments and development processes.