You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Shipping req objects as part of error reports can lead to the leakage of secure information, including credentials. Sentry will strip "sensitive" keys in a project, but 1) users have to know to turn it on, 2) this still means you're sending the content over the wire to a third party, and 3) they won't strip all of them; Authentication headers, for example, seem to be retained, and depending on the arbitrary naming of request body fields the contents thereof may or may not actually be stripped.
I'd suggest instead a whitelist of content to send, rather than just sending an entire req object (which also results in the serialization of less-than-useful content, too).
This is probably a major version iteration, but unfortunately, as-is, nest-raven is IMO unsafe in production. I may be able to do the heavy lifting on fixes, however, if we can agree on an API.
The text was updated successfully, but these errors were encountered:
nest-raven is directly using[1] official sentry nodejs method for extracting request data [2]. Which by default extracts only some keys[3]. This can be configured[4,5], but not currently in nest-raven [6]. Would the addition of this suite your needs?
So I did look at that before posting, and it seems like the keys that it extracts are shallow ones. And they make sense--pull headers, cookies, that sort of thing. Where it goes sideways is nested keys, like req.headers.authorization, which it doesn't seem to deal with (and relies on Sentry's remote sensitive-key stripping to deal with, where it can?).
I've learned from experience to lead people into making secure choices by default. Some degree of configurability here might help, but I'm still concerned overall with how easy it'll be to accidentally data-exfiltrate yourself.
Shipping
req
objects as part of error reports can lead to the leakage of secure information, including credentials. Sentry will strip "sensitive" keys in a project, but 1) users have to know to turn it on, 2) this still means you're sending the content over the wire to a third party, and 3) they won't strip all of them;Authentication
headers, for example, seem to be retained, and depending on the arbitrary naming of request body fields the contents thereof may or may not actually be stripped.I'd suggest instead a whitelist of content to send, rather than just sending an entire
req
object (which also results in the serialization of less-than-useful content, too).This is probably a major version iteration, but unfortunately, as-is,
nest-raven
is IMO unsafe in production. I may be able to do the heavy lifting on fixes, however, if we can agree on an API.The text was updated successfully, but these errors were encountered: