Dangling Dns in Actix with Bearer Tokens

A dangling DNS configuration in an Actix web service becomes high risk when combined with Bearer Token authorization, because the token may be accepted from an untrusted or spoofed endpoint. In a typical Actix application, routes are defined and middleware such as actix-web-httpauth is used to extract and validate Bearer tokens. If the service relies on DNS-based service discovery or dynamic endpoint resolution, and if the DNS record can be manipulated or is slow to converge, an attacker can position a malicious host at the resolved IP while the application still holds a valid Bearer token for that service name.

During a middleBrick scan, this surface is tested by resolving the API hostname at scan time and then attempting to reach the same endpoint via an alternate network path or a controlled DNS response. When Bearer tokens are passed via the Authorization header, the scan checks whether the token is accepted without verifying the identity or integrity of the host presenting it. A finding is generated when the API accepts the token from a host that is not the authoritative service endpoint, effectively creating a trust boundary bypass. This maps to the BOLA/IDOR and Authentication checks in middleBrick’s 12 parallel security checks. The risk is especially pronounced in microservice environments where services are registered in DNS and tokens are propagated across internal networks without additional host verification.

For example, consider an Actix service that resolves internal.example.com to a backend at startup. If the DNS record later changes to point to a rogue host, and the Actix app does not re-validate the hostname presented during TLS handshake, the Bearer token intended for the legitimate backend may be sent to the attacker. MiddleBrick detects this by performing unauthenticated requests with valid Bearer tokens against the resolved endpoint and observing whether the token is accepted from unexpected network positions. Findings include the CVE-2023-38545-style network confusion patterns and references to the OWASP API Top 10 2023 A07:2023 — Identification and Authentication Failures, emphasizing the importance of binding tokens to specific endpoints and validating DNS and TLS properties.

An illustrative Actix snippet that demonstrates the vulnerable pattern is shown below. In this code, the token is read from the Authorization header and used to authorize access, but there is no verification that the request resolves back to the expected service identity:

use actix_web::{web, App, HttpResponse, HttpServer, Responder};
use actix_web::http::header::HeaderValue;
use actix_web::dev::ServiceRequest;
use actix_web_httpauth::extractors::bearer::BearerAuth;
use actix_web_httpauth::middleware::HttpAuthentication;

async fn validate_token(
    auth: BearerAuth,
) -> Result {
    // Vulnerable: no host verification, token accepted from any route
    if auth.token() == "valid_token_123" {
        Ok(HttpResponse::Ok().body("Authorized"))
    } else {
        Ok(HttpResponse::Unauthorized().finish())
    }
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let auth = HttpAuthentication::bearer(validate_token);
    HttpServer::new(move || {
        App::new()
            .wrap(auth.clone())
            .route("/secure", web::get().to(|| async { HttpResponse::Ok().body("data") }))
    })
    .bind("0.0.0.0:8080")?
    .run()
    .await
}

Remediation focuses on ensuring that Bearer tokens are validated in the context of the expected network endpoint, preventing acceptance of tokens from mismatched hosts. In Actix, this involves combining token validation with explicit hostname or certificate checks, and avoiding the acceptance of tokens when the request resolves to an unexpected address. middleBrick’s remediation guidance maps to secure coding practices and framework-specific patterns that reduce the attack surface presented by dangling DNS.

One approach is to resolve the expected hostname at startup and compare it with the TLS presented hostname on each request. Below is a secure Actix example that performs this check before validating the Bearer token:

use actix_web::{web, App, HttpResponse, HttpServer, Responder, dev::ServiceRequest};
use actix_web::http::header::HeaderValue;
use actix_web_httpauth::extractors::bearer::BearerAuth;
use actix_web_httpauth::middleware::HttpAuthentication;
use std::sync::Arc;

async fn validate_token_and_host(
    req: ServiceRequest,
    auth: BearerAuth,
) -> Result {
    // Expected hostname resolved at startup or via a trusted source
    let expected_host = "api.example.com";
    // Extract the host from the request
    if let Some(host_header) = req.connection_info().host().split(':').next() {
        if host_header != expected_host {
            return Err((actix_web::error::ErrorForbidden("host mismatch"), req));
        }
    } else {
        return Err((actix_web::error::ErrorForbidden("missing host"), req));
    }
    // Validate token after host check
    if auth.token() == "valid_token_123" {
        Ok(req)
    } else {
        Err((actix_web::error::ErrorUnauthorized("invalid token"), req))
    }
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let auth = HttpAuthentication::bearer(|req, auth| validate_token_and_host(req, auth));
    HttpServer::new(move || {
        App::new()
            .wrap(auth.clone())
            .route("/secure", web::get().to(|| async { HttpResponse::Ok().body("data") }))
    })
    .bind("0.0.0.0:8080")?
    .run()
    .await
}

For environments using service discovery, pin the service identity using certificate-bound tokens or mTLS, and validate the client certificate against a pinned CA. Another pattern is to use a static configuration map that associates service names with allowed IPs or DNS names, and reject any request that does not match the map. The middleBrick CLI can be used in CI/CD to verify that these guards are present by scanning the endpoint with Bearer tokens and flagging responses that accept tokens from unresolved or mismatched hosts.

When integrating into pipelines, the GitHub Action can enforce that no scan result includes a high-severity finding for Authentication or BOLA checks related to token handling. The MCP Server allows developers to trigger scans from their IDE and review findings before merging. These products help maintain continuous assurance that Bearer token usage remains bound to the correct host and that dangling DNS conditions are detected early.