Such a configuration would only be as secure as the least secure webapp connecting to the Redis server.
Redis primarily runs as a single-threaded server operating with a bunch of "databases" that effectively act as namespaces to perform separation of data such that keys don't collide. Unfortunately for us, these namespaces don't give us any ability to control who can access them so anyone who can access one namespace can access all of them.
Therefore, any application can see any other application's full Redis state (the KEYS
command can help here) so long as they're on the same cluster/server. As such, you will always be mixing states of differing applications even if you're using different databases and other key-naming best practices.
Assuming all of the applications are perfect, then you should be fine to do this. Applications themselves probably won't poke into other applications' states and won't (accidentally) clobber each other's states or in-cache data.
However, we can't assume applications are perfect. If any of the applications connected to that server get compromised, an attacker can (potentially easily) dump all keys for the current namespace, dump other namespaces, and effectively read whatever they want. It's relatively unlikely that an attacker will know to do this, but it's better not to find out.
For security (and performance), it's often better to run a dedicated Redis instance per application. Redis is light enough that such a configuration shouldn't be too much of a load on any given server infrastructure.