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