Backstage: Github token leaked to the frontend in error message

[martina-if]

Current Behavior

I had a bug in the backend configuration where the Github token had an extra /n character at the end. This created an error in the backend that got propagated to the frontend and leaked the token itself:

Counter-intuitively, in the backend, I saw less details about the error:

catalog warn Failed item in location github:https://github.com/spotify/backstage/blob/master/plugins/github-actions/examples/sample.yaml, Error: Unable to read github, Error: Unable to read https://github.com/spotify/backstage/blob/master/plugins/github-actions/examples/sample.yaml, TypeError: token 123abc
is not a legal HTTP header value

Expected Behavior

I think the token should never be leaked and displayed to the frontend. The backend logs should contain as many details about the failure as possible. But ideally, the token would not be printed in the logs either.

Possible Solution

A possible solution is to have a filter that determines the type of error and only provide a more generic message like "unable to read from github. Bad request". And then have the details in the backend logs.

Steps to Reproduce

Deploy Backstage with the Helm charts.

Pick a valid github token and encode it together with a newline character (this was the configuration mistake):

$ printf 'abc123\n' | base64
MTIzCg==

Now add that next to the GITHUB_SECRET in the backstage-backend secret:

kubectl edit secret backstage-backend

Your Environment

This happened with Backstage deployed in Kubernetes.

• NodeJS Version (v12):
• Operating System and Version (e.g. Ubuntu 14.04):
• Browser Information:

[jot-hub]

Hi @martina-if , should be related to https://github.com/node-fetch/node-fetch/pull/843 - but its v3.0.0-beta.9- _finally_(long overdue) only the header name is spitted out in the error and not the value. This should help but not sure if we want to bump-up that far. c.c: @Rugvip