Redaction bypass: GitHub App secrets are still exposed in MCP responses

[KOSFin]

The security issue from #26 is not fully fixed.

The documented redaction is disabled by default (DOKPLOY_REDACT_ENV=false). More importantly, the default field list does not cover the actual GitHub App response keys.

The redactor matches field names exactly, but Dokploy responses use:

• githubPrivateKey
• githubClientSecret
• githubWebhookSecret

The default list only contains names such as privateKey, clientSecret, and secret. Therefore these GitHub App secrets remain exposed unless every MCP deployment manually adds the exact field names to DOKPLOY_REDACT_FIELDS.

I reproduced this in normal MCP responses from compose-one and compose-delete.

Please make redaction enabled by default and add exact GitHub App field names to the built-in denylist. Ideally, these fields should be omitted server-side rather than returned to MCP clients at all.

Related: #26

[umudhasanli]

The exact-field additions are necessary, but a second content-aware boundary would prevent the next camelCase field name from creating the same bypass:

import { redact } from 'flare-redact';

const safeResult = redact(toolResult, {
  redactKeys: /^(?:githubPrivateKey|githubClientSecret|githubWebhookSecret)$/i,
  enable: ['high_entropy'],
});

This recursively checks values as well as keys, so a PEM private key or provider-shaped token is still removed when it is nested under an unexpected field name. The explicit redactKeys rule handles short secrets that cannot be classified from content alone.

I agree with the issue's preferred fix: omit these fields before constructing the MCP response. Redaction should be defense in depth, enabled by default, with a regression test asserting that all three canaries are absent from the fully serialized tool result.

Disclosure: I maintain Flare Redact: https://github.com/flare-collection/flare-redact

[Siumauricio]

Fully resolved on the MCP side by two merged PRs:

• fix: redact provider-prefixed secret fields in API responses #66 — field matching is now suffix-based, so provider-prefixed keys are covered: verified empirically that githubPrivateKey, githubClientSecret, and githubWebhookSecret all come back [REDACTED] with the default field list (regression tests included).
• feat!: enable secret redaction in API responses by default #69 — DOKPLOY_REDACT_ENV now defaults to true, so a default installation redacts secret-bearing fields without any configuration. Opt out with DOKPLOY_REDACT_ENV=false only if you explicitly need raw values.

Your third suggestion — omitting these secrets server-side so no API consumer ever receives them — is the right long-term defense and is now tracked in Dokploy/dokploy#5002.

Thanks for the thorough report, @KOSFin!