Session Fixation in Fiber with Dynamodb

Session fixation occurs when an application assigns a user a session identifier before authentication and does not regenerate that identifier after login. In a Go Fiber application that stores session data in DynamoDB, this can happen if session IDs are created on initial visit (or via a predictable pattern) and then reused after the user authenticates. Because DynamoDB is often used as a session store with a structure like sessionID → userID + metadata, an attacker who can set or guess a session ID can force a victim to use that ID. After the victim logs in, the same ID now maps to an authenticated user, allowing the attacker to hijack the session by presenting the known ID.

With DynamoDB, the risk is amplified if session records are not properly invalidated or if the application relies on client-side cookies without server-side rotation. For example, if the application sets a cookie named session_id on the first request and uses that value as a key to read/write items in a sessions DynamoDB table, an attacker can craft a link with a known session_id. When the victim authenticates, the item keyed by that session_id is updated with authenticated claims. Because the attacker knows the session_id in advance, they can reuse the cookie value after authentication to act as the victim. MiddleBrick scans would flag this as BOLA/IDOR and Authentication issues when session IDs are predictable or not rotated post-login, especially when DynamoDB items are not scoped with per-user randomness.

OpenAPI/Swagger analysis can help uncover this if session management endpoints are documented but lack security schemes that enforce session rotation. Since DynamoDB is often used for its scalability, developers might overlook the need to couple strong session lifecycle controls with the storage layer. Without regenerating the session ID on authentication and binding it tightly to the authenticated subject, the DynamoDB table effectively becomes a repository of predictable session tokens, making fixation straightforward. MiddleBrick’s checks for unsafe consumption and authentication will highlight missing session regeneration steps and insufficient validation of session ownership when reading from DynamoDB.

To remediate session fixation in Fiber with DynamoDB, regenerate the session identifier after successful authentication and ensure server-side binding between the session key and the authenticated user. Below is a concrete example using the AWS SDK for Go v2, with DynamoDB as the session store.

// Session record stored in DynamoDB
type Session struct {
    SessionID string `json:"session_id"`
    UserID    string `json:"user_id"`
    ExpiresAt int64  `json:"expires_at"`
    CSRF      string `json:"csrf"`
}

// After successful login, create a new session ID and write to DynamoDB
func createSessionAfterLogin(userID string, dynamoClient *dynamodb.Client, table string) (string, error) {
    newSessionID := uuid.NewString() // cryptographically random
    item, err := dynamodb.MarshalMap(Session{
        SessionID: newSessionID,
        UserID:    userID,
        ExpiresAt: time.Now().Add(24 * time.Hour).Unix(),
        CSRF:      uuid.NewString(),
    })
    if err != nil {
        return "", err
    }
    _, err = dynamoClient.PutItem(context.TODO(), &dynamodb.PutItemInput{
        TableName: aws.String(table),
        Item:      item,
    })
    if err != nil {
        return "", err
    }
    return newSessionID, nil
}

// Invalidate the old session after authentication
func invalidateSession(sessionID string, dynamoClient *dynamodb.Client, table string) error {
    _, err := dynamoClient.DeleteItem(context.TODO(), &dynamodb.DeleteItemInput{
        TableName: aws.String(table),
        Key: map[string]attribute.Value{
            "session_id": attribute.ValueOf(sessionID),
        },
    })
    return err
}

In your Fiber handler, call createSessionAfterLogin upon successful credentials verification, set the new session ID in a secure, HttpOnly cookie, and immediately invalidate the pre-authentication session ID. This ensures that even if an attacker forced a session ID, it no longer maps to a valid authenticated item in DynamoDB after login. Combine this with strict SameSite and Secure cookie attributes and server-side validation on each request that reads the session from DynamoDB to confirm ownership and freshness.

MiddleBrick’s scans can validate that your API endpoints enforce session rotation and that DynamoDB session records are not reused across authentication events. The CLI tool (middlebrick scan ) can be integrated into your workflow to detect missing regeneration patterns and BOLA/IDOR risks tied to DynamoDB-backed sessions. For teams needing deeper enforcement, the Pro plan adds continuous monitoring to alert when session management deviations appear, and the GitHub Action can fail builds if risk thresholds are not met before deployment.