Cross Site Request Forgery in Fiber with Dynamodb

Cross Site Request Forgery (CSRF) in a Fiber-based service that uses DynamoDB can occur when application state and identity are conveyed via cookies or tokens without sufficient anti-CSRF protections, and where DynamoDB operations are invoked directly from endpoints that do not validate the request origin. In such setups, an authenticated user’s browser may be tricked into issuing state-changing requests to the Fiber server, and those requests can result in DynamoDB writes if the server does not verify intent.

Consider a Fiber endpoint that updates a user’s profile by directly using a request body to build a DynamoDB UpdateItem input. If the endpoint relies only on session cookies for authentication and does not enforce same-site cookie attributes, anti-CSRF tokens, or strict origin checks, an attacker can craft a malicious site that triggers these updates on behalf of the victim. Because DynamoDB does not enforce per-request origin checks, the requests succeed if the user’s credentials are valid, leading to unauthorized updates (e.g., email, role, or preferences) stored in DynamoDB.

Another common pattern is using Lambda-backed HTTP APIs or middleware in Fiber that assumes requests from a trusted source are safe. However, if the API accepts query parameters or headers that map directly to DynamoDB condition expressions or update paths without rigorous validation, a forged request can manipulate these values. For instance, an attacker may supply crafted JSON or form values that change the Key or UpdateExpression, causing DynamoDB to modify records the user should not be allowed to touch. This risk is especially pronounced when the application embodies the insecure direct object reference (BOLA/IDOR) alongside CSRF, enabling attackers to target specific items by manipulating identifiers in the request.

Because DynamoDB is often used as a primary persistence layer, the impact of a successful CSRF attack can include data modification, privilege escalation, or changes to user settings that persist across sessions. The CSRF vector is not introduced by DynamoDB itself, but by how the Fiber application integrates with it—specifically, missing origin verification, missing anti-CSRF tokens, and overly permissive update construction. Scanning with middleBrick can surface such integration risks in the Authentication and BOLA/IDOR checks, highlighting endpoints where state-changing operations are not adequately isolated from forged requests.

To mitigate CSRF in Fiber applications that interact with DynamoDB, implement defense-in-depth measures: enforce same-site and secure cookie attributes, use anti-CSRF tokens for state-changing operations, validate and sanitize all inputs before constructing DynamoDB requests, and apply the principle of least privilege to AWS credentials and IAM policies.

1. Set secure cookies and enable CSRF tokens in Fiber

Ensure session cookies are marked SameSite=Lax or SameSite=Strict and Secure. For endpoints that perform writes, require a validated anti-CSRF token in a header or form field rather than relying solely on cookies.

// Fiber middleware to set secure cookies
app.Use("/*", func(c *fiber.Ctx) error {
    cookie := new(fiber.Cookie)
    cookie.Key = "session"
    cookie.Value = generateSessionToken()
    cookie.Expires = time.Now().Add(24 * time.Hour)
    cookie.Secure = true
    cookie.SameSite = fiber.CookieSameSiteLax
    cookie.HTTPOnly = true
    return c.Cookie(cookie)
})

// Example endpoint requiring CSRF token in header
app.Post("/profile/update", func(c *fiber.Ctx) error {
    token := c.Get("X-CSRF-Token")
    if token != validCSRFTokenFromSession(c) {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid csrf token"})
    }
    // proceed to DynamoDB update
    return nil
})

2. Validate input and construct safe DynamoDB updates

Never directly map request fields into DynamoDB UpdateExpression or ConditionExpression. Whitelist allowed fields, validate types, and use expression attribute names/values safely to avoid injection and unintended updates.

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

app.Put("/users/:userID", func(c *fiber.Ctx) error {
    userID := c.Params("userID")
    type UpdateRequest struct {
        Email string `json:"email" validate:"email"`
        Theme string `json:"theme" validate:"one=light|dark"`
    }
    var req UpdateRequest
    if err := c.BodyParser(&req); err != nil {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": err.Error()})
    }
    // Validate input explicitly; map only allowed fields to DynamoDB updates
    updateInput := &dynamodb.UpdateItemInput{
        TableName: aws.String("Users"),
        Key: map[string]*dynamodb.AttributeValue{
            "userID": {S: aws.String(userID)},
        },
        UpdateExpression: aws.String("SET #email = :email, #theme = :theme"),
        ExpressionAttributeNames: map[string]*string{
            "#email": aws.String("email"),
            "#theme": aws.String("theme"),
        },
        ExpressionAttributeValues: map[string]*dynamodb.AttributeValue{
            ":email": {S: req.Email},
            ":theme": {S: req.Theme},
        },
        ConditionExpression: nil, // use cautiously; ensure it does not over-restrict
    }
    _, err := dynamoClient.UpdateItem(updateInput)
    if err != nil {
        return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": err.Error()})
    }
    return c.SendStatus(fiber.StatusOK)
})

3. Apply least-privilege IAM and avoid broad permissions

Ensure the AWS credentials used by Fiber have DynamoDB permissions limited to the specific actions and resources required. Avoid using administrative policies for routine application operations.

// IAM policy example (conceptual) for the app
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:UpdateItem",
                "dynamodb:GetItem"
            ],
            "Resource": "arn:aws:dynamodb:region:account:table/Users"
        }
    ]
}

By combining secure cookie settings, explicit CSRF token validation, strict input validation, and least-privilege IAM, you reduce the likelihood that a forged request can safely execute unintended DynamoDB operations from a Fiber service.