Api Key Exposure in Actix with Dynamodb

When an Actix web service loads configuration or authorization material from a DynamoDB table and exposes it through an unauthenticated or overly permissive endpoint, the combination creates an Api Key Exposure finding. middleBrick detects this pattern during unauthenticated scanning by checking whether API keys or secrets stored in DynamoDB are retrievable without proper authentication or are returned in responses that should not disclose sensitive data.

DynamoDB itself does not leak keys; the risk arises from how the Actix application reads and serves data. For example, if an Actix handler queries DynamoDB for an item containing an api_key field and includes that field in a JSON response to the client, any unauthenticated caller who can trigger that handler can harvest valid API keys. This often occurs when developer convenience routes (e.g., /debug/config) are left in production or when fine-grained authorization is missing, enabling horizontal or vertical privilege escalation across users.

The scan tests for this by probing endpoints that interact with DynamoDB and checking whether responses contain credential-like values. It also inspects the OpenAPI specification for routes that reference DynamoDB-backed data models and looks for missing authentication on those operations. Because Actix routes can map directly to DynamoDB table structures, an OpenAPI/Swagger spec that describes a GET /config operation returning an object with an api_key property — without requiring authentication — will be flagged as a high-severity exposure.

Real-world patterns include hardcoding table names and access keys in Actix configuration files that are inadvertently served, or using DynamoDB conditional checks that fail silently and return partial data including keys. middleBrick’s checks for Input Validation and Authentication ensure these routes are not unintentionally public, and the findings include remediation guidance such as removing sensitive fields from responses and enforcing authentication on configuration endpoints.

Remediation focuses on preventing sensitive DynamoDB data from reaching the client and ensuring that access to configuration or key material is properly restricted. Below are concrete Actix examples that demonstrate secure patterns.

1. Exclude sensitive fields from API responses

When returning data from DynamoDB, omit fields that contain API keys or secrets. Use a dedicated response model that does not include sensitive properties.

use actix_web::{web, HttpResponse, Responder};
use aws_sdk_dynamodb::Client;
use serde::Serialize;

#[derive(Serialize)]
pub struct ConfigResponse {
    pub environment: String,
    pub region: String,
    // api_key is intentionally omitted
}

pub async fn get_config(
    client: web::Data,
    table: web::Data,
) -> impl Responder {
    let resp = client
        .get_item()
        .table_name(table.as_ref())
        .key("id", aws_sdk_dynamodb::types::AttributeValue::S("app_config".to_string()))
        .send()
        .await;

    match resp {
        Ok(output) => {
            let config = ConfigResponse {
                environment: output.item.and_then(|i| i.get("environment")).and_then(|v| v.as_s().ok()).unwrap_or("").to_string(),
                region: output.item.and_then(|i| i.get("region")).and_then(|v| v.as_s().ok()).unwrap_or("").to_string(),
            };
            HttpResponse::Ok().json(config)
        }
        Err(e) => HttpResponse::InternalServerError().body(e.to_string()),
    }
}

2. Require authentication for configuration endpoints

Protect routes that interact with DynamoDB by adding Actix guard checks or extractors that validate tokens or sessions.

use actix_web::{web, HttpRequest, HttpResponse, Responder};
use actix_web::http::header::AUTHORIZATION;

pub async fn get_secure_config(
    req: HttpRequest,
    client: web::Data<aws_sdk_dynamodb::Client>,
    table: web::Data<String>,
) -> impl Responder {
    let auth_header = req.headers().get(AUTHORIZATION);
    if auth_header.is_none() {
        return HttpResponse::Unauthorized().finish();
    }
    // Validate token or session here before proceeding
    let resp = client.get_item().table_name(table.as_ref()).send().await;
    // handle response...
    HttpResponse::Ok().finish()
}

3. Use DynamoDB expressions to limit returned attributes

When querying DynamoDB, request only the attributes you need to avoid returning sensitive fields inadvertently.

let resp = client
    .query()
    .table_name(table.as_ref())
    .select(aws_sdk_dynamodb::types::Select::SpecificAttributes)
    .expression_attribute_names("#env", "environment")
    .projection_expression("#env")
    .send()
    .await;

4. Enforce least-privilege IAM for the Actix service

Ensure the IAM role or user associated with the Actix service can read only the non-sensitive attributes or use conditions that restrict access patterns, reducing the impact of a potential exposure.

These patterns align with remediation guidance provided in middleBrick findings, which map to controls in frameworks such as OWASP API Top 10 API4:2023 (Injection) and API7:2023 (Security Misconfiguration).