This may be the first time I've ever disagreed with a comment you've made, but here we go!
> Meanwhile, safety in a web application is domain-specific, and there isn't much a language can do to protect you.
There absolutely is. Rust's expressive type system is a more important feature than the memory-safety guarantees for general purpose programming. This has significant impact on the ability to express security constructs directly in the code. Witness, for instance, the widespread use of typing to distinguish unvalidated and validated user inputs, such as Rocket's RawStr type [0].
Applying that technique can mitigate SSRF attacks without even knowing the details. You can worry all you like about SQLI in Rust, but in the code I've seen it's no more a concern than any web app, and likewise it can be enforced in the type system in a way that sure seems superior to "hope the dev only writes boring Python".
I'd agree with the general premise that, all things being equal, the security of something that looks exactly like everything else is higher than some novel construct. But I strongly disagree that there's nothing a language can do to help developers write secure applications, and I'd suggest it starts with an expressive type system.
I think the idea of somehow using types to express safe vs. unsafe URLs is much less compelling as an SSRF mitigation than using client certificates or proxies to rule them out, which is what shops that are serious about SSRF already do. Meanwhile: I think if you go looking at Rust web applications, you're going to find that they in fact do nothing like this at all --- they're not using magic types as an SSRF mitigation.
Similarly: it's not at all my claim that Rust is somehow more susceptible as a language to SQLI attacks! The opposite thing is true: Rust, as a language, is far better situated to deal with them, because of expressive typing. But that's what could be, not what is. In practice, ironic or not, if you implement the same CRUD application in circa-2020 Rust and in Django, the Rust application is more likely to have SQLI.
The point is that unlike kernel code or browser components, where memory safety is most of the ballgame and Rust is a real game-changer, web application security is domain-specific. The language and its runtime are much less important to web security than what gets built on top of the language. And right now, even though Python is an objectively inferior language, more of the domain of web security is built more carefully on Django than what's available on Rust.
If the question is simply, how can you maximize security of a CRUD app project you're starting in 2020, the answer is probably to build it on Django.
As to your points about what patterns are more likely in actual practice, I can't speak to that; I've only seen a handful of Rust web apps. But the ones I've seen absolutely do use type-foo to keep things straight.
> The language and its runtime are much less important to web security than what gets built on top of the language.
That's a great point. I would highlight, though, that what gets built (and how likely it is to have bugs, which is also pertinent!) is directly impacted by the language and runtime, so the two questions can't be neatly separated.
In the long run, will most users be writing the guts of, say, a session manager to support their CRUD app? No, of course not, they'll just reach for some shared resource. Is it easier to be confident that the Rust implementation of that library has a lower incidence of bugs? Today, no, because for the Django version you can rely on the major real-world use as evidence of reliability, but in the long run, almost certainly. Is it easier to be confident that the usage of the Rust version of the library is correct? Absolutely, since the invariants can be enforced by the compiler.
The session manager thing is a great example of what I'm talking about. A completely custom session manager in a Django app would be shocking. In a Rust app? Not so much.
> Meanwhile, safety in a web application is domain-specific, and there isn't much a language can do to protect you.
There absolutely is. Rust's expressive type system is a more important feature than the memory-safety guarantees for general purpose programming. This has significant impact on the ability to express security constructs directly in the code. Witness, for instance, the widespread use of typing to distinguish unvalidated and validated user inputs, such as Rocket's RawStr type [0].
Applying that technique can mitigate SSRF attacks without even knowing the details. You can worry all you like about SQLI in Rust, but in the code I've seen it's no more a concern than any web app, and likewise it can be enforced in the type system in a way that sure seems superior to "hope the dev only writes boring Python".
I'd agree with the general premise that, all things being equal, the security of something that looks exactly like everything else is higher than some novel construct. But I strongly disagree that there's nothing a language can do to help developers write secure applications, and I'd suggest it starts with an expressive type system.
[0]: https://api.rocket.rs/v0.4/rocket/http/struct.RawStr.html