Brute Force Attack in Flask with Basic Auth

A brute force attack against a Flask application using HTTP Basic Authentication attempts to discover valid credentials by systematically submitting many username and password combinations. Because Basic Auth encodes credentials with Base64 rather than encrypting them, requests expose the username with every request. An attacker who can observe or intercept traffic gains the username, reducing the search space to passwords only. In Flask, developers sometimes protect routes with custom decorators or middleware that check the Authorization header without additional protections, relying on transport security such as HTTPS to slow attackers. However, HTTPS alone does not prevent rapid credential guessing; it only protects secrecy in transit. Without rate limiting or other throttling mechanisms, an attacker can make many sequential requests using tools such as curl, requests, or specialized scanners, submitting hundreds or thousands of attempts per minute. Flask’s default single-threaded development server is especially vulnerable to high-throughput guessing when deployed without a production WSGI stack or reverse proxy protections. The enumeration pattern is straightforward: for a known username like admin, iterate over a password list, observe HTTP 200 versus 401 responses, and confirm valid credentials. This behavior becomes an API-style attack surface when the endpoint returns distinct status codes or timing differences that allow adaptive offline guessing. Because middleBrick scans unauthenticated attack surfaces, it can detect whether the application exposes status code distinctions that facilitate brute force and whether authentication endpoints lack rate controls. Attack patterns such as credential stuffing also intersect with brute force when attackers reuse username and password pairs harvested from other breaches against the Basic Auth interface. The presence of predictable usernames and weak password policies further increases risk. Because middleBrick tests authentication mechanisms as part of its 12 parallel security checks, it can surface findings related to Authentication and BFLA/Privilege Escalation when brute force conditions are identified.

Remediation focuses on reducing the effectiveness of credential guessing by combining rate limiting, secure password storage, and proper response handling. Below is a minimal, secure Flask example that uses HTTP Basic Auth with bcrypt hashing and rate limiting via Flask-Limiter.

from flask import Flask, request, jsonify
from flask_limiter import Limiter
from flask_limiter.util import get_remote_address
import bcrypt
import base64

app = Flask(__name__)
limiter = Limiter(app=app, key_func=get_remote_address, default_limits=["5 per minute"])

# In-memory store for example; use a database in production
USERS = {
    "admin": bcrypt.hashpw(b"StrongPassphrase123!", bcrypt.gensalt())
}

def check_auth(username, password):
    if username in USERS:
        return bcrypt.checkpw(password.encode("utf-8"), USERS[username])
    return False

@app.route("/protected")
@limiter.limit("5 per minute")
def protected():
    auth = request.authorization
    if not auth or not check_auth(auth.username, auth.password):
        return jsonify({"error": "Unauthorized"}), 401
    return jsonify({"message": "Authenticated"}), 200

if __name__ == "__main__":
    app.run(ssl_context="adhoc")

Key practices illustrated:

• Rate limiting at the route level (5 requests per minute per IP) to slow brute attempts.
• Use of bcrypt with a salt to store password hashes, preventing offline password recovery if hashes are leaked.
• Consistent 401 responses for both missing credentials and invalid credentials to avoid username enumeration via status code differences.
• Enabling HTTPS (adhoc context for dev; a proper certificate in production) to protect credentials in transit.

For deployments behind a reverse proxy or load balancer, configure the proxy to enforce additional rate limits and to set X-Forwarded-For headers correctly so that Flask-Limiter can identify client IPs. You can also integrate middleBrick’s CLI to validate that these controls are effective: use middlebrick scan <url> to run an unauthenticated scan and review authentication and rate-limiting findings. Teams on the Pro plan can enable continuous monitoring to track changes to authentication behavior over time, while the GitHub Action can fail builds if a security score drops below a chosen threshold, ensuring that new changes do not reintroduce weak authentication patterns.