In Symfony you can use something called Symfony Secrets. It basically encrypts data like database credentials which you would normally put in your .env file.
Does Rust or it's web-framework Actix-web contain a similar mechanism? Google didn't yield any results.
actix is more a library than one of those kitchen-sink frameworks, note that it doesn't include an ORM or a templating engine either. So you should just look for a library that does what you need.
Regarding your actual request: what are you trying to defend against? Just something that prevents things from accidentally showing up in debug output, keeping thing secure in the event of the whole machine getting compromised, or something else?
Looking at the symfony feature, it seems to be about being able to commit encrypted secrets into git, while keeping the key locally. From a quick search this might provide something similar: dotenv_vault - Rust
Initially only from keeping things accidentally from going to the debug and showing up in your Git/VCS due an accidental commit. Now I am looking for a way to protect the credentials even if the web-app gets compromised.
I elaborated on this question on this Security Stackexchange question.
Well, that's tricky. There are things one can do, but they're narrow solutions, not universal ones.
One options is to store the credentials externally and generate ephemeral keys (e.g. time-limited session tokens or pre-signed requests) through that. Using the operating system's key store to hold signing keys can work there.
If you're holding onto secrets to 3rd-party services which don't provide such a mechanism then you should consider setting automated key rotation and invalidating the old keys.
Or you can reduce the blast radius by using more scoped credentials that only give your server access to specific things instead of a whole account.
Trying to secure things within a process where the threat model is that the process is compromised is futile on architectures where rogue pointers can access anything. You'd need hardware with memory tagging or pointer authentication to gain serious in-process security.
If the app can access secrets, so can the attacker. As the person on stack exchange correctly said, if you want to protect the secrets you have to put them in an external system (like a HSM) and have that system do the operations on the secrets instead of the app.
This doesn't help for things like a db connection string, obviously. I don't think there is anything you can do about that, not really anyways. The best thing you can do there is connect to the db, and then securely overwrite (see zeroize crate) the credentials. But since there is an active connection the attacker can just reuse that to steal your data. Or wait for an app restart. You can make it annoying for the attacker, but not really secure.
I suggest you instead focus on making your app reasonably secure. Most apps get compromised because of incredibly silly mistakes, like allowing sql injection.