Sensitive credentials may be included in thrown errors or logs during client initialization

[Rondahey]

Overview

When initializing the CDP SDK client with invalid credentials or misconfigured environment variables, the SDK may throw errors that include request details or configuration values. In some environments, these errors can end up in logs (CI, server logs, APM), risking accidental exposure of sensitive information (API keys, secrets, or auth headers).

Problem Description

Developers often log errors during setup and debugging. If error objects or messages contain:

• raw API keys
• authorization headers
• full request payloads with secrets
  then those secrets can be persisted in logs or monitoring systems.

Even if the SDK does not intentionally log secrets, including them in thrown errors can still cause exposure through common console.error(err) patterns.

Expected Behavior

• Errors thrown by the SDK should never include secrets in message text or serialized fields.
• Any sensitive values (API keys, auth headers, secrets) must be redacted.
• Debug-level details should be opt-in and still redact secrets.

Steps to Reproduce

1. Configure the SDK with an invalid or malformed API key.
2. Run a simple initialization + request.
3. Log the thrown error object (e.g., console.error(err)).
4. Observe whether the error includes credential-like values.

## Example code
```ts
import { CdpClient } from "@coinbase/cdp-sdk";

async function run() {
  const cdp = new CdpClient({
    apiKey: "CDP_TEST_KEY_SHOULD_NOT_APPEAR_IN_LOGS",
  });

  // Trigger a request that fails auth
  await cdp.evm.getBalance({ network: "base", address: "0x0000000000000000000000000000000000000000" });
}

run().catch((err) => {
  // Common pattern in apps/CI
  console.error(err);
});

Proposed Solution

• Introduce a centralized redaction utility that masks or removes sensitive values such as:
  • API keys
  • authorization headers
  • secret environment variables
• Ensure all errors thrown by the CDP SDK pass through this redaction layer before being surfaced.
• Limit error context to safe metadata only (e.g., endpoint name, status code, request ID).
• Add safeguards so even debug or verbose modes never emit raw secrets.

Acceptance Criteria

• No secrets appear in error.message, stack traces, or serialized error objects.
• Redaction is applied consistently across all SDK modules (EVM, accounts, facilitator/API).
• Unit tests validate that secrets are redacted in common failure scenarios (401/403, invalid config).
• Existing error handling behavior remains backward-compatible, aside from redaction.

Additional Information

• This prevents accidental credential leakage into logs, CI output, and monitoring tools.
• Many consumers log errors by default; safe-by-default error surfaces are critical.
• Conservative redaction (masking anything that looks like a credential) is preferred over precision.