<p dir="auto">This is more of a FYI kind of issue.</p>
<p dir="auto"><strong>Is your feature request related to a problem? Please describe.</strong><br>
When making a request via Axios, if an error is caught and logged as-is, it will contain the entire request object which contains headers which can include credentials such as API keys.<br>
If someone isn't aware of this and just logs the entire error object or error.toJSON() without sanitising it, they can leak sensitive data and credentials.</p>
<p dir="auto"><strong>Describe the solution you'd like</strong><br>
A config option to not append the request object to thrown errors and keep only the standard error properties from the spec <a href="https://nodejs.org/api/errors.html#errors_class_error" rel="nofollow">https://nodejs.org/api/errors.html#errors_class_error</a></p>
<p dir="auto"><strong>Describe alternatives you've considered</strong><br>
I've worked around this by creating a new error object and only copying the standard error properties and the response status to the new error and throwing that instead.</p>
<p dir="auto"><strong>Is your feature request related to a problem? Please describe.</strong><br>
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]</p>
<p dir="auto">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: <a href="https://github.com/axios/axios/blob/master/index.d.ts#L82">https://github.com/axios/axios/blob/master/index.d.ts#L82</a></p>
<p dir="auto">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.</p>
<p dir="auto">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.</p>
<p dir="auto"><strong>Describe the solution you'd like</strong><br>
A clear and concise description of what you want to happen.</p>
<p dir="auto">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.</p>
<p dir="auto">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</p>
<div class="highlight highlight-source-ts notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="ax.interceptors.response.use(
    (response) =&gt; response,
    (error) =&gt; Promise.reject(new Error(error.message))
);"><pre class="notranslate"><span class="pl-s1">ax</span><span class="pl-kos">.</span><span class="pl-c1">interceptors</span><span class="pl-kos">.</span><span class="pl-c1">response</span><span class="pl-kos">.</span><span class="pl-en">use</span><span class="pl-kos">(</span>
    <span class="pl-kos">(</span><span class="pl-s1">response</span><span class="pl-kos">)</span> <span class="pl-c1">=&gt;</span> <span class="pl-s1">response</span><span class="pl-kos">,</span>
    <span class="pl-kos">(</span><span class="pl-s1">error</span><span class="pl-kos">)</span> <span class="pl-c1">=&gt;</span> <span class="pl-smi">Promise</span><span class="pl-kos">.</span><span class="pl-en">reject</span><span class="pl-kos">(</span><span class="pl-k">new</span> <span class="pl-smi">Error</span><span class="pl-kos">(</span><span class="pl-s1">error</span><span class="pl-kos">.</span><span class="pl-c1">message</span><span class="pl-kos">)</span><span class="pl-kos">)</span>
<span class="pl-kos">)</span><span class="pl-kos">;</span></pre></div>
<p dir="auto">This interceptor could be disabled by the configuration flag.</p>
<p dir="auto">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.</p>
<p dir="auto"><strong>Describe alternatives you've considered</strong><br>
A clear and concise description of any alternative solutions or features you've considered.</p>
<p dir="auto">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.</p>
<p dir="auto"><strong>Additional context</strong><br>
Add any other context or screenshots about the feature request here.</p>