How to Secure Your Feature-Flag-Based Application

You can't wait for next week. You've sold your management on the importance and usefulness of feature flags for your application. Your development team is ready to deliver its first experiments with feature flags and next week is when you'll turn them on. Then you get a phone call. Your company's application security team heard what your team is up to and they are concerned. They want to make sure that introducing feature flags to your application will not make it vulnerable to attack. You're not a security expert, so you're not quite sure what to tell them. Fear no more. This post will outline the security concerns your application security team is likely to have and how you can assuage their fears. Here is your guide on how to talk to your security team about feature flags.

Keep in mind that the security team will focus on three things: confidentiality, integrity, and availability. Focus on helping the security team understand how your feature flags account for those things. Feature flag management is the first area to cover. Several questions come to mind for a security team member. First, where are the flag values updated? Second, how can you ensure the confidentiality and integrity of your feature flag values? Moving the configuration of feature flags to a configuration file instead of storing them in code is a good start. However, then you have to worry about who has access to the file and how you track changes. This leads us to centralized management. Centralized management of feature flags has great security benefits. A central repository manages environments, experiments, and users.

A security expert wants to know who can change feature flag values and when, how they can change them, and why they were changed. Centralized management of feature flags gives you the opportunity to control this access. Centralized feature flag management systems allow you to create users and give them roles that control what they can do. When the system offers two-factor authentication (2FA), then you can use a token that the developers hold in addition to their username and password so you can make sure they are who they say they are. Mention this to security folks and they will love you. CloudBees Feature Management enables you to use 2FA along with an audit trail that shows exactly who changed flags in which environments. In production, you'll want to know who changed feature flag values and experiments so your users are seeing what they should.

Your application security people may breathe a sigh of relief when you tell them that you can control and audit feature flag changes. However, another security concern comes up. How can you make sure that feature flag values are not changed by someone in transit? Let's take a look at the anatomy of a man-in-the-middle attack. A man-in-the-middle (MITM) attack happens when an attacker can place himself between two parties and make the parties think they are talking to each other. A diagram will help bring it home.

A MITM attack can be used to steal your data and to change the data on the way to one of the parties. When discussing feature flag security, changing the values in transit is of greatest concern. While changing a flag from true to false may not seem like a major risk, it could be the start of a chain reaction. Many sites are compromised via a chain of exploits

that ultimately leads to a data breach. Don't allow a vulnerable piece of code that is activated by a feature flag to become the first link in the chain.

The good news is that there are ways to protect against this. First, make sure the connection to your service is encrypted using TLS encryption. That will prevent someone from seeing what's sent between two servers. Another great tool to use is a digital signature. Digital signatures allow you to verify that a request or response actually came from the party you think it did. Signatures also verify that nothing in the data has been changed in transit. CloudBees Feature Management encrypts all data transmissions between the CloudBees Feature Management SDK and the CloudBees Feature Management servers that hold the values of your flags. CloudBees Feature Management also digitally signs all data coming from the CloudBees Feature Management system. The SDK checks this signature so you know for sure that no one intercepted the request and changed the flag's value.

You can trust feature flag code running on your server because you have control over it. However, you can't trust code that is delivered to the client, such as JavaScript. An attacker can see and change code in the browser. They can see and change your feature flags, too. General security practices are applicable when implementing feature flags in JavaScript. First, keep close track of what feature flags are in play and what they control. Keep feature flags on the client-side short-lived. Make sure they aren't controlling key functionality.

For managing features effectively across your user base, you need to able to slice and dice your users to segments, i.e: internal employees, beta customers, company A, users only in the US, etc.  When using a 3rd party service for feature toggles, you don't want to send them your end customer data (email, geolocation, or any other data) so that they can evaluate and decided which feature to present. Ideally, these decisions points would happen on the client side, without the 3rd party solution been exposed to your customer data. CloudBees Feature Management architecture is built around privacy, targeting specific end users happens on the client slide (mobile app, web app or a backend system) with locally available attributes and is never transmitted back to CloudBees Feature Management, the SDK generates a random identifier (device ID) on the device to uniquely identify an anonymous user.

The third concern of security folks is availability. If your flags are centrally managed, make sure the repository that holds them is available. Incorporate it into your disaster recovery and business continuity plans to the extent that's necessary for your business. Using hosted infrastructure, such as AWS, is a good first step in ensuring maximum uptime and a secure infrastructure. Regardless of where you store feature flags, make sure you have a good backup plan if your feature flag repository were to become unavailable for some reason. Your plan could be as simple as creating a default view. Or maybe you have default functionality that all will get if the feature flag isn't turned on or is missing. It could also be more complex, such as a backup system or file-based feature flag configuration that you fall back on. Do what makes sense for your business.

When that phone call from your application security team comes, you have two possible responses. First, you can tell them that you encrypt the data in transit. The application uses digital signatures to ensure the identity of the feature flag repository and the integrity of the flags themselves. Centrally managed feature flags allow you to know exactly who has access to the feature flags in every environment and when they last changed them. The flag repository is hosted on AWS, taking care of high availability and disaster recovery.  Your team follows good secure coding practices to protect the flags in the client code. Second, you can tell them that you use CloudBees Feature Management. Either way, you're now equipped to respond with confidence that your feature flag-enabled application is secure.