The first point about template injection almost seemed like it was going somewhere, but actually feels like a no brainer to avoid, since every flask/jinja tutorial under the sun is going to tell you to use curly-brace placeholders in your templates, and not python's built-in substitution operators/methods.

When I think vulnerabilities, I think of something inherently flawed with the design and implementation of something that can be easily exploited, even when used perfectly as intended. For example, if there was a way for someone to inject code into the template even when used with all common sense template syntax and loading techniques.

Since Jinja/Flask were designed to handle untrusted input sanitization well, this is more of a "gotcha" than a "vulnerability." If you use the tools available to you appropriately, it's not a problem. If you misuse or don't use the tools available to you, you risk accidentally creating vulnerabilities unnecessarily. That sort of goes without saying.

generally there is a secret key known to the server that is used to sign the session. you cannot modify the session without the signature becoming invalid, and the only way to property sign a mutated session would be if the attacker had access to the secret key stored on the server.

generally it’s recommended that the key be 40 bytes (320 bits) of random data but it could be much more. you would have to somehow guess that value to fake a session.

you shouldn’t ever put any sensitive information inside those sessions as they are NOT encrypted and anyone could decode them, the real protection you are afforded is that an attacker (or normal user) can not modify that data and you can be reasonably sure the data can only be modified by your code.

more info: https://blog.paradoxis.nl/defeating-flasks-session-management-65706ba9d3ce