You didn't mention all the things in Flask Security Considerations: https://flask.palletsprojects.com/en/latest/web-security/ You probably want SameSite Strict. I wrote a diatribe about cookies, it is still largely relevant. Browsers have improved since but also not everyone is on the latest browser. TL;DR Enable all the security features possible for session cookies, and CSRF cookies, but don't use cookies otherwise. https://waters.me/internet/use-cookies-like-it-is-2018/ Security headers discussed here: https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html In development and deployment you typically want a Content Security Policy, you typically want a CDN if none is provided by the hosting provider. You don't want to know how bad frames are you just need to stop people doing weird stuff with your app. If you are using simple passwords people will pick weak ones. You don't discuss threat model, what does your app actually do? It may be acceptable to leave passwords to the user if it is something trivial like game high scores, or something you can't afford such as cryptocurrency services. Threat should determine effort, but threat includes GDPR or other legal responsibilities that potentially fall on you. The biggest weakness less important sites will have is storing (and thus eventually leaking) weak password hashes as people reuse passwords still. I know 2025 and people are still ignorant of basic web security, thing about users is there are new ones being born everyday, including yesterday. Also storing more user data than you need (you probably need an email address for password reset flows, do you really need their name? If you need a stronger password reset, you might need a postal address, depending again on what your app does). Flask defaults to a sensible password hash scheme if you use the right modules, but check what you are actually storing, not just a hash but a good one with enough rounds. From a session testing point of view I commonly see not overwriting session cookie at login page delivery (you need to assume anything in the browser before they GET the login page is compromised), not changing the session cookie on successful login, not invalidating old sessions on logout or password change, or similar security related account operations like disabling an account (can't login but current session is valid). Leaking session cookies to other hosting providers is a classic, lot of sites set the application session cookie at the top level domain "example.com" to share across subdomains ("app.example.com", "support.example.com"), then have some cheap Wordpress instance on "www.example.com" telling me how good their security is, which they send the session cookie of every user to needlessly, so no matter how much security they do they'll never get better than Wordpress levels of security (Wordpress security is fine for a blog but you don't want to add it to your apps attack surface). Most important hack to know about sessions, Paypal credit card hack, in early days of PayPal someone created a webpage telling people how to link their credit card to their Paypal account, except it silently logged them into a Paypal account he controlled when they visited his helpful page. He of course knew his own username and password, but was still an "attacker" against their user's credit card details, lack of CSRF on login page, again using Flask forms correctly for login prevents this. More on reddit.com

Why the fuck would you use the pickle module to read/maintain state? De-serialization's #1 rule has ALWAYS been don't de-serialize data from an un-known source (and in this case I'm making an addendum - a terribly guarded source). JSON works just as well and doesn't risk poisoning the namespace! And if you do use it, don't fall victim to mass assignment vulnerabilities (which is basically the same attack)! More on reddit.com

there is a working solution (flask-login), why not use it? More on reddit.com