Bola Idor in Fastapi with Dynamodb

Broken Object Level Authorization (BOLA) occurs when an API exposes one object identifier (ID) to a user who can then manipulate requests to access or modify a different object that belongs to another user. In a Fastapi application backed by DynamoDB, this typically happens when authorization checks are missing or incomplete between object lookup and operation execution.

Consider a Fastapi endpoint designed to retrieve a user profile by an item_id supplied in the URL. If the endpoint queries DynamoDB using that item_id but does not verify that the authenticated subject owns or is authorized for that specific item, an authenticated attacker can change the item_id to another valid identifier and read or affect another user’s data. DynamoDB’s key-based access patterns make this especially risky: with a predictable key structure (e.g., PK=USER#123, SK=PROFILE#abc), an attacker can systematically iterate identifiers to discover accessible resources.

In Fastapi, route parameters and query parameters often map directly to DynamoDB key expressions. For example, an endpoint like /users/{user_id}/settings might construct a DynamoDB KeyConditionExpression using user_id as the partition key. If the application does not enforce that the authenticated user’s subject ID matches the requested user_id, the request satisfies DynamoDB’s access conditions while bypassing authorization. This is a classic BOLA/IDOR vector: the object identifier is user-controlled, the database returns a result, and the application returns that result without validating ownership or scoped permissions.

DynamoDB’s permission model can inadvertently support this mistake. IAM policies or fine-grained token-based authorizations may grant broad read/write rights to a table or index, assuming application-layer checks will narrow access. When those checks are absent or incorrectly applied, the API surface becomes wide open. Additionally, sparse index usage or secondary indexes can expose alternate key paths that an attacker might try if primary identifiers are not carefully namespaced per tenant or subject.

Common attack patterns include changing numeric IDs, swapping UUIDs, or manipulating URL path segments to reference sibling records. In DynamoDB, because keys are central to access, predictable key designs amplify the impact: an attacker who knows the schema can attempt sequential or enumerated identifiers to test for missing authorization. Even with rate limiting present, BOLA can remain undetected if requests succeed but access control is simply missing rather than explicitly denied.

To detect this during a middleBrick scan, the tool examines the unauthenticated attack surface and checks whether authorization is validated consistently across object references. It cross-references OpenAPI/Swagger definitions and runtime behavior to identify endpoints where identifiers flow into DynamoDB queries without corresponding subject validation. The scanner does not fix the logic, but it surfaces findings with severity and remediation guidance to help developers tighten object-level checks.

Remediation for BOLA in Fastapi with DynamoDB centers on ensuring that every data access includes the correct authorization context tied to the authenticated subject. This means validating that the item’s owning subject matches the authenticated user before constructing or executing a DynamoDB query.

One robust pattern is to derive the partition key from the authenticated subject rather than from user-supplied input. For example, instead of using the request’s user_id parameter as the DynamoDB key, compute the key using the authenticated principal’s ID. This eliminates the attacker’s ability to substitute another identifier.

Below is a concrete Fastapi example using the AWS SDK for DynamoDB (v2 style with boto3-compatible interface) that demonstrates secure retrieval of a user’s settings. The code retrieves the authenticated user’s ID from the security dependency, builds a key that includes a tenant or subject namespace, and queries DynamoDB only with that authorized key.

from fastapi import Depends, FastAPI, HTTPException, status
import boto3
from pydantic import BaseModel

app = Fastapi()

def get_current_user_id() -> str:
    # In practice, this would validate an auth token and return the subject ID.
    # Placeholder: replace with real auth logic.
    return "user-abc-123"

class SettingsResponse(BaseModel):
    user_id: str
    theme: str
    notifications_enabled: bool

dynamodb = boto3.resource("dynamodb", region_name="us-east-1")
TABLE_NAME = "app-settings"

@app.get("/settings", response_model=SettingsResponse)
def read_settings(user_id: str = Depends(get_current_user_id)):
    table = dynamodb.Table(TABLE_NAME)
    # Build a namespaced key to avoid cross-tenant leaks
    partition_key = f"USER#{user_id}"
    try:
        response = table.get_item(
            Key={
                "PK": partition_key,
                "SK": "PROFILE",
            }
        )
    except Exception as e:
        raise HTTPException(
            status_code=status.HTTP_500_INTERNAL_SERVER_ERROR,
            detail="Failed to retrieve settings",
        )
    item = response.get("Item")
    if not item:
        raise HTTPException(status_code=404, detail="Settings not found")
    return SettingsResponse(
        user_id=user_id,
        theme=item.get("theme", "light"),
        notifications_enabled=item.get("notifications_enabled", True),
    )

In this example, the user_id parameter comes from a dependency that represents the authenticated subject, not from the request path. The DynamoDB key explicitly includes a namespace prefix (USER#) to avoid collisions and ensure that even if an attacker guesses an identifier, they cannot access another tenant’s data if your authorization logic correctly binds the subject to the key prefix.

For endpoints that accept an item_id but still require object-level checks, always re-derive or validate ownership before querying. For instance, if items belong to a user, include both the subject ID and the item ID in the key or perform a secondary authorization check after retrieval:

@app.get("/items/{item_id}", response_model=dict)
def read_item(item_id: str, user_id: str = Depends(get_current_user_id)):
    table = dynamodb.Table(TABLE_NAME)
    # Assume items are stored with owner_id as part of the key
    response = table.get_item(Key={"PK": f"USER#{user_id}", "SK": f"ITEM#{item_id}"})
    item = response.get("Item")
    if not item:
        raise HTTPException(status_code=404, detail="Item not found or access denied")
    return item

Additionally, apply principle of least privilege to DynamoDB IAM roles or token scopes so that even if an identifier leaks, the impact is limited. Combine these practices with continuous scanning using tools like middleBrick to surface missing authorization checks. The scanner can map findings to frameworks such as OWASP API Top 10 and provide prioritized remediation guidance without altering your runtime or attempting automatic fixes.