You're likely to lose safety implementing a vanilla CRUD app in Rust instead of Django. Rust is mostly buying you memory safety; the rest of its safety features are helpful when building new kinds of applications, but Django CRUD applications follow a well-worn pattern, and the Django developers have done really good work making sure that those patterns are easy to implement securely (usually by default).
Meanwhile, safety in a web application is domain-specific, and there isn't much a language can do to protect you. There aren't really Rust features that directly prevent SSRF attacks, or HTTP desync. In fact, my experience assessing Rust (and Go) web applications is that they intend to reincarnate web vulnerabilities that went mostly extinct in Django applications years ago; for instance, I'm virtually never going to find SQLI in a Django application, but Rust web applications are somewhat likely to build their own SQL queries. This will shock and upset some Rust developers to hear (all the popular Rust SQL interfaces force parameterized queries! they're thinking), but it's true.
I like Rust, and write more Rust than any other language lately. I'd say the same thing about practically any modern language compared to boring old Django, which is the Volvo of web frameworks.
I have nothing much to say about reliability and do recognize that writing in Python or Ruby means that you're also writing ridiculous batteries of unit tests to verify basic things like whether your setters and getters work properly, because the language essentially makes you check your own typos. I'm only talking about security.
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.
Note that I'm not claiming that Rust is the solution to every problem under the sun. It just happens to be pretty much the sweet spot for problems I need to solve, which typically involve concurrency and/or distribution and/or new protocols and/or sophisticated graph algorithms and/or actual OS access.
Meanwhile, safety in a web application is domain-specific, and there isn't much a language can do to protect you. There aren't really Rust features that directly prevent SSRF attacks, or HTTP desync. In fact, my experience assessing Rust (and Go) web applications is that they intend to reincarnate web vulnerabilities that went mostly extinct in Django applications years ago; for instance, I'm virtually never going to find SQLI in a Django application, but Rust web applications are somewhat likely to build their own SQL queries. This will shock and upset some Rust developers to hear (all the popular Rust SQL interfaces force parameterized queries! they're thinking), but it's true.
I like Rust, and write more Rust than any other language lately. I'd say the same thing about practically any modern language compared to boring old Django, which is the Volvo of web frameworks.
I have nothing much to say about reliability and do recognize that writing in Python or Ruby means that you're also writing ridiculous batteries of unit tests to verify basic things like whether your setters and getters work properly, because the language essentially makes you check your own typos. I'm only talking about security.