Join us for Flagship 2024: April 16-17 – Register Now.

10 Developer Environment Security Tips

Contents

Session Timeouts

Administrators can modify session timeout settings to ensure that a session terminates when it is no longer in use. By default, sessions automatically time out after 30 minutes of inactivity, forcing users to re-authenticate for access. However, team administrators can customize this setting for their organization by specifying a timeout value. Note that all sessions will timeout after 7 days regardless of your organization’s setting, forcing users to re-authenticate.

A timeout value represents the length of time after which the system logs out inactive users. We recommend maintaining a shorter timeout period to enforce stricter security.

More on Session Timeouts here.

Environment Permissions

You can restrict the editing and/or publishing of feature flags, segments, and metrics by setting permissions at the object or environment level. For production environments, in particular, enforcing permissions and restricting editors/publishers can be very useful. Approval flows let you specify and/or enforce approval by another user for any change to the definition of a feature flag.

An environment has the following three permission settings:

  • Anyone can edit
  • Restrict who can edit
  • Require approvals for changes
More on Environment Permissions here.

Enforce SAML Strict Mode

If you enable SAML strict mode, all users must use SAML to log in to Split. Any existing Split username and password, or alternatives such as Google OAuth, will not be valid. Be sure to test your SAML configuration before forcing all users in your organization to log in using your IdP.

Note: You can enable or disable SAML strict mode at any time as long as you don’t have SCIM enabled.

More on SAML Strict Mode here.

SCIM Support

System for Cross-domain Identity Management (SCIM) is an open standard that allows admins to automate user and group provisioning. SCIM communicates user and group information between identity providers (IdPs) and service providers requiring user and group information (Split). With SCIM, IT administrators can easily govern Split users and groups within their own identity provider.

You can enable SCIM user provisioning to work with your SSO-strict enabled account. SCIM facilitates user provisioning, which allows your IdP to create, update, and deactivate members in Split. IT/IAM Managers are now able to manage existing Split users and groups via their identity management provider. As of now, we support Okta & Azure AD.

An IT/IAM Manager can:

  • Map individual group/user from IdP to existing group in Split
  • Automatically create of new groups in Split

This will enable:

  • Easy onboarding/offboarding of users
  • Risk reduction because all users/groups will be synced with your IdP
More on SCIM Support here.

Split Proxy

The Split Proxy enables you to deploy a service in your own infrastructure that behaves like Split’s servers. It is used by both server-side and client-side SDKs to synchronize the flags without connecting to Split’s actual backend directly.

This tool reduces connection latencies from the SDKs to the Split cloud and back transparently, and when a single connection is required from a private network to the outside for security reasons.

More on Split Proxy here.

Approval Flows

As an administrator, you can choose to set up approval workflows in your environment.

These approval workflows help you manage what changes users or groups are allowed to make in any given environment.

These approvals apply to feature flags and segments. Editors on an environment can submit the change for approval to another teammate using Split to ensure no mistakes were made in the release.

More on Approval Workflows here.

Workspace View Permissions

In the Workspace permissions area, optionally select the desired control access by doing the following:

  • Anyone has access: Allows anyone to have access to this particular workspace.
  • Restrict who can access: Allows you to select which users, groups, and admin API keys have access to a particular workspace.
More on Workspace View Permissions here.

Permissions and Team Management

In the Split application, you can enable permissions by environment, feature flag, segment, or metric, which limits the actions that non-editors can take.

Administrators can control who can edit and configure feature flags and segments across an environment using environment-level permissioning. You can set the change permissions for an environment to limit categories of actions to administrators, individual users, or groups. Groups make it easy to create a collection of users with shared permissions.

Audit Logs

You can monitor log data using the web console to audit every modification made to feature flags over time or to troubleshoot any issues that occur during rollout (admin changes are also logged).

You can ingest this data using third-party integrations or the outgoing webhook for analysis within other tools.

More on Audit Logs here & here. *Admin Audit Logs are only available on Split’s Enterprise plan.

Obfuscation of Traffic Keys

Flag Obfuscation

When a flag is evaluated, an impression is sent back to Split. This summarizes the outcome of the evaluation while removing the data used in targeting. It does, however, contain the flag name and rule used, which determines which treatment to serve.

If these bits of information are of concern, it is best practice to obfuscate them. This can be easily done by selecting less obvious flag or rule names. A split’s description is not contained in the impression, and can be utilized to describe the flag’s purpose in detail.

Treatment Obfuscation

Similar to flag obfuscation, treatment obfuscation involves changing the name of the treatments to be non-identifying. Just as flags have description fields that can be leveraged for clarity, so do treatments.

These description fields are never returned in the impression and are another way to anonymize data while documenting what obfuscated treatments are for.

Key Hashing

Another method to anonymize data is to hash the user_key sent to Split. When making a getTreatment call, a key representing a user is passed into the SDK. This key is sent to Split in the impression.

Customers who are concerned that this key could be used to link impression data to their users are encouraged to hash the key before passing it into the SDK using a deterministic hashing function. This adds a layer of anonymity between the key stored in the Split customer’s database and the key provided to Split.

By following these steps, you can be sure your environment is as secure as Fort Knox.

Get Split Certified

Split Arcade includes product explainer videos, clickable product tutorials, manipulatable code examples, and interactive challenges.

Switch It On With Split

Split gives product development teams the confidence to release features that matter faster. It’s the only feature management and experimentation solution that automatically attributes data-driven insight to every feature that’s released—all while enabling astoundingly easy deployment, profound risk reduction, and better visibility across teams. Split offers more than a platform: It offers partnership. By sticking with customers every step of the way, Split illuminates the path toward continuous improvement and timely innovation. Switch on a trial account, schedule a demo, or contact us for further questions.

Want to Dive Deeper?

We have a lot to explore that can help you understand feature flags. Learn more about benefits, use cases, and real world applications that you can try.

Create Impact With Everything You Build

We’re excited to accompany you on your journey as you build faster, release safer, and launch impactful products.