Graphql Introspection in Axum with Dynamodb

GraphQL introspection in an Axum service that uses DynamoDB as the backend can expose both schema structure and operational patterns that increase the attack surface. Introspection queries return type definitions, queries, mutations, and field resolvers, which can reveal how data is modeled in DynamoDB and how authorization is applied.

In Axum, a GraphQL endpoint typically resolves requests against a schema that maps to DynamoDB operations such as GetItem, Query, or Scan. If introspection is enabled in production, an attacker can discover which DynamoDB tables are queried, what key schemas are used, and how conditional expressions are constructed. This information can be combined with BOLA or IDOR testing to infer valid resource identifiers and data ownership rules.

Because DynamoDB often stores sensitive user data, exposure of field names like user_id, email, or api_key through introspection can guide targeted injection or privilege escalation attempts. MiddleBrick detects this risk as part of its Property Authorization and Input Validation checks, highlighting where introspection responses may leak data exposure risks.

Middleware or framework-level logging in Axum can also inadvertently reflect introspection requests or responses, increasing the risk of information leakage. When combined with unauthenticated endpoints, this can enable an attacker to probe the API surface without credentials, a scenario flagged by MiddleBrick’s Unauthenticated LLM Endpoint and SSRF checks when introspection is tied to discovery workflows.

Using MiddleBrick’s OpenAPI/Swagger analysis, the tool cross-references the GraphQL schema definitions with runtime behavior, identifying mismatches between declared capabilities and actual DynamoDB query patterns. This helps teams understand whether introspection is necessary and whether it should be restricted behind authentication or schema hiding.

To reduce risk when using GraphQL with DynamoDB in Axum, implement schema hiding, strict authorization, and query validation. Below are concrete, working examples that demonstrate secure patterns.

1. Disable introspection in production

Use the introspection option in your GraphQL layer to disable discovery in non-development environments.

use axum::routing::post;
use tower_http::cors::CorsLayer;
use graphql::Schema;

let schema = Schema::build(query_root, EmptyMutation::new(), EmptySubscription::new())
    .introspection(false) // disable introspection in production
    .finish();

let app = Router::new()
    .route("/graphql", post(graphql_handler))
    .layer(CorsLayer::permissive());

2. Validate and parameterize DynamoDB queries

Ensure that GraphQL resolver inputs are mapped to parameterized DynamoDB expressions to avoid injection and malformed key conditions.

use aws_sdk_dynamodb::types::AttributeValue;
use aws_sdk_dynamodb::Client;

async fn get_user_by_id(client: &Client, user_id: &str) -> Result<aws_sdk_dynamodb::types::Item, String> {
    let resp = client.get_item()
        .table_name("Users")
        .key("user_id", AttributeValue::S(user_id.to_string()))
        .send()
        .await
        .map_err(|e| e.to_string())?;

    Ok(resp.item().cloned().ok_or("Item not found".to_string())?)
}

3. Apply field-level authorization before DynamoDB access

Enforce ownership checks in Axum extractors before constructing DynamoDB requests, reducing reliance on runtime filtering.

use axum::extract::State;
use serde::{Deserialize, Serialize};

#[derive(Deserialize)]
struct UserQuery {
    user_id: String,
}

async fn user_profile_handler(
    State(user_service): State<UserService>,
    query: Query<UserQuery>,
) -> Result<Json<User>, (StatusCode, String)> {
    let current_user = user_service.current_user();
    if current_user.id != query.user_id {
        return Err((StatusCode::FORBIDDEN, "Unauthorized".into()));
    }
    let user = user_service.get_user(&query.user_id).await?;
    Ok(Json(user))
}

4. Use middleware to block introspection in specific routes

In Axum, implement a layer that rejects introspection operations based on the request payload.

use axum::http::Request;
use tower::Layer;

struct IntrospectionBlockLayer;

impl Layer for IntrospectionBlockLayer {
    type Service = IntrospectionBlockService;

    fn layer(&self, inner: S) -> Self::Service {
        IntrospectionBlockService { inner }
    }
}

struct IntrospectionBlockService<S> {
    inner: S,
}

impl<S, B> tower::Service<Request<B>> for IntrospectionBlockService<S>
where
    S: tower::Service<Request<B>>,
{
    type Response = S::Response;
    type Error = S::Error;
    type Future = S::Future;

    fn poll_ready(&mut self, cx: &mut Context<'_>) -> Poll<Result<(), Self::Error>> {
        self.inner.poll_ready(cx)
    }

    fn call(&self, mut req: Request<B>) -> Self::Future {
        let body = req.body();
        if let Some(bytes) = body.as_ref() {
            if bytes.contains(b"__schema") || bytes.contains(b"__type") {
                return future::err(axum::http::Error::new_custom(
                    axum::http::error::InvalidHeader::custom("introspection blocked"),
                ));
            }
        }
        self.inner.call(req)
    }
}

# Example IAM policy condition
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "dynamodb:GetItem",
            "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Users",
            "Condition": {
                "StringEquals": {
                    "aws:SourceVpce": "vpce-abc123"
                }
            }
        }
    ]
}