Pii Leakage in Fiber with Dynamodb

When building HTTP services with the Fiber web framework and persisting data in Amazon DynamoDB, PII leakage commonly arises from mismatches between API surface design and database access patterns. In a black-box scan, middleBrick tests the unauthenticated attack surface of a Fiber endpoint and checks whether responses inadvertently expose email addresses, phone numbers, national identifiers, or other personal data stored in DynamoDB items. Because DynamoDB stores semi-structured attributes, developers may return entire items or overly broad projections without redaction, allowing sensitive fields to reach the client.

The risk is amplified when endpoints accept user-controlled identifiers (e.g., a path parameter like userID) and use them directly in a DynamoDB GetItem or Query without enforcing field-level authorization. For example, an endpoint designed to return a user profile might deserialize a DynamoDB item into a struct that includes sensitive attributes such as SSN or creditCardLast4. If the JSON encoder writes all struct fields, PII is exposed regardless of whether the client requested it. middleBrick’s Property Authorization checks highlight cases where returned data exceeds what the caller should see, tying the finding to the OWASP API Top 10 and GDPR expectations for data minimization.

DynamoDB-specific configurations can also contribute to leakage. When sparse attributes are stored in a single table and conditional projections are not applied, a query might return items with fields that should remain internal (e.g., internal flags or tokens). If the service layer does not explicitly select only safe attributes, the response may include sensitive data. middleBrick’s Data Exposure checks examine responses for patterns like API keys and PII, flagging endpoints that return full DynamoDB items without sanitization. Real-world scan findings often map to the BOLA/IDOR category when an attacker iterates over IDs and receives data belonging to other users, demonstrating how weak authorization around DynamoDB keys enables PII leakage.

Another contributing factor is unsafe consumption patterns in the service code. Deserializing DynamoDB attribute values into loosely typed maps or using raw map[string]interface{} without validation allows unexpected sensitive fields to pass through. middleBrick’s Input Validation and Unsafe Consumption checks look for missing schema constraints and missing redaction logic. Because LLM endpoints are increasingly integrated with backend data stores, the scanner’s LLM/AI Security module also checks whether responses to model calls might inadvertently echo stored PII, a risk that spans both traditional APIs and AI-augmented services.

middleBrick connects these runtime findings to your OpenAPI/Swagger spec, resolving $ref definitions to verify whether declared responses match actual behavior. This helps teams see whether PII appears in documented schemas and prioritize fixes. The scanner’s remediation guidance recommends applying field-level filters, using projection expressions in DynamoDB, and validating input IDs against access control rules. By testing unauthenticated paths, middleBrick shows what an attacker can observe without credentials, emphasizing the need for explicit authorization and output sanitization rather than relying on network-level obscurity.

To prevent PII leakage when Fiber reads from DynamoDB, apply strict field selection and redaction in the service layer. Use DynamoDB’s projection capabilities to retrieve only required attributes, and map them to a response struct that excludes sensitive fields. The following example demonstrates a secure pattern using the AWS SDK for Go with Fiber, where a profile endpoint returns a limited set of safe attributes.

//go:generate mockgen -source=handler.go -destination=mocks/handler.go
package main

import (
	"context"
	"encoding/json"
	"net/http"

	"github.com/gofiber/fiber/v2"
	"github.com/aws/aws-sdk-go-v2/service/dynamodb"
	"github.com/aws/aws-sdk-go-v2/service/dynamodb/types"
)

type UserProfile struct {
	UserID   string `json:"userId"`
	Name     string `json:"name"`
	Email    string `json:"email"`
	Username string `json:"username"`
}

func GetProfile(db *dynamodb.Client, tableName string) fiber.Handler {
	return func(c *fiber.Ctx) error {
		userID := c.Params("userID")
		if userID == "" {
			return c.Status(http.StatusBadRequest).JSON(fiber.Map{"error": "missing userID"})
		}

		out, err := db.GetItem(c.Context(), &dynamodb.GetItemInput{
			TableName: aws.String(tableName),
			Key: map[string]types.AttributeValue{
				"userID": &types.AttributeValueMemberS{Value: userID},
			},
			ProjectionExpression: aws.String("userID, name, email, username"), // restrict attributes
		})
		if err != nil {
			return c.Status(http.StatusInternalServerError).JSON(fiber.Map{"error": err.Error()})
		}
		if out.Item == nil {
			return c.SendStatus(http.StatusNotFound)
		}

		profile := UserProfile{
			UserID:   *out.Item["userID"].(*types.AttributeValueMemberS).Value,
			Name:     *out.Item["name"].(*types.AttributeValueMemberS).Value,
			Email:    *out.Item["email"].(*types.AttributeValueMemberS).Value,
			Username: *out.Item["username"].(*types.AttributeValueMemberS).Value,
		}

		return c.JSON(profile)
	}
}

In this example, the ProjectionExpression ensures that only selected attributes are retrieved from DynamoDB, reducing the surface for accidental PII exposure. The response struct omits fields such as ssn or internalRole even if they exist in the table, preventing leakage through overly broad deserialization. For queries that return multiple items, apply the same principle by using FilterExpression on the client side only as a convenience; server-side projection with ProjectionExpression is the stronger control because it limits data at the source.

Additionally, enforce authorization before invoking DynamoDB. Validate that the requesting user is allowed to view the target resource, for example by scoping the key condition to tenant or subject ownership. middleBrick’s BOLA checks will detect when endpoints expose other users’ data via predictable identifiers. Combine these practices with the CLI (middlebrick scan <url>) or GitHub Action to continuously verify that PII exposure regressions are caught before deployment. The MCP Server integration allows you to run these scans from within AI coding assistants, embedding security checks directly into development workflows.