Dictionary Attack in Flask with Api Keys

A dictionary attack in a Flask API that relies on API keys as the sole authentication mechanism exploits predictable or easily guessable key values. In this setup, clients send an X-API-Key header on each request, and the server checks the header against a list of valid keys stored locally or in a database. If those keys are low-entropy strings, reused across services, or exposed in source control, an attacker can systematically iterate through a list of candidate keys to discover valid ones.

Flask itself does not provide built-in protections against such guessing attempts; without explicit rate limiting, lockout, or key rotation, a dictionary attack becomes feasible. Attackers may probe endpoints that return different responses for authenticated versus unauthenticated requests, or that leak subtle timing differences, to infer whether a given key is valid. Because API keys are often long-lived and shared across services, compromising one key can grant broader access across the system. The risk is compounded when unauthenticated endpoints expose functionality that can be used to enumerate users or resources, aiding the attacker in narrowing the key space.

The combination of Flask routes that accept API keys without additional context (such as per-client nonces or rotating tokens) and insufficient monitoring allows attackers to run automated scripts that submit thousands of guesses within seconds. If the API does not enforce rate limiting or progressive delays, each request completes quickly, enabling high-throughput trials. Moreover, if logging or error messages inadvertently confirm successful authentication (for example, returning richer data or different HTTP status codes), the attacker gains clear feedback to refine the dictionary. This pattern is commonly seen in services that adopt API keys for simplicity but overlook the need for adaptive defenses, turning what should be a shared secret into a static credential vulnerable to offline and online guessing.

middleBrick detects this risk as part of its Authentication and Rate Limiting checks during unauthenticated scans. By probing the API with a curated list of candidate keys and analyzing response differences, it can identify endpoints that accept guessed keys and lack protective mechanisms. The scan also examines OpenAPI specifications for comments or examples that might inadvertently disclose key formats, and correlates findings with the Inventory Management checks to highlight whether keys appear in exposed documentation or configuration samples. The outcome is a prioritized finding that maps to the OWASP API Security Top 10 and common compliance frameworks, emphasizing the need for stronger key lifecycle management and request throttling.

To mitigate dictionary attacks, Flask APIs using API keys should incorporate rate limiting, key rotation, and validation logic that avoids static, guessable credentials. Below are concrete code examples that demonstrate these practices in a Flask application.

First, enforce rate limiting at the route or application level using a token bucket or sliding window approach. The example uses a simple in-memory store for illustration; in production, use a distributed store such as Redis to coordinate limits across workers.

from flask import Flask, request, jsonify
import time

app = Flask(__name__)

# Simple in-memory rate limit store: {key: [timestamps]}
request_log = {}

def is_rate_limited(api_key, limit=100, window=60):
    now = time.time()
    timestamps = request_log.get(api_key, [])
    # Remove outdated entries
    recent = [t for t in timestamps if now - t < window]
    if len(recent) >= limit:
        return True
    request_log[api_key] = recent + [now]
    return False

@app.before_request
def authenticate():
    if request.endpoint in ['public_health', 'static_assets']:
        return  # skip auth for truly public endpoints
    api_key = request.headers.get('X-API-Key')
    if not api_key or is_rate_limited(api_key):
        return jsonify({"error": "unauthorized or rate limit exceeded"}), 401
    # Optionally validate key format and existence in a store
    if not is_valid_key_format(api_key):
        return jsonify({"error": "invalid key format"}), 400
    g.api_key = api_key

def is_valid_key_format(key: str) -> bool:
    # Enforce a minimum length and character set to reduce predictability
    import re
    pattern = re.compile(r'^[A-Za-z0-9\-_]{32,64}$')
    return bool(pattern.match(key))

Second, generate and rotate keys using a cryptographically secure method, and store only hashed representations. Avoid embedding keys directly in source code or configuration files that are checked into version control.

import secrets
import hashlib
import sqlite3

def create_key():
    # Generate a high-entropy key suitable for use as an API key
    return secrets.token_urlsafe(32)

def store_key(plain_key, user_id):
    hashed = hashlib.sha256(plain_key.encode()).hexdigest()
    conn = sqlite3.connect('keys.db')
    cur = conn.cursor()
    cur.execute(
        'INSERT INTO api_keys (key_hash, user_id, created_at) VALUES (?, ?, datetime('now'))',
        (hashed, user_id)
    )
    conn.commit()
    conn.close()
    return plain_key  # return only once to the caller

# Example usage:
# raw_key = create_key()
# issued = store_key(raw_key, user_id=42)
# return jsonify({"api_key": issued})

Third, validate keys against a backend store rather than a static list, and return uniform error responses to avoid information leakage. Combine this with monitoring to detect bursts of failed attempts that indicate a dictionary attack in progress.

def is_valid_key_format(key: str) -> bool:
    import re
    pattern = re.compile(r'^[A-Za-z0-9\-_]{32,64}$')
    return bool(pattern.match(key))

def verify_key_in_db(api_key_hash, conn):
    cur = conn.cursor()
    cur.execute('SELECT id, active FROM api_keys WHERE key_hash = ?', (api_key_hash,))
    row = cur.fetchone()
    return row is not None and row[1] == 1

By implementing these patterns, Flask services reduce the effectiveness of dictionary attacks and align better with security best practices for API key management.