Potential security concern with streamlit caching error messages


I’m using streamlit to build some internal dashboards, and one of the processes I’ve got in there is caching some database calls, so that every time a user interacts with the dashboards, we don’t need to re-pull our source data. However, when investigating a caching error, I noticed that the error logs were fairly verbose and appeared to expose our DB credentials (error message sampled below) when printing the hash chain. Does anyone have any ideas/answers on potentially reducing the verbosity level of this error message or on a way forward that doesn’t expose sensitive creds?

While caching the body of `pl_base_data_component()`, Streamlit encountered an
object of type `builtins.weakref`, which it does not know how to hash.

If you don't know where the object of type `builtins.weakref` is coming
from, try looking at the hash chain below for an object that you do recognize,
then pass that to `hash_funcs` instead:

Object of type builtins.list: [(..., (<class 'sqlalchemy.pool.impl.QueuePool'>, ...),... {'client_flag': 2, 'host': <DB_HOST>, 'passwd': <DB_PASSWORD>, 'user': <DB_USERNAME>}]]

Appreciate any guidance here.


Hi @Senthil,

Thanks for posting! Are you caching your DB credentials?


My actual credentials are pulled from environment vars; only a reference to the host name is included in the actual script. The function which I’m caching here executes a sql query, so it includes the sqlalchemy db connection object.

Just to clarify – is the error message exposing the actual credentials, or is it just “<DB_PASSWORD>”, etc.?

It’s exposing actual credentials. I have obfuscated them for the purpose of this post.

Thanks! Let me check with our team

Hey @_Senth_N,

you can hide error messages within the app through a config variable. Just create a file .streamlit/config.toml in your project dir with the following content:

showErrorDetails = False

We recommend doing that for secure production apps and we also enable that by default on Streamlit’s Community Cloud. More info on config options here. We try to keep exception messages as helpful as possible, that’s why we are showing the detailed information to you during development.

Let me know if that works for you or if you have any other concerns.

Cheers, Johannes


Awesome, thank you Johannes. That ought to work just fine for my use case here. Appreciate the prompt support.

Actually @jrieke a follow up - reading through the configs documentation, it appears that the errors would still print in their entirety to the console. If we’re logging the stdout/console (because they’re on a deployed container), then the DB creds exposed in the error message would still be logged, would they not? Of course, its still an improvement over the creds being shown in the browser, but some concerns might still remain.

Just following up here again re: my second concern @jrieke or @Caroline

Hey @_Senth_N, yes the error would still print to the command line. This is something we are thinking about changing, so feel free to add your thoughts to the discussion here

Got it - done. Would really hope to see this implemented, as it is a roadblock for the time being to have an exception that ends up exposing credentials to our logs.