Skip to main content
Sensitive fields are values that should not be stored, indexed, or exposed in telemetry. Foveus applies redaction and backend safety controls, but your team should still decide which fields are safe to capture for your services.
Do not intentionally send secrets, credentials, card data, authentication tokens, or highly sensitive personal data to Foveus.

Common sensitive fields

The Foveus SDK redacts these JSON field names by default, in captured request and response bodies:
It also redacts these headers by default: Authorization, Cookie, Set-Cookie, X-API-Key, X-Auth-Token and Authentication. Field names match exactly, ignoring case. password is redacted; userPassword, customerEmail or homeAddress are not, unless you add them. A redacted string, number, boolean or null value is replaced with "***". An object or array under a redacted key is not masked.

What is not redacted

  • Log messages and structured log properties.
  • Exception messages.
  • Objects and arrays under a redacted key. Add the sensitive keys inside them to RedactedFields.
  • Keys that only contain a redacted name, such as userPassword.
  • Query strings with SDK versions before 1.1.0-beta.18. From that version, a query-string parameter whose name is a redacted field is stored as ***; other parameters are stored as sent.
Do not log secrets or sensitive personal data.

Add your own sensitive fields

Every product has domain-specific fields that may be sensitive. Add them to RedactedFields.
Redaction changes apply to newly captured telemetry.

Add sensitive headers

If your service uses custom headers for authentication, session state, internal tokens, or provider credentials, add them to RedactedHeaders.

What to avoid capturing

Avoid capturing values such as:
  • passwords
  • one-time passcodes
  • PINs
  • session tokens
  • access tokens
  • refresh tokens
  • API keys
  • authorization headers
  • cookies
  • card numbers
  • CVV or CVC values
  • private keys
  • secrets
  • full identity documents
  • highly sensitive personal data
If your service handles these values, use redaction and path exclusions.

Safer values to search by

Execution Context Search is most useful when you search by stable, non-secret identifiers. Good examples:
These values can help you find executions without exposing secrets. For example:
or:

Redacted fields are not searchable

If a field is redacted, Foveus does not index the original value for search. For example:
If your response contains:
The SDK stores *** instead of the original value. Do not expect this search to work:
Use a safer identifier instead:

Sensitive routes

Some routes are more likely to contain sensitive data. Examples:
Use path exclusions when needed.
You can also exclude exact paths.

Response context

Response context is useful when you need to see what your service or a provider returned. For example:
This can be safe and useful to search:
But response bodies can also include sensitive values. Before enabling response capture broadly, review the fields your APIs return and add redaction rules.

Request context

Request context helps you understand what a client sent. For example:
This can be useful for investigation. But request bodies can also include credentials, account details, or personal data. For sensitive routes, use path exclusions or disable body capture.

Searchable context safety

Foveus applies backend safety controls before indexing context. The backend refuses to index or search keys that are, or contain, any of these words: password, passcode, pin, otp, token, authorization, cookie, secret, apikey, api_key, card, pan, cvv, cvc, bvn, nin. It also refuses values that look like tokens. Because this matches words inside keys, it can also block harmless keys such as company (contains pan). These controls can include:
  • sensitive-key denylist
  • redaction
  • scalar-only indexing
  • bounded value length
  • bounded key length
  • maximum traversal depth
  • maximum indexed properties per execution
  • workspace and service policies
Sensitive fields should not become searchable context. Before sending live telemetry:
  1. Review request and response fields for sensitive data.
  2. Add domain-specific fields to RedactedFields.
  3. Add custom sensitive headers to RedactedHeaders.
  4. Exclude sensitive routes.
  5. Enable response capture only where useful and safe. It is off by default.
  6. Check that log and exception messages do not contain secrets; they are not redacted.
  7. Use sampling for high-volume services.
  8. Trigger test requests in Test mode.
  9. Open executions and confirm redaction works, including fields nested inside objects.
  10. Search by safe identifiers, not secrets.

Example production setup

Troubleshooting

A sensitive field appears in Foveus

Add the exact field name to RedactedFields. If the value is an object or array, add the sensitive keys inside it. If the value appears in a log or exception message, remove it from the message; those are not redacted.
Then trigger a new request. Redaction applies to newly captured telemetry.

A sensitive header appears in Foveus

Add the header to RedactedHeaders.

Context search finds a field it should not

Add the field to redaction or policy controls, then trigger new telemetry. Telemetry captured before the change keeps its old values until it expires. Execution telemetry, including searchable context properties, expires after 2 days.

Context search cannot find a field

Check whether the field was redacted, denied by policy, excluded by route, skipped by sampling, or outside retention.

What to do next