Issue 1:
Describe the issue

Right now, axios helpfully copies its config into all error messages. Unfortunately, if there is sensitive data in this config (e.g. API keys) this is also logged. There should be an easily accessible option to help prevent this, because most people won't bother to put in the effort for security. This use case is intended for node.js users, where consumers of the logs aren't necessarily as privileged as those running the library.

Example Code

Code snippet to illustrate your question

// in externalapi.js
const instance = axios.create({
baseUrl: 'https://something.com',
headers: {
'X-Api-Key': 'secretstring',
}
});

// in useapi.js
instance.get('/somethnig'); // oops, typo; throws 404 error

Expected behavior, if applicable

Right now, the thrown error includes the API key in the logs, which is not ideal. Instead, there should be a way to include the API key in the config without including it in the errors. We might also want to to remove it from the response config as well in case downstream users want to copy-paste that in their own errors.

Environment:

Axios Version 0.19.2

OS: N/A

Additional Library Versions: Node 12

Additional context/Screenshots

It might be nice to be able to encode additional data and headers in the config which aren't included in the config returned by response. Perhaps this could be done via separate secretData or secretHeaders fields which are treated separately.

Issue 2:
Is your feature request related to a problem? Please describe.

A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Errors thrown by axios have the full request body (and response body if a response was received before the error was thrown). The shape of errors thrown by axios is shown here: https://github.com/axios/axios/blob/master/index.d.ts#L82

There's no doubt that having this information can be incredibly useful. Especially if using interceptors to do retries or otherwise respond to errors, having access to the original request is incredibly useful.

Unfortunately, this also means that if the original request contained sensitive content, that sensitive content is now on the error being thrown / rejected. This puts the onus on the developer to remember to properly cleanse the error before allowing it to be thrown or logged. And this certainly doesn't always happen. I cringe a little bit thinking about all the usernames / passwords that are being logged to browser consoles around the world when login requests fail, for example.

Describe the solution you'd like

A clear and concise description of what you want to happen.

I'm a big believer in doing the safe thing by default, and allowing that behavior to be overridden intentionally by developers if so desired. What I would prefer here is that axios automatically cleanse the error of the request and response content by default, but allow the developer to pass in a flag to override this behavior.

One possible way this could be achieved is by adding a final response interceptor at the end of any user defined interceptors, that essentially just looks like so

ax.interceptors.response.use(
(response) => response,
(error) => Promise.reject(new Error(error.message))
);

This interceptor could be disabled by the configuration flag.

I believe this would allow developers to utilize the full error object as it is today in any interceptors they define, but would prevent the final error from containing any sensitive content by default.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

The proposed solution is a breaking change. As an alternative, we could keep the existing behavior as the default, and allow a flag to enable the "clean" errors functionality described above. This would at least allow developers an easy way to make sure any errors are sensitive content free. But it still requires the developer to know about the flag and set it to be safe.

Additional context

Add any other context or screenshots about the feature request here.