Flask vulnerability classes

Flask leaves the database to you, so a Flask view is exactly as safe as the query code you write under request.args, request.form and request.get_json().

Flask is the framework people reach for when they need a small HTTP front for a command-line tool, which makes "take a request, run a program" the most common Flask view that goes wrong.

Flask stays out of your way, which means nothing stands between a query string and eval() except the view you wrote, and one Flask development feature runs Python from the browser by design.

Flask exposes Jinja through two functions that look alike, and template injection is the result of using render_template_string() with a string that already has request data inside it.

Flask itself does not unpickle anything a client sends, so every unsafe deserialization in a Flask application was added above the framework: a YAML import endpoint, an object stored in a cookie, or a cache of pickled results.

Flask gives you one file-serving function that checks the path and one that does not, and path traversal in Flask is mostly a matter of which of the two a view calls.

Flask is where small proxy endpoints get written (an image fetcher, a link preview, a CORS workaround), and each of them is an HTTP client that a visitor aims by filling in a url parameter.

request.get_json() returns whatever JSON the client sent, including nested objects, and a Flask view that drops one of those values into a PyMongo filter has let the client write part of the query.