In the past there have been concerns about using ASAN in production in certain environments: https://seclists.org/oss-sec/2016/q1/363 . The comment is from 2016 - what is the landscape like today?
Is it recommendable to use the sanitizers here in a production system running on a user's device? The application receives untrusted input from other parties and processes these in various ways.
Are there security relevant impacts from using them? Do any of the added instrumentations actually make it easier to remotely exploit a bug?
The application I'm considering this for is open source, so easing reverse engineering would not be an issue for in this case.
Sanitizers are primarily meant to be used as debug, not hardening tools i.e. for error detection at verification stage but not error prevention in production. Otherwise they may leak sensitive info to the attacker (by printing details about address space and library version to stderr on error) or obtain local root privileges due to uncontrolled use of environment variables. Also sanitizers may add quite a bit of overhead (2x slowdowns are not uncommon for Asan, 1.5x for UBsan).
In general sanitizers are sometimes used in production environment for A/B testing, to increase coverage and detect bugs which escaped normal QA.
Clang has many options for hardening: fortification (-D_FORTIFY_SOURCE=2), ASLR (-fPIE),
stack protection (-fstack-protector, -fsanitize=safe-stack) and control-flow integrity (-fsanitize=cfi) (see Clang Hardening Cheatsheet for details). They have a much smaller overhead and are specifically meant to be used in production.
UPDATE (thanks to @cisnjxqu):
UBsan supports the -fsanitize-minimal-runtime mode which provides minimalistic, low-overhead runtime library which is supposed to not increase the application attack surface.