Dangling Dns in Flask with Api Keys

A dangling DNS record occurs when a hostname (e.g., internal.example.com) previously pointed to a service but now resolves to an unexpected or unmanaged endpoint. In Flask applications that rely on API keys for outbound service calls, this creates a risk where the application may inadvertently send credentials to an attacker-controlled host.

Consider a Flask app that uses an API key to call a payment provider. The code resolves payments.vendor.internal at startup or on each request. If the vendor decommissions the service and the DNS record is not removed or updated, the hostname may resolve to a server under an attacker’s control. Because the Flask app includes a valid API key in requests, an attacker can capture the key and reuse it, leading to credential misuse, data exfiltration, or lateral movement within a private network.

This scenario is especially relevant when API keys are passed in headers or query parameters, as the attacker only needs a dangling hostname to receive the secret. The vulnerability is compounded when the Flask app runs in environments where DNS resolution is not tightly controlled, such as development or containerized setups. The app assumes the hostname remains trustworthy, but the DNS zone may have changed without the application’s knowledge.

In a black-box scan, middleBrick tests for unauthenticated endpoints and inspects outbound behavior patterns. It flags scenarios where API keys are transmitted to unresolved or repurposed hosts by analyzing request paths and DNS-related findings. Because the scan runs without credentials, it can detect exposed surfaces where dangling DNS records intersect with key-based authentication, highlighting risks like SSRF or external data exposure.

Another angle involves internal service discovery. If a Flask service queries a hostname like worker.int.example.com that later becomes dangling, and the response is not validated, an attacker who registers the name can intercept or manipulate traffic. middleBrick’s checks include inventory management and unsafe consumption tests, which help surface these misconfigurations by correlating spec definitions with runtime behavior.

LLM/AI security probes are not directly used to find dangling DNS, but the scanner’s parallel checks ensure that any endpoint making outbound calls—keyed or otherwise—is assessed for exposure. This is valuable because the same misconfiguration can lead to indirect prompt injection or data leakage when integrated into automated workflows.

To mitigate dangling DNS risks when using API keys in Flask, validate hostnames and pin connections where possible, and ensure keys are not sent to unresolved or unknown endpoints.

1. Use an allowlist of known hosts

Before making a request, confirm the target hostname is expected. Example using requests with an allowlist:

import requests
from urllib.parse import urlparse

ALLOWED_HOSTS = {"api.vendor.com", "payments.vendor.com"}

def call_vendor_api(key: str, path: str) -> dict:
    url = f"https://api.vendor.com{path}"
    parsed = urlparse(url)
    if parsed.hostname not in ALLOWED_HOSTS:
        raise ValueError(f"Hostname not allowed: {parsed.hostname}")
    headers = {"Authorization": f"Apikey {key}"}
    resp = requests.get(url, headers=headers, timeout=5)
    resp.raise_for_status()
    return resp.json()

2. Resolve and verify at runtime

Perform a DNS lookup and compare the result to a known good address. This approach adds a layer of assurance that the hostname hasn’t been hijacked:

import socket
import requests

def safe_get(url: str, key: str) -> dict:
    expected_ip = "192.0.2.10"  # Known good IP for the service
    hostname = urlparse(url).hostname
    resolved = socket.getaddrinfo(hostname, 443)
    ips = {addr[4][0] for addr in resolved}
    if expected_ip not in ips:
        raise RuntimeError(f"DNS resolution mismatch for {hostname}")
    headers = {"Authorization": f"Apikey {key}"}
    resp = requests.get(url, headers=headers, timeout=5)
    resp.raise_for_status()
    return resp.json()

3. Avoid embedding keys in query strings

Pass API keys in headers rather than query parameters to reduce exposure in logs or referrer leaks:

from flask import Flask, request, jsonify
import requests

app = Flask(__name__)

@app.route("/proxy")
def proxy():
    api_key = request.headers.get("X-API-Key")
    if not api_key:
        return jsonify({"error": "missing key"}), 400
    # Use a verified host
    resp = requests.get(
        "https://api.vendor.com/data",
        headers={"Authorization": f"Apikey {api_key}"},
        timeout=5
    )
    resp.raise_for_status()
    return jsonify(resp.json())

4. Rotate keys and monitor changes

Regularly rotate API keys and integrate host inventory checks into your deployment pipeline. If a hostname becomes dangling, rotation limits the window during which a captured key is valid.

5. Use environment-based configuration

Load allowed hosts and keys from environment variables to simplify updates without code changes:

import os
import requests
from flask import Flask

app = Flask(__name__)
ALLOWED_HOSTS = set(os.getenv("ALLOWED_HOSTS", "api.vendor.com").split(","))

def call_service(path: str) -> dict:
    hostname = urlparse(f"https://{os.getenv('API_HOST')}/").hostname
    if hostname not in ALLOWED_HOSTS:
        raise ValueError("Unrecognized host")
    key = os.getenv("API_KEY")
    resp = requests.get(f"https://{os.getenv('API_HOST')}{path}",
                        headers={"Authorization": f"Apikey {key}"})
    resp.raise_for_status()
    return resp.json()

These practices reduce the chance that an API key is sent to a dangling or malicious host. They align with secure-by-design principles and complement scanning tools like middleBrick, which can highlight mismatches between declared endpoints and runtime behavior.