Pii Leakage in Aspnet with Dynamodb

When an ASP.NET application interacts with Amazon DynamoDB, PII leakage commonly arises from a mismatch between application-layer object models and the schema design in DynamoDB. In a typical ASP.NET setup, developers map domain entities to C# classes and serialize them into DynamoDB items. If these classes contain properties such as Email, PhoneNumber, NationalId, or other personal data, and those properties are stored in DynamoDB without appropriate controls, any API endpoint that retrieves and returns those items can unintentionally expose PII.

DynamoDB’s schema-less nature means items within the same table can vary in structure. This flexibility can lead to accidental inclusion of sensitive attributes in responses when queries return broader item projections than intended. For example, a query that fetches user profiles for authentication might also return attributes like Ssn or DateOfBirth if they are present in the item. In ASP.NET, if the response serializer includes all public properties of the entity without explicit filtering, PII can be transmitted to clients or logged inadvertently.

Additionally, DynamoDB streams can amplify PII exposure. If an ASP.NET backend writes change events to a stream and those streams are consumed by other services or logged for debugging, items containing PII may be persisted or transmitted without encryption at rest or in transit. Misconfigured IAM policies may also allow broader access than necessary, enabling an attacker who compromises a lower-privilege role to retrieve items that include sensitive fields.

The risk is further influenced by how the ASP.NET application constructs queries. A query that uses a FilterExpression to narrow results on the client side still retrieves the full item from DynamoDB before filtering, meaning PII outside the filter is transferred over the network. If the endpoint does not explicitly project only required attributes (using ProjectionExpression), the response can contain more data than the client expects, increasing the likelihood of PII leakage through logs, error messages, or client-side storage.

middleBrick detects these patterns by correlating OpenAPI/Swagger specifications with runtime behavior. For an ASP.NET endpoint documented to return a subset of attributes, if DynamoDB scan or query results include additional fields such as Email or PhoneNumber, this discrepancy is flagged. The scanner also checks whether responses contain patterns recognized as PII, such as email regex patterns or known sensitive field names, and highlights the absence of server-side projection or encryption controls.

To mitigate PII leakage in an ASP.NET application using DynamoDB, implement server-side attribute selection, strict IAM policies, and response filtering. Use ProjectionExpression in queries and scans to retrieve only the necessary attributes, ensuring PII fields are never pulled from DynamoDB unless explicitly required and protected.

Below are concrete, working examples for a .NET 6+ application using the AWS SDK for .NET.

1. Query with ProjectionExpression

Retrieve only non-sensitive attributes for authentication purposes.

var request = new QueryRequest
{
    TableName = "Users",
    KeyConditionExpression = "UserId = :uid",
    FilterExpression = "Enabled = :enabled",
    ExpressionAttributeValues = new Dictionary<string, AttributeValue>
    {
        { ":uid", new AttributeValue { S = "user123" } },
        { ":enabled", new AttributeValue { BOOL = true } }
    },
    ProjectionExpression = "UserId, Username, EmailVerified"
};
var response = await dynamoDbClient.QueryAsync(request);

2. Conditional check before returning sensitive fields

Ensure sensitive fields are accessed only under strict authorization.

var getItemRequest = new GetItemRequest
{
    TableName = "Users",
    Key = new Dictionary<string, AttributeValue>
    {
        { "UserId", new AttributeValue { S = "user123" } }
    },
    ProjectionExpression = "UserId, Username, Email, PhoneNumber"
};
var getItemResponse = await dynamoDbClient.GetItemAsync(getItemRequest);
if (getItemResponse.Item.TryGetValue("Email", out var emailAttr))
{
    // Only include PII if the caller is authorized
    if (UserHasConsentOrAdminRole()) 
    {
        result.Email = emailAttr.S;
    }
}

3. Use DynamoDB Streams with filtering

Consume streams safely by excluding PII-rich items or masking them before processing.

// Example processing Lambda input
public async Task FunctionHandler(DynamodbEvent evnt, ILambdaContext context)
{
    foreach (var record in evnt.Records)
    {
        if (record.eventName == "INSERT" || record.eventName == "MODIFY")
        {
            var image = record.dynamodb.NewImage;
            // Remove or mask PII before further use
            if (image.ContainsKey("PhoneNumber"))
            {
                image["PhoneNumber"] = new StreamRecordValue { S = "MASKED" };
            }
            await ProcessItemAsync(image);
        }
    }
}

4. Enforce encryption and access controls

Ensure the table uses server-side encryption and that IAM roles follow least privilege.

// IAM policy snippet for read-only access without PII fields
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:GetItem",
                "dynamodb:Query"
            ],
            "Resource": "arn:aws:dynamodb:region:account:table/Users",
            "Condition": {
                "ForAllValues:StringEquals": {
                    "dynamodb:Attributes": ["UserId", "Username", "EmailVerified"]
                }
            }
        }
    ]
}

By combining these patterns, an ASP.NET service can limit DynamoDB responses to necessary data, avoid transferring PII unnecessarily, and align with secure-by-design practices. middleBrick’s scans validate that such projection and filtering are reflected in both the API contract and runtime behavior, reducing the risk of unintentional data exposure.