Integer Overflow in Actix with Dynamodb

An integer overflow in an Actix web service that interacts with DynamoDB can occur when user-supplied numeric values (such as quantity, size, or limit parameters) are used to compute request parameters like page size, batch write item counts, or pagination offsets without validating range or overflow behavior. In Rust, arithmetic operations such as addition or multiplication on primitive integer types (e.g., u32, usize) will panic in debug builds on overflow, but in release builds they will wrap around by default, producing small invalid values that may be trusted and forwarded to DynamoDB.

When these computed values are used as part of a DynamoDB request, the resulting behavior can be unexpected: a wrapped overflow value may produce an invalid request that DynamoDB rejects, or—more dangerously—a small computed value may be interpreted as an acceptable limit that unintentionally exposes more data than intended. For example, an attacker could provide a crafted query parameter that results in a computed offset of zero or a very small page size, bypassing intended pagination limits and leading to data exposure or excessive consumption of read capacity units.

Because middleBrick scans the unauthenticated attack surface, it can detect endpoints where large or unexpected numeric inputs reach DynamoDB calls, surface these as input validation and property authorization findings, and highlight the risk of logic manipulation via integer overflow. The scanner checks for missing upper bounds, missing range checks, and unsafe deserialization of numeric fields, which are common contributors to overflow-related API weaknesses.

To prevent integer overflow when building DynamoDB requests in Actix, validate and sanitize all numeric inputs before using them in request construction. Use checked arithmetic and enforce explicit bounds that align with DynamoDB service limits. Below are concrete, realistic code examples showing safe patterns for pagination and batch operations.

Safe pagination with validated offset and limit

Ensure limit and offset are validated, parsed as non-negative integers, and bounded before constructing an AWS SDK request. Use checked_add when computing derived values.

use aws_sdk_dynamodb::types::PaginatorState;
use aws_sdk_dynamodb::{Client, Error};
use actix_web::{web, HttpResponse};
use std::num::NonZeroU32;

async fn query_items(
    client: web::Data,
    query: web::Query>,
) -> Result {
    let table_name = "ItemsTable";
    let limit_str = query.get("limit").map(|s| s.as_str()).unwrap_or("20");
    let offset_str = query.get("offset").map(|s| s.as_str()).unwrap_or("0");

    // Parse and validate inputs
    let limit = limit_str
        .parse::()
        .map_err(|_| HttpResponse::BadRequest().body("invalid limit"))?;
    let offset = offset_str
        .parse::()
        .map_err(|_| HttpResponse::BadRequest().body("invalid offset"))?;

    // Enforce sensible bounds to avoid excessive consumption
    let bounded_limit = NonZeroU32::new(limit.min(1000)).ok_or_else(|| {
        HttpResponse::BadRequest().body("limit must be between 1 and 1000")
    })?;

    // Build the request safely; use checked math if computing new values
    let next_token = if offset > 0 {
        // For exclusive start key, you would store the last evaluated key separately
        // and use it as ExclusiveStartKey when offset > 0.
        None
    } else {
        None
    };

    let mut request = client
        .scan()
        .table_name(table_name)
        .limit(bounded_limit);

    if let Some(token) = next_token {
        request = request.exclusive_start_key(token);
    }

    let resp = request.send().await?;
    Ok(HttpResponse::Ok().json(resp.items().unwrap_or_default()))
}

Batch write with checked item count

When writing items in batches, cap the batch size to a safe maximum and use checked arithmetic to avoid overflow when computing total request size or item counts.

use aws_sdk_dynamodb::types::WriteRequest;
use aws_sdk_dynamodb::{Client, Error};
use actix_web::web;

async fn batch_write_items(
    client: web::Data,
    items: Vec,
) -> Result<(), Error> {
    // Cap batch size to a safe value aligned with DynamoDB limits
    const MAX_BATCH_SIZE: usize = 25;
    let batch_size = items.len().min(MAX_BATCH_SIZE);

    // Use checked operations when aggregating counts or sizes
    let _total: usize = batch_size;

    let write_requests: Vec = items[..batch_size]
        .chunks(25)
        .map(|chunk| {
            WriteRequest::builder()
                .put_request(
                    aws_sdk_dynamodb::types::PutRequest::builder()
                        .item(chunk[0].clone())
                        .build(),
                )
                .build()
        })
        .collect();

    let req = client.batch_write_item().set_request_items(write_requests).build();
    req.send().await?;
    Ok(())
}

These patterns demonstrate how to enforce input validation, bounded ranges, and checked arithmetic when constructing DynamoDB requests from Actix services. By combining these practices with continuous scanning using middleBrick, you can detect risky numeric handling before it reaches production.