Overview
In CVE-2021-21241, Flask-Security-Too (a maintained fork of Flask-Security) could return an authentication token in responses to GET requests on sensitive endpoints such as /login and /change. GET requests are not CSRF-protected by default, so an attacker could lure an authenticated user to visit a malicious site that triggers these GET calls and capture the token from the response, enabling token theft and potential account compromise. This vulnerability stemmed from improper handling of tokens in token-based auth flows within Flask-Security-Too versions prior to 3.4.5 and 4.0.0, where tokens could be exposed in GET responses rather than being delivered through POST flows with proper CSRF protection. The patch in 3.4.5 and 4.0.0 eliminates token exposure in such GET responses. As a workaround for deployments that cannot upgrade immediately, setting SECURITY_TOKEN_MAX_AGE to 0 would render tokens unusable, reducing the risk in the interim. This guidance maps to the CVE and focuses on real-world implications for Flask apps using Flask-Security-Too.
Affected Versions
Flask-Security-Too >=3.3.0, <3.4.5
Code Fix Example
Flask API Security Remediation
Vulnerable pattern (older Flask-Security-Too behavior):
from flask import Flask, jsonify
import secrets
app = Flask(__name__)
@app.route('/login', methods=['GET'])
def login_get():
# Vulnerable: token is included in the GET response
token = secrets.token_hex(32) # token generated for demonstration
return jsonify({'token': token})
# Fixed pattern (upgrade to 3.4.5+/4.0.0 or implement CSRF-protected flow):
from flask import Flask, jsonify, request
app = Flask(__name__)
@app.route('/login', methods=['POST'])
def login_post():
# Do not expose tokens in GET responses; tokens are delivered via secure, CSRF-protected flows
# Validate credentials here (omitted for brevity)
return jsonify({'status': 'ok'})