HIGH missing tlsflaskbasic auth

Missing Tls in Flask with Basic Auth

Missing Tls in Flask with Basic Auth — how this specific combination creates or exposes the vulnerability

Using HTTP Basic Authentication in a Flask application without Transport Layer Security (TLS) exposes credentials and session tokens to interception on the network. Basic Auth encodes the username and password with Base64, which is easily reversible. Without TLS, the encoded string travels in plaintext and can be captured through passive sniffing or active man-in-the-middle (MITM) attacks. middleBrick detects this combination during black-box scanning, flagging the absence of TLS as a high-severity encryption finding and noting that authentication credentials are transmitted unencrypted.

The risk is compounded because Basic Auth is often sent with every request, including those that are not obviously sensitive, such as metadata or status endpoints. An attacker on the same network segment can collect valid credentials and reuse them to impersonate users. In some configurations, if TLS is misconfigured (for example, using deprecated protocols or weak ciphers), the encryption may be insufficient to prevent downgrade attacks or decryption. Because middleBrick performs unauthenticated scans, it can identify endpoints that accept Basic Auth over non-TLS channels and highlight the missing encryption as a critical gap in the API security posture.

Additionally, without TLS, other security mechanisms that depend on encrypted channels—such as secure cookies or injected headers—can be stripped or altered in transit. This makes it easier to conduct injection or tampering attacks that further undermine authentication. The combination of weak transport protection and the inherent reversibility of Basic Auth creates a scenario where account takeover can occur with minimal effort. Remediation requires enforcing TLS for all endpoints and ensuring that authentication is only accepted over encrypted connections.

Basic Auth-Specific Remediation in Flask — concrete code fixes

To secure Basic Auth in Flask, enforce HTTPS across the application and validate that credentials are only accepted over encrypted channels. Below is a minimal, secure example that integrates Basic Auth with TLS enforcement using a request handler and a before_request hook. This pattern ensures that any request arriving over HTTP is rejected before authentication logic is executed.

from flask import Flask, request, Response
import ssl

app = Flask(__name__)

# Require HTTPS for all requests
@app.before_request
def enforce_https():
    if not request.is_secure:
        return Response(
            '{"error": "HTTPS required"}',
            status=403,
            mimetype='application/json'
        )

# Basic Auth verification (example hardcoded credentials; use environment variables or a secure store in production)
VALID_USERNAME = 'api_user'
VALID_PASSWORD = 's3cur3P@ss!'

@app.route('/protected')
def protected():
    auth = request.authorization
    if not auth or auth.username != VALID_USERNAME or auth.password != VALID_PASSWORD:
        return Response(
            '{"error": "Unauthorized"}',
            status=401,
            mimetype='application/json',
            headers={'WWW-Authenticate': 'Basic realm="API"'}
        )
    return Response('{"status": "ok"}', mimetype='application/json')

if __name__ == '__main__':
    context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
    context.load_cert_chain(certfile='server.crt', keyfile='server.key')
    app.run(host='0.0.0.0', port=5000, ssl_context=context)

In production, avoid hardcoding credentials. Instead, load them from environment variables or a secrets manager and rotate them regularly. Combine this with HTTP Strict Transport Security (HSTS) headers to instruct browsers and intermediaries to always use HTTPS, reducing the risk of accidental cleartext access. middleBrick’s scans can verify that TLS is enforced and that authentication mechanisms are not exposed over insecure transports, helping teams prioritize remediation.

For teams using the middleBrick CLI, running middlebrick scan <url> against an endpoint with Basic Auth and no TLS will surface the encryption issue in the findings report. The Pro plan’s continuous monitoring can track whether encryption is consistently applied across all monitored APIs, and the GitHub Action can fail builds if a new route introduces HTTP-only authentication. These integrations help ensure that the combination of Basic Auth and missing TLS is caught early and not introduced in later stages of development.

Related CWEs: encryption

CWE IDNameSeverity
CWE-319Cleartext Transmission of Sensitive Information HIGH
CWE-295Improper Certificate Validation HIGH
CWE-326Inadequate Encryption Strength HIGH
CWE-327Use of a Broken or Risky Cryptographic Algorithm HIGH
CWE-328Use of Weak Hash HIGH
CWE-330Use of Insufficiently Random Values HIGH
CWE-338Use of Cryptographically Weak PRNG MEDIUM
CWE-693Protection Mechanism Failure MEDIUM
CWE-757Selection of Less-Secure Algorithm During Negotiation HIGH
CWE-261Weak Encoding for Password HIGH

Frequently Asked Questions

Can Basic Auth be used safely without TLS if the credentials are rotated frequently?
No. Even with frequent rotation, Basic Auth encodes credentials reversibly and transmits them in cleartext without TLS. An attacker can capture and use the credentials before rotation occurs. TLS is required to protect credentials in transit regardless of rotation policy.
How does middleBrick detect missing TLS when scanning an API with Basic Auth?
middleBrick performs unauthenticated black-box checks and attempts to interact with endpoints over HTTP. If the endpoint accepts and returns sensitive authentication-related responses without requiring TLS, the scan flags missing encryption and highlights the risk of credential exposure in the report.