Potential security issue: accessToken and instanceURL are exposed if JSON.stringify is used

[djs959]

First of all, thank you for creating ts-force! I've used several approaches for working with the Salesforce API, and I must say that ts-force is by far the easiest and most intuitive to use. You've done an amazing job with it.

However, I wanted to bring up a potential security issue. I recently discovered that each RestObject instance retains the Salesforce access token after being used to access Salesforce. This happens if JSON.stringify is used to serialize a RestObject instead of the provided toJson method. The issue arises because the Rest instance (which contains the access token in its config) is stored in the _client property of each RestObject.

Here's an example of the structure if JSON.stringify is used.

workType: {
    attributes: {
      type: "WorkType",
      url: "/services/data/v58.0/sobjects/WorkType"
    },
    _modified: {},
    safeUpdateProxyHandler: {},
    _client: {
      apiLimit: {
        used: 12947,
        limit: 125000
      },
      config: {
        version: 58,
        accessToken: "TOKEN_REMOVED",
        instanceUrl: "https://REMOVED.my.salesforce.com"
      },
      version: "v58.0"
    },
    id: "08qREMOVED",
    name: "XXX",
    _TYPE_: "WorkType"
  }

Potential Impact

This behaviour creates a risk in scenarios where:
1. The server acts as a proxy for Salesforce API access for a public or semi-restricted web client.
2. RestObject instances are logged or serialized, potentially exposing sensitive data in console logs or over a network.

The embedded access token could allow anyone with access to the serialized data (e.g., in the browser) to directly access the Salesforce API, bypassing the intended restrictions.

Why This Might Go Unnoticed
• Users may naturally rely on JSON.stringify to serialize objects without realising it includes the _client property.
• The toJson method is not always used, especially by those new to ts-force, leading to inadvertent exposure of sensitive tokens.
• This can lead to significant security risks, especially in environments where Salesforce access is proxied or where objects are sent to public-facing clients.

Suggested Fix

A simple fix would be to make the _client property non-enumerable so it doesn’t get serialized by JSON.stringify. This can be done in the RestObject constructor as follows:

Object.defineProperty(this, '_client', {
    value: client || new Rest(), // Assign the Rest instance
    enumerable: false,          // Prevents it from being included in JSON.stringify
    writable: true,             // Allows updates to the _client property
    configurable: true          // Allows the property to be reconfigured later if necessary
});

This small change will ensure that _client remains accessible internally but will no longer appear in serialized output. It would help secure the usage of ts-force in environments where Salesforce API access is proxied or restricted.

Additional Considerations
1. Ease of Implementation: This change would not impact existing functionality, as _client is not expected to be serialized or accessed externally.
2. Improved Security by Default: By ensuring sensitive information like the access token is non-enumerable, ts-force would be safer to use out of the box without requiring additional developer knowledge or precautions.
3. Backward Compatibility: This adjustment does not introduce breaking changes, as it merely modifies the visibility of _client during serialization while maintaining all existing behaviours.

Thanks again for your excellent work on this library!

[ChuckJonas]

Ya, I've noticed this in the past but it's never really been an issue as my use case has always been in a BASS client side app or local scripting.

For use in web services, I could definitely see this accidentally exposing the token via logs (or worse)...

Working on a fix.

[ChuckJonas]

Fixed via #162 and released as version 3.5.0.