Crashlytics: Do bearer tokens get filtered out client side?

[andordavoti]

Does the crashlytics client library filter out bearer tokens from requests that get logged to your platform? I've tried researching and testing this, but I haven't found any definitive answers. Our API needs two bearer tokens that shouldn't be sent to any logging service.

[mikehardy]

Hi there!
Not sure what you mean with any of this unfortunately 🤔
For questions this detailed / and that may have to do with security, you will want to go a layer down to the firebase-android-sdk / firebase-ios-sdk repositories, examine their code where open/available and post in their issues where you need clarification

At this layer (react-native-firebase) we don't typically create or interact with tokens at all.

[andordavoti]

The issue could come up if a network request fails which has JWT tokens in the header, then I don't want to send that to Crashlytics. However it looks like Crashlytics only reports native crashes and not JS crashes so it might not be an issue. We are using Sentry for JS crashes and errors, so I might only need to filter it out there.

[mikehardy]

@andordavoti @react-native-firebase\crashlytics can report javascript crashes if you like, in fatal or non-fatal style, chained or not chained to default exception handles if you like. There's a test button for it in our test app and I wrote an entire blog article describing it here https://invertase.io/blog/react-native-firebase-crashlytics-configuration#configurable-exception-handler-chaining

So that assertion is suspect:

it looks like Crashlytics only reports native crashes and not JS crashes

I'm not sure it's worth following any of the rest of the chain of logic built on it?

My confusion here:

Not sure what you mean with any of this unfortunately thinking

Is still standing. I'm not sure what your actual use case is.

[andordavoti]

Ah I see. Then I might need to look into JS crashes with Crashlytics...

My use case is that we attach two JWT bearer tokens to HTTP requests sent to the backend. If one of these requests fail Axios (the HTTP library we are using) will throw an error which contains the two JWT bearer tokens. However, we don't want these tokens to be sent to Google or Sentry in our case. So we are unsure if we need to filter them out, or if that is handled by the client libraries.

Does this description make more sense?😅

[mikehardy]

If the error message itself contains the bearer token in the error message then it's possible that they will be logged, as the error message and then it's stack trace is logged. If you configure the module here correctly it is testable at least, you'll know soon enough. In my experience building out the javascript "crashes are fatal" / "optional chaining to default javascript uncaught exception handler" feature here my crashes were showing up on the firebase crashlytics console with very little delay. Make sure you've got the crashlytics crash report list set to the correct app though - I think it was defaulting to ios and I was testing on android app so the crashes did not show up and that was confusing for me until I realized there is not a combined list of crashes, it is a list of crashes per app and ios + android are considered separate apps.

[andordavoti]

Thanks, then I'll look more into that. Appreciate the input:)