Formula Injection in Echo Go with Dynamodb

Formula Injection occurs when untrusted data is interpreted as a formula or expression by a downstream system. In an Echo Go service that uses DynamoDB, this typically happens when user-controlled input is used to construct DynamoDB ExpressionAttributeValues or ExpressionAttributeNames and then passed to a condition or projection that is evaluated by a client or helper layer rather than being safely parameterized by the DynamoDB API. Even though the official AWS SDK for Go sends requests as structured payloads, if the application builds dynamic filter expressions by string concatenation using user input, an attacker can supply values like =1+1 or =HYPERLINK("https://evil.com/") that shift behavior in client-side parsers, exported reports, or downstream integrations that later process the data.

With DynamoDB, the risk is often realized when scan or query operations produce results that are handed off to a templating engine, CSV exporter, or LLM output parser. For example, a Go handler might do fmt.Sprintf("FilterExpression: %s", userSupplied) to build an expression, which then allows an attacker to inject a formula that causes unexpected evaluation in consuming applications. Because DynamoDB itself does not evaluate formulas, the vulnerability is not in the database protocol but in how the application builds expressions and how downstream consumers interpret the returned data. An attacker may leverage this to manipulate numeric outputs, trigger errors in parsers, or steer data extraction toward sensitive fields.

In the context of middleBrick’s checks, an unauthenticated scan of an Echo Go endpoint that accepts input parameters used in DynamoDB query conditions can detect whether expression building is improperly concatenated. The LLM/AI Security checks may additionally probe for prompt injection if any part of the API response is forwarded to an LLM; a formula injected into a field that later becomes part of a system prompt can lead to prompt injection or data exfiltration. Therefore, the combination of Echo Go, DynamoDB, and improper expression construction creates a pathway where input validation and output handling must be hardened to prevent formula-driven logic manipulation.

Remediation focuses on strict separation of data and expression, using the SDK’s built-in expression builders and never interpolating user input into expression strings. Always use expression.Name for attribute names and expression.Value for values, and let the SDK handle parameterization. Below are concrete, working examples in Go using the AWS SDK for Go v2.

Safe Query with ExpressionAttributeNames and ExpressionAttributeValues

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/expression"
)

func getUserByStatus(ctx context.Context, tableName, status string) (*dynamodb.GetItemOutput, error) {
	cfg, err := config.LoadDefaultConfig(ctx)
	if err != nil {
		return nil, err
	}
	client := dynamodb.NewFromConfig(cfg)

	// Use expression builder to avoid string concatenation
	e := expression.NewBuilder().
		WithNames(expression.AttributeNames{"#st": "status"}).
		WithValues(expression.AttributeValues{"val": status}).
		Build()

	req := &dynamodb.GetItemInput{
		TableName: aws.String(tableName),
		Key: map[string]aws.AttributeValue{
			"id": &aws.AttributeValueMemberS{Value: "user123"},
		},
		FilterExpression:          e.Filter(),
		ExpressionAttributeNames:  e.Names(),
		ExpressionAttributeValues: e.Values(),
	}
	return client.GetItem(ctx, req)
}

Safe Scan with Condition and Reserved Words

func scanActiveUsers(ctx context.Context, tableName string) (*dynamodb.ScanOutput, error) {
	cfg, err := config.LoadDefaultConfig(ctx)
	if err != nil {
		return nil, err
	}
	client := dynamodb.NewFromConfig(cfg)

	// Build expression safely; status is a value, not part of the expression string
	filt := expression.Name("#active").Equal(expression.Value(true))
	e, err := expression.NewBuilder().
		WithNames(expression.AttributeNames{"#active": "active"}).
		WithValues(expression.AttributeValues{"active": true}).
		Build()
	if err != nil {
		return nil, err
	}

	req := &dynamodb.ScanInput{
		TableName:                 aws.String(tableName),
		FilterExpression:          filt,
		ExpressionAttributeNames:  e.Names(),
		ExpressionAttributeValues: e.Values(),
	}
	return client.Scan(ctx, req)
}

Remediation for Output Handling

Ensure that data returned from DynamoDB is not re-evaluated as formulas in downstream systems. In an Echo handler, avoid writing raw numeric or expression-like strings into contexts that may be consumed by templating or LLM calls. Use strict content-type responses and sanitize fields that may be interpreted as instructions.

func handler(c echo.Context) error {
	out, err := getUserByStatus(c.Request().Context(), "users", "active")
	if err != nil {
		return c.JSON(500, map[string]string{"error": "unable to load"})
	}
	// Do not forward raw expression-like fields to LLM or template engines
	return c.JSON(200, out.Item)
}

By using expression builders, avoiding string-based assembly, and controlling downstream consumption, an Echo Go service with DynamoDB can mitigate formula injection risks while preserving the flexibility of dynamic queries.