Axios errors leak sensitive content - by default this content should not be returned

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.

[vinceve]

In my opinion it is kind of weird to introduce this behaviour. Sure you can clean out the data from your error object and see less, but it won’t stop developers putting console.log in their code. Plus when you’re developing, it will be a nightmare to debug.

The same logic can be applied if the request worked btw: if someone puts a console log in their success handler logging the request, you are still leaking it.

I think it is ultimately the developer’s responsibility to see if his code doesn’t leak any sensitive information.

[tobalsgithub]

@vinceve You’re right. In our case, everything we use axios for is serverside, so it’s that exact scenario that we’re trying to avoid.