Cors Wildcard in Fiber with Dynamodb

A CORS wildcard (*) in a Fiber application that interacts with DynamoDB can unintentionally expose both data and control flow to origins that should not have access. When * is used in the Access-Control-Allow-Origin header while the backend also uses AWS SDK calls to DynamoDB, the browser allows any website to make authenticated requests on behalf of a user and to inspect responses that contain DynamoDB-derived data.

This becomes particularly dangerous when credentials or tokens are included in requests. The wildcard allows a malicious site to invoke endpoints that query or modify DynamoDB resources, potentially leveraging the authenticated user’s permissions. Since CORS is a browser-enforced mechanism, server-side logic must not rely on it for authorization; a wildcard in this context effectively delegates origin decisions to the client, which is unsafe when combined with sensitive DynamoDB operations.

For example, consider an endpoint that retrieves user profile data from a DynamoDB table and returns it as JSON. With a wildcard CORS policy, any site can send a request and read the returned items, even if the data includes PII or internal identifiers. If the endpoint also performs write operations based on request parameters, the wildcard enables unauthorized mutation of DynamoDB items, leading to data corruption or privilege escalation.

In addition, preflight requests (OPTIONS) with a wildcard can reveal which headers and methods are accepted, aiding reconnaissance. When combined with misconfigured IAM policies for DynamoDB, an attacker might leverage overly permissive CORS to probe for writable tables or sensitive attributes, increasing the attack surface exposed by the API.

Remediation focuses on replacing the wildcard with an explicit allowlist of origins and ensuring that authorization checks are performed independently of CORS. Below are concrete Fiber examples using the github.com/gofiber/fiber/v2 package and the AWS SDK for Go v2 to interact with DynamoDB.

First, configure CORS to specify exact origins instead of *:

import (
	"github.com/gofiber/fiber/v2"
	"github.com/gofiber/fiber/v2/middleware/cors"
)

func main() {
	app := fiber.New()

	cfg := cors.Config{
		AllowOrigins:     "https://trusted.example.com,https://app.example.com",
		AllowHeaders:     "Content-Type,Authorization",
		AllowMethods:     "GET,POST,PUT,DELETE,OPTIONS",
		ExposeHeaders:    "X-Total-Count,Authorization-Error",
		AllowCredentials: true,
	}

	app.Use(cors.New(cfg))

	app.Get("/profile/:userID", func(c *fiber.Ctx) error {
		userID := c.Params("userID")
		// DynamoDB call follows
		return getProfile(c, userID)
	})

	app.Listen(":3000")
}

Second, implement per-request authorization and use the AWS SDK to query DynamoDB with condition expressions to enforce ownership and permissions:

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

func getProfile(c *fiber.Ctx, userID string) error {
	cfg, err := config.LoadDefaultConfig(c.Context(), config.WithRegion("us-east-1"))
	if err != nil {
		return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "unable to load AWS config"})
	}

	client := dynamodb.NewFromConfig(cfg)

	// Enforce ownership and authorization at the database level
	input := &dynamodb.GetItemInput{
		TableName: aws.String("Users"),
		Key: map[string]types.AttributeValue{
			"user_id": &types.AttributeValueMemberS{Value: userID},
		},
		// Use a filter expression to ensure only allowed attributes are returned
		ProjectionExpression: aws.String("user_id,display_name,email_verified"),
	}

	output, err := client.GetItem(c.Context(), input)
	if err != nil {
		return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "failed to retrieve profile"})
	}

	if output.Item == nil {
		return c.Status(fiber.StatusNotFound).JSON(fiber.Map{"error": "profile not found"})
	}

	return c.JSON(output.Item)
}

These patterns ensure that CORS does not act as an authorization layer and that DynamoDB interactions respect application-level permissions. For production use, pair this with authenticated sessions and scoped IAM roles to further reduce risk when serving requests from specific origins.