`getApplicationVariable()` returns encrypted values in front components

[remihuigen]

Description

getApplicationVariable() returns the at-rest encrypted envelope (enc:v2:...) instead of the plaintext value when called from an application front component.

This affects every application variable declared with isSecret: false. These variables are explicitly intended to be exposed to front components, so this makes the feature unusable for browser-safe configuration such as public Mapbox access tokens.

Reproduction

Define a non-secret application variable:

MAPBOX_PUBLIC_ACCESS_TOKEN: {
  universalIdentifier: getIdentifier(
    'applicationVariables',
    'mapboxPublicAccessToken',
  ),
  description: 'Client-side Mapbox access token used to render Mapbox Maps.',
  type: FieldType.TEXT,
  isSecret: false,
},

Set its value in the application settings, then use it from a front component:

import { getApplicationVariable } from 'twenty-sdk/front-component'

const token = getApplicationVariable('MAPBOX_PUBLIC_ACCESS_TOKEN')

console.log(token)

Actual behavior

token is an encrypted envelope, e.g.:

enc:v2:...

Expected behavior

token should be the plaintext configured value, e.g.:

pk.eyJ...

Secret variables must continue to be omitted entirely from front-component context.

Root cause

The front-component resolver correctly filters out variables where isSecret === true, but it forwards the encrypted database/cache value without decrypting it:

[strip-secret-from-application-variables.ts](https://github.com/twentyhq/twenty/blob/dea1f899045b6e6690724f999eb879faae977248/packages/twenty-server/src/engine/metadata-modules/front-component/utils/strip-secret-from-application-variables.ts)

acc[flatApplicationVariable.key] = String(
  flatApplicationVariable.value ?? '',
);

flatApplicationVariable.value is the persisted encrypted value. The resolver needs to decrypt non-secret application variables before serializing them into the front-component environment.

Regression

This behavior shipped with the front-component application-variable feature in twenty/v2.10.0 and remains present in v2.25.0. Strictly speaking, it is not a regression from an earlier working version of this API—the feature itself was introduced already broken.

Technical inputs

Twenty version: v2.25.0
Introduced in: twenty/v2.10.0
Introducing commit: [dea1f899045b6e6690724f999eb879faae977248](https://github.com/twentyhq/twenty/commit/dea1f899045b6e6690724f999eb879faae977248) — Inject none secret env variables into front components (#20511)

[sonarly]

🟠 Sonarly Analysis — High Severity

Encrypted application variables reach front components

Front components receive the persisted encrypted envelope instead of the plaintext value for exposed application variables, making browser-safe configuration unusable.

Root Cause

The proximate cause is that FrontComponentResolver.frontComponent() obtains application variables from WorkspaceCacheService and passes them to stripSecretFromApplicationVariables(). That helper removes isSecret entries but serializes every remaining value directly:

if (flatApplicationVariable.isSecret) {
  return acc;
}

acc[flatApplicationVariable.key] = String(
  flatApplicationVariable.value ?? '',
);

There is no SecretEncryptionService.decryptVersioned() call for a non-secret row. Therefore, when the cache contains an at-rest envelope, the same envelope is returned in the GraphQL applicationVariables field and then placed in the front-component worker environment. getApplicationVariable() only parses and reads that environment value; it has no decryption layer, so it necessarily returns the envelope [ref:strip-secret-from-application-variables.ts] [ref:front-component.resolver.ts] [ref:getApplicationVariable.ts].

The triggering cause was the introduction of the front-component application-variable exposure path in commit dea1f899045b6e6690724f999eb879faae977248. That commit added the resolver lookup, the secret-filtering helper, and tests that covered plaintext non-secret values and secret omission, but did not cover an encrypted value with isSecret: false [ref:dea1f899045b6e6690724f999eb879faae977248]. The failure occurs whenever a front component is opened for an application whose exposed variable value is stored or cached as an encrypted envelope; it is deterministic for that request path, not a traffic spike or transient dependency failure.

The cache conversion is also a pass-through: it copies applicationVariableEntity.value into the flat variable without decryption [ref:workspace-application-variable-map-cache.service.ts] [ref:from-application-variable-entity-to-flat-application-variable.util.ts]. The local branch’s ordinary application-variable update and 2.5 backfill paths encrypt only rows marked secret [ref:application-variable.service.ts] [ref:2-5-instance-command-slow-1798000005000-encrypt-application-variable.ts]. Consequently, the repository does not establish how the observed non-secret encrypted row was created; that data/deployed-version detail is missing. It does establish that any such envelope is forwarded unchanged once it reaches the front-component resolver.

Blame commit: dea1f899 by martmull — Inject none secret env variables into front components (#20511)

Suggested Fix

Updated front-component application-variable serialization to decrypt versioned encrypted envelopes before exposing non-secret variables to browser front components. Plaintext values continue to pass through unchanged, while secret variables remain excluded and are never decrypted or exposed. Injected SecretEncryptionService into the front-component module and added unit coverage for decryption, workspace scoping, and secret filtering.

---

Analyzed by Sonarly · View full analysis

[remihuigen]

@martmull you closed my proposed PR #23494 which is fine, but this issue still remains an issue: getApplicationVariable() always returns an encrypted value client side, even if isSecret is false

[martmull]

Ok my bad I read this too quickly. Reopening and reviewing this