Configuration mismatch in karate-config.js during environment-based credential switching

Question

When utilizing karate-config.js to separate production credentials from mock data for integration testing, the framework relies on the -env system property to load specific profiles. The goal is to ensure that tests targeting a local mock server (Karate Netty) never inadvertently trigger requests to production endpoints due to configuration leaks.

There is uncertainty regarding the priority of variable assignment when a variable is defined both in the global configuration and overridden within a specific feature file during a mock-based test run. If the baseUrl is dynamically reassigned to a local port, the interaction between the JavaScript-based config engine and the feature-level variable scope must be strictly defined to prevent credential exposure.

How does Karate handle the precedence of variables defined in karate-config.js when they are redefined within a feature file during a mock server execution?
  Is there a mechanism to enforce a strict "non-production" state that prevents the execution of any request if production credentials are detected while the environment is set to dev?

Tasadduq Burney · Answer

Direct answer
A feature-level * def baseUrl = 'http://localhost:8080' shadows the value returned by karate-config.js for that scenario only. It does not mutate the config object, and other scenarios continue to see the configured value unless they also redefine it. Karate has no built-in runtime interceptor that automatically cancels every request when production credentials are detected while karate.env is dev. You must enforce the boundary explicitly.
Confirmed facts vs. likely explanation

ItemStatusDetail

Config bootstrapConfirmedKarate loads karate-config.js once, reads karate.env, and exposes returned keys as scenario variables.
Feature redefinitionConfirmed* def in a feature shadows the same-named config variable in that scope; it is silent shadowing, not mutation.
Automatic prod blockConfirmed absenceNo built-in mechanism blocks requests solely because production credentials exist in a dev run.
Credential leak causeLikelyA dev feature file redefines baseUrl or headers to a production value, or the dev branch still returns production secrets.

Steps for this case

In karate-config.js, keep the dev branch free of production usernames, passwords, and tokens. Return only the local mock baseUrl and mock headers.
Add a fail-fast check in the dev branch that throws when baseUrl, host, or credential markers match production:

if (env === 'dev') {
  if (/production-host|prod-token/.test(baseUrl + JSON.stringify(config))) {
    throw new Error('Production marker detected in dev config');
  }
  config.baseUrl = 'http://localhost:' + mockPort;
}

Add a Background block to mock-based feature files so every scenario asserts the non-production state before any request:

Background:
* def env = karate.env
* match env == 'dev'
* match baseUrl startsWith 'http://localhost:'
* def headers = { 'Content-Type': 'application/json' }
* if (headers.Authorization != null && headers.Authorization.match(/prod/)) karate.abort()

Do not print or log karate-config.js values; test reports can capture secrets.

Verification

Run with karate.env set to dev, print karate.env and baseUrl, then redefine baseUrl in a feature and print again to confirm scenario-local shadowing.
Temporarily point the dev baseUrl at a production host and run; the suite should fail during config load before any HTTP request.
Inspect the dev branch to confirm production credentials are absent and headers are set conditionally.

Missing diagnostic
Which Karate version and runner are you using, and how is karate.env supplied? CLI env-flag spelling and scope behavior vary across releases, and that detail determines the exact command to verify.
Assumption: behavior described targets Karate 1.x-style configuration; older releases may differ. Treat version-specific flags as unverified until you confirm the installed release.

Configuration mismatch in karate-config.js during environment-based credential switching

1 answer

Direct answer

Confirmed facts vs. likely explanation

Steps for this case

Verification

Missing diagnostic

Your perspective belongs here.

0 question comments

Item	Status	Detail
Config bootstrap	Confirmed	Karate loads `karate-config.js` once, reads `karate.env`, and exposes returned keys as scenario variables.
Feature redefinition	Confirmed	`* def` in a feature shadows the same-named config variable in that scope; it is silent shadowing, not mutation.
Automatic prod block	Confirmed absence	No built-in mechanism blocks requests solely because production credentials exist in a dev run.
Credential leak cause	Likely	A dev feature file redefines `baseUrl` or headers to a production value, or the dev branch still returns production secrets.