Time Of Check Time Of Use in Flask with Hmac Signatures

Time Of Check Time Of Use (TOCTOU) is a class of race condition where the outcome of a security decision depends on the timing between a check and a subsequent use. In Flask applications that use Hmac Signatures to validate requests, TOCTOU can emerge when the application first verifies a signature (check) and then later uses the associated data (use), with an observable window between the two steps. An attacker can exploit this window by altering the resource that was validated after the check but before it is used, while the application still proceeds based on the earlier verified signature.

Consider a Flask route that accepts an Hmac-signed JSON payload containing a user identifier and an intended action, such as changing an email address. A common pattern is to compute the Hmac over the request body, compare it to the provided signature, and only then parse and act on the JSON. The vulnerability arises if, after signature verification, the application re-parses the body or relies on values that may have been swapped by an adversary. Because HTTP message parsing is mutable until the application fully consumes and locks the data, an attacker can intercept or replay the request in a way that replaces the parsed object between verification and usage. This can lead to privilege escalation or unauthorized actions even when the signature itself remains valid for the original content.

In distributed or asynchronous Flask deployments, TOCTOU with Hmac Signatures is compounded by caching, load balancing, or background workers. If signature validation occurs in one worker and the request context is handed off to another worker that re-evaluates or enriches the data, the second worker might see a version of the data that no longer matches the signed intent. Additionally, if the application logs or stores intermediate representations of the request after verification, those artifacts can be manipulated or replayed to trigger unintended behavior. The key risk is not the cryptographic strength of the Hmac itself, but the lack of an atomic, immutable binding between the signature and the exact usage context at the moment of decision.

Tools such as middleBrick can detect timing-related inconsistencies and missing atomicity by scanning the unauthenticated attack surface of a Flask API. While middleBrick does not inspect internal code paths, its checks for Authentication, Input Validation, and Unsafe Consumption can surface endpoints where signature verification and data usage are not tightly coupled. The LLM/AI Security checks further probe for prompt injection and system leakage, but for API endpoints, the scanner focuses on how inputs are handled before and after verification. By correlating findings across multiple security checks, middleBrick provides prioritized remediation guidance that helps developers tighten the window between check and use.

To prevent TOCTOU with Hmac Signatures in Flask, bind the signature verification and data usage into a single, atomic step and avoid re-parsing or re-evaluating the request body after verification. Always compute the Hmac over a canonical representation of the data you intend to use, and immediately apply the derived values in a way that cannot be altered by later processing. Below are concrete examples demonstrating a vulnerable pattern and a secure remediation.

Vulnerable pattern

An endpoint that verifies the signature and then re-loads JSON from the request can be tricked if the request stream is consumed or mutated between steps.

import hashlib
import hmac
from flask import Flask, request, jsonify

app = Flask(__name__)
SECRET = b'super-secret-key'

def verify_hmac(data: bytes, signature: str) -> bool:
    expected = hmac.new(SECRET, data, hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, signature)

@app.route('/change-email', methods=['POST'])
def change_email():
    signature = request.headers.get('X-Signature')
    if not signature:
        return jsonify({'error': 'missing signature'}), 400
    # Vulnerable: body consumed later, creating a TOCTOU window
    if not verify_hmac(request.data, signature):
        return jsonify({'error': 'invalid signature'}), 403
    payload = request.get_json()  # Re-parsing after verification
    new_email = payload.get('email')
    # Use new_email here...
    return jsonify({'status': 'ok'})

Secure remediation

Compute and use the payload in one pass after verifying the signature against the exact bytes you will use. Do not call request.get_json() again after verification.

import hashlib
import hmac
import json
from flask import Flask, request, jsonify

app = Flask(__name__)
SECRET = b'super-secret-key'

def verify_hmac(data: bytes, signature: str) -> bool:
    expected = hmac.new(SECRET, data, hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, signature)

@app.route('/change-email', methods=['POST'])
def change_email():
    signature = request.headers.get('X-Signature')
    if not signature:
        return jsonify({'error': 'missing signature'}), 400
    body = request.get_data()  # Raw bytes, consumed once
    if not verify_hmac(body, signature):
        return jsonify({'error': 'invalid signature'}), 403
    # Parse once from the already-verified bytes
    try:
        payload = json.loads(body)
    except json.JSONDecodeError:
        return jsonify({'error': 'invalid JSON'}), 400
    new_email = payload.get('email')
    if not new_email:
        return jsonify({'error': 'email required'}), 400
    # Use new_email here with confidence the data matches the signature
    return jsonify({'status': 'ok'})

Additional hardening steps include normalizing JSON key ordering before signing, setting strict content-type checks, and rejecting requests with transfer-encoding manipulations that could alter the message between check and use. When integrating with middleware or caching layers, ensure the signed payload is not re-transformed before consumption. middleBrick’s scans can highlight endpoints where signature usage follows insecure patterns, and the CLI tool (middlebrick scan <url>) can be incorporated into scripts or the GitHub Action to fail builds if risky API behaviors are detected.