There's some kind of cognitive dissonance in the crypto community, where on the one hand they hammer into people the concept that they should always use trusted libraries and not screw with any of the settings, but on the other hand- many of those trusted libraries have insecure defaults or non-obvious gotchas that require developers to dive into the documentation and, quite often, understand quite a bit about cryptography.
It looks like this is often the result of legacy code, need to maintain backwards compatibility, etc. etc.; but I think this is one area where those reasons are absolutely NOT justified excuses. When your entire world is based on security - make your product WORK and make it secure BY DEFAULT; nothing else matters.
This is one of those things that just shows how immature the software industry still is.
Often times when people talk about software they talk about feature lists. And they talk about things like design, security, performance, robustness as secondary aspects and often times as things that can be bolted on later. But the reality is that this is exactly backwards. Security, elegance, performance, etc. are fundamental to the operation of a tool, including software. The difference between a tool that does those things well and one that doesn't is not some tiny detail, it's the difference between a tool that is so good it takes over a billion dollar market and one that is relegated to failure.
Look at, say, cars for example. Some cars differ on features but the biggest difference is in the overall design, fit-and-finish, and attention to detail.
If you use pickle to serialize your cookies, and if your secret key is freely available on the interwebz, yes, you've got a problem.
If you use json, you've still got a problem, namely, that your secret key is still freely available on the interwebz. People might not be able to execute arbitrary code on your server, but they can still easily modify their cookies to log in as a different user, steal their personal info, etc. etc.
If we're going to talk about securing our defaults, I think it's very important that we make the defaults actually secure all the way, rather than just making them slightly less insecure than they currently are.
Keep all session data on the server side. Now you've got secure defaults.
Or make sure that your secret key is actually, you know, secret.
It looks like this is often the result of legacy code, need to maintain backwards compatibility, etc. etc.; but I think this is one area where those reasons are absolutely NOT justified excuses. When your entire world is based on security - make your product WORK and make it secure BY DEFAULT; nothing else matters.