Your HCL Foundry integration needs an appkey, appsecret, and service URL — three values that can cause serious harm, if exposed. Here’s how to handle them securely.
Applicability
This guide applies specifically to web applications that integrate with HCL Foundry using non-Iris SDKs— such as the HCL Volt MX JavaScript SDK.
The patterns described here are not intended for Volt MX Iris-based builds, which have its own build-time credential management via Iris project settings.
The Problem at a Glance
When initialising Volt MX Foundry client using the JavaScript SDK, developers often start with something like this:
var appkey = "<your-app-key>";
var appsecret = "<your-app-secret>";
var serviceURL = "<your-service-url>";
// Initialise Volt MX SDK and connect to Foundry
var client = new voltmx.sdk();
client.init(appkey, appsecret, serviceURL,
function(res) { /* success */ },
function(err) { /* failure */ }
);
Never hardcode credentials in production
Embedding
appkeyandappsecretdirectly in JavaScript source means they can be extracted via browser DevTools, source inspection, or inadvertent version control commits. Even minified or bundled JavaScript is not a safe hiding place.
Your Options
Option 1: Environment Variables at Build Time
Inject the key and secret values at build time via environment variable files. Rather than hardcoding credentials in source, you define them in a .env file (excluded from version control) or in your CI/CD pipeline’s secret store. The build tool embeds them into the compiled output at deploy time.
This is a widely-adopted baseline and meaningfully better than hardcoding — but be aware that values embedded at build time end up in your JavaScript bundle and are visible to anyone who downloads and inspects it. It is therefore more suited to internal applications or lower-risk scenarios.
//Sample for React
# .env (git-ignored)
REACT_APP_FOUNDRY_APP_KEY=your-app-key
REACT_APP_FOUNDRY_APP_SECRET=your-app-secret
REACT_APP_FOUNDRY_SERVICE_URL=https://your-foundry-url
// In your React component or service
var client = new voltmx.sdk();
client.init(
process.env.REACT_APP_FOUNDRY_APP_KEY,
process.env.REACT_APP_FOUNDRY_APP_SECRET,
process.env.REACT_APP_FOUNDRY_SERVICE_URL,
onSuccess, onFailure
);
Always add .env to .gitignore. Supply real values through your CI/CD secret store (GitHub Actions Secrets, Azure DevOps Variable Groups, etc.) and inject them during the build step.
Pros
No secrets in source code or version control
Works with all major JS frameworks
Simple to adopt with existing CI/CD pipelines
Cons
Credentials are embedded in the browser bundle
Not suitable for public-facing or high-sensitivity apps
Option 2: Fetch Credentials at Runtime from a Protected Endpoint
Rather than baking credentials into the bundle at build time, your web app fetches them at runtime from a backend endpoint — just before calling client.init(). The backend serves the credentials only to authenticated or appropriately authorised requests, and the values are never present in the shipped JavaScript bundle.
This does not prevent credentials from reaching the browser, but it offers meaningful advantages over build-time embedding: credentials can be rotated without a redeploy, access to the config endpoint can be gated by session or IP, and the values are not statically extractable from your bundle.
Pros
Credentials not embedded in the JS bundle
Rotate keys without a rebuild or redeploy
Config endpoint can be session-gated or IP-restricted
Cons
Credentials still reach the browser at runtime — inspect via DevTools
Config endpoint must be secured carefully
Requires a backend service to host the endpoint
Option 3: Volt Foundry Identity Service — Eliminate Anonymous Calls
Options 1 and 2 address how credentials are delivered to the browser. This option addresses a different, complementary question: what can an attacker actually do if they obtain the appkey and appsecret?
HCL Volt Foundry’s built-in Identity Service allows you to require users to authenticate before they can invoke any Integration or Object Service — replacing unauthenticated (anonymous) calls with identity-verified ones.
With this approach, your web app directs users to authenticate through a configured identity provider (Foundry’s User Store, OAuth 2.0, SAML, Active Directory, or a custom provider). Foundry issues a user-scoped token upon successful login. All subsequent API calls carry this token — not a shared app credential. The appkey and appsecret are still needed to initialise the SDK, but they are only used to establish the session context, not to authorise service calls.
In Foundry Console:
Apps → Your App → Identity → Add Identity Service
Choose provider: User Store / OAuth 2.0 / SAML / AD etc.
Link Identity Service to your Integration Services
Set Security Level: "Authenticated App User" (not Anonymous)
Pros
Server-enforced — users must authenticate before calling APIs
Per-user audit trail via Foundry’s access reports
Eliminates the risk of shared credential misuse
Cons
Requires an identity provider and Foundry Identity Service config
Not suitable if your app genuinely needs anonymous/guest access (e.g. ATM / Branch Location)
Which option should I choose?
These options are best used in combination rather than in isolation. Use Option 2 (runtime fetch) to keep credentials out of your bundle and enable key rotation without redeployment. Layer on Option 3 (Identity Service) to ensure that even if credentials are extracted from the browser, they cannot be used to call your APIs without a valid user login.
Option 1 (build-time env vars) is a reasonable starting point for internal tools or development environments, but should be treated as a stepping stone rather than a production solution for any public-facing application.
Additional Best Practices
Rotate regularly
Ensure regular key rotation through HCL Foundry’s admin console.
API Throttling
Set up API Throttling in Foundry during development which can also be overridden with a runtime config per environment.
