Keep secrets and personal data out of development logs

A useful error message should explain what failed without becoming a container for everything the application knew at that moment. Dumping a request object, environment or account record into a log can expose both credentials and personal data.

These exposures need different responses. A secret may grant access and require revocation or rotation. Personal data requires assessment of the people, copies and processing involved. A single “sensitive content” warning is not a complete operating procedure for either.

Design the error record before the failure

A hypothetical integration developer is investigating why a CRM update fails. The quickest debugging change appears to be logging the complete request and response.

A better diagnostic record might include the operation name, a restricted correlation reference, the provider’s error category and the connector version. If a particular field causes the failure, record a safe validation result instead of copying the field’s value.

This is a design exercise: identify the decisions the developer must make, then provide the minimum evidence needed for them. Do not assume that more raw content always makes diagnosis faster.

OWASP’s logging guidance discusses information that should be excluded or handled carefully in logs, including credentials and sensitive personal data. Apply that guidance to development and test systems as well as production.

Treat secret scanning as one detection layer

GitHub’s secret-scanning documentation describes detection of supported secret patterns and the need to address exposed credentials. Push protection can block detected secrets in supported circumstances, subject to the repository and feature configuration.

Neither capability establishes that every possible credential is detected. A proprietary token, a transformed value or content outside the scanned surface may fall outside coverage.

Secret scanning is also not a comprehensive personal-data detector. A customer complaint or private address may contain no credential pattern. Keep separate policies and checks for the information the development workflow can handle.

Use approved synthetic fixtures and provider-documented test credentials where available. A test that requires an active production secret in a log has created the problem it is meant to prevent.

Respond to a credential exposure at its source

If a credential has been exposed, removing it from the latest file or deleting one log entry does not revoke the capability it grants. Follow the provider’s process to revoke or rotate it, then assess where it was available and what access it permitted.

Coordinate that response with the responsible owner. A replacement credential should reach the intended service through the approved secret-management path, not through another copied chat or issue description.

Repository history, build artefacts, log exports and support bundles may retain earlier copies. Address those copies under the incident process, while recognising that cleanup and revocation answer different questions.

GitHub’s documentation supports prioritising the exposed credential’s security. It does not justify a claim that a clean scan proves no access occurred.

Keep personal-data review distinct

For personal data in logs, determine what fields were captured, which people may be affected, who could access the logs and where exports went. Stop unnecessary collection and preserve only the evidence required for the authorised investigation.

Do not paste the exposed content into a general issue tracker to explain the problem. A restricted reference and a description of the data categories may be sufficient.

OpenTelemetry’s sensitive-data guidance recommends avoiding unnecessary collection and using appropriate processing controls. Removing a field before emission is preferable when feasible because later filtering cannot undo earlier collection or export.

Error-path tests should therefore inspect the final diagnostic destinations, not only the application’s normal response.

Make safe debugging convenient

Provide developers with approved diagnostic fields, synthetic examples and a short process for requesting exceptional access. If the standard tools make every problem opaque, teams will be tempted to add uncontrolled payload logging.

Before a change is accepted, check:

• No diagnostic statement dumps complete credentials, environments or customer objects.
• Normal and exception paths use the same content policy.
• Scanning coverage and known gaps are documented.
• Credential exposure triggers revocation or rotation assessment.
• Personal-data exposure follows its own authorised investigation.
• Temporary debug settings have an owner and removal condition.

The aim is a debugging workflow that supplies useful evidence by default. Detection tools remain valuable, but the strongest routine improvement is to stop unnecessary sensitive content from entering the diagnostic path.