Skip to content

Avoid leaking any headers that appear as though may be sensitive#166

Closed
tjarratt wants to merge 1 commit intoelixir-error-tracker:mainfrom
tjarratt:avoid-leaking-any-headers-that-appear-senstive
Closed

Avoid leaking any headers that appear as though may be sensitive#166
tjarratt wants to merge 1 commit intoelixir-error-tracker:mainfrom
tjarratt:avoid-leaking-any-headers-that-appear-senstive

Conversation

@tjarratt
Copy link
Contributor

@tjarratt tjarratt commented Jan 7, 2026

Hello ! Me again with another security related Pull Request.

As a follow-up to #160 I'd like to make the filtering of the context for errors captured from Phoenix a bit more intelligent and less hard-coded.

The major change in behaviour here is that instead of filtering out a few specific request headers, we filter out anything that looks like it could potentially be sensitive and undesirable to store in cleartext. The idea here being that it's good to be more secure by default.

I believe that a good change after this would be to make this configurable with an allowlist option, or to allow users to specify their own deny list.

@crbelaus
Copy link
Contributor

crbelaus commented Mar 1, 2026

I'm sorry but I don't think this should be merged. We could come up with an infinite list of potential headers that could be private in some cases. Anyone's system can use custom headers at any time, so this list could also grow to infinite.

At the moment we are filtering cookie and authorization headers which are the most common and standard ones. An argument could be made that we should filter set-cookie so outgoing cookies are filtered in the same way as incoming cookies.

Everything else can be filtered according to each app needs with a custom ErrorTracker.Filter implementation.

@crbelaus crbelaus closed this Mar 1, 2026
crbelaus added a commit that referenced this pull request Mar 1, 2026
We now redact headers instead of just dropping them. This allows users
of the Error Tracker to know wether a header was present or not. With
the previous logic it was impossible to know wether the header was
dropped or not present in the first place.

We also redact the `set-cookie` header so we redact outgoing cookies and
not only incoming cookies as per the `cookie` header.

This PR replaces #166
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants