Server Side Template Injection in Fiber with Dynamodb

Server Side Template Injection (SSTI) occurs when user-controlled data is merged into a template and interpreted as code rather than literal content. In a Fiber application using Dynamodb as a data store, risk arises when application logic builds responses by interpolating DynamoDB results directly into a template engine (such as html/template) without proper escaping or sandboxing.

Consider a typical handler that fetches an item by an identifier provided by the client and renders it using Go’s html/template package:

// Example vulnerable pattern in a Fiber app
item := map[string]interface{}{
    "ID":   c.Params("id"),
    "Name": "{{.UserInput}}", // unsanitized data from DynamoDB or request
}
tmpl := template.Must(template.New("page").Parse(dynamoDBResultTemplate))
tmpl.Execute(c.Response().Body(), item)

If the data stored in DynamoDB includes template-like syntax (e.g., action directives or function calls), and the template is re-parsed or re-executed with broader context, the attacker can cause arbitrary code execution within the template’s execution context. Because DynamoDB does not validate content for template syntax, an attacker who can write or influence stored data (e.g., through an API endpoint that lacks strict input validation or authorization) can later trigger SSTI when that data is rendered.

The combination of Fiber’s flexible handler chaining and DynamoDB’s schemaless storage amplifies the impact: untrusted data can enter through multiple entry points (path parameters, query strings, request bodies, or cached DynamoDB records), be persisted, and later rendered in a template context where unsafe actions like function calls or field accesses are allowed. This can lead to information disclosure, remote code execution, or authentication bypass depending on the template engine’s capabilities and how the application uses the rendered output.

Because middleBrick scans unauthenticated attack surfaces and tests input validation and data exposure, it can surface SSTI risks where DynamoDB-sourced data reaches the template layer without adequate escaping, helping teams identify dangerous data flows before they are exploited.

Remediation focuses on strict input validation, output encoding, and avoiding direct concatenation of user or external data into executable template constructs. When working with DynamoDB results in Fiber, treat all data as untrusted and apply context-aware escaping based on where the data is used (HTML, URL, JavaScript).

1) Validate and sanitize data before storage and at render time

Ensure fields expected to be plain text are validated against a strict allowlist and escaped when rendered. For HTML contexts, use html/template’s automatic escaping:

import (
    "html/template"
    "github.com/gofiber/fiber/v2"
)

type Item struct {
    ID   string
    Name template.HTML // use template.HTML only when intentionally embedding trusted HTML
}

func getItem(c *fiber.Ctx) error {
    id := c.Params("id")
    // Assume fetchDynamoDBItem returns a validated Item
    item, err := fetchDynamoDBItem(id)
    if err != nil {
        return c.Status(fiber.StatusInternalServerError).SendString("error")
    }
    // Render with automatic escaping for HTML fields
    tmpl := template.Must(template.New("item").Parse(`
        <div>ID: {{.ID}}</div>
        <div>Name: {{.Name}}</div>
    `))
    return tmpl.Execute(c.Response().Body(), item)
}

2) Avoid storing or rendering executable template syntax in DynamoDB

Do not allow users to supply template directives that will be re-evaluated. If you must store rich content, store raw text and render it as plain text or encode to HTML entities:

import (
    "strings"
    "github.com/gofiber/fiber/v2"
)

func sanitizeAndStore(c *fiber.Ctx) error {
    raw := c.FormValue("content")
    // Reject or escape template-like constructs
    if strings.ContainsAny(raw, "{{") || strings.ContainsAny(raw, "{%") {
        return c.Status(fiber.StatusBadRequest).SendString("invalid content")
    }
    // Store plain text in DynamoDB; escape on output
    _, err := saveToDynamoDB(fiber.Map{"id": c.Params("id"), "content": raw})
    if err != nil {
        return c.Status(fiber.StatusInternalServerError).SendString("error")
    }
    return c.SendString("ok")
}

3) Use strict type assertions and context-aware escaping when consuming DynamoDB results

DynamoDB returns data as loosely typed attribute maps; enforce strict schemas and escape based on output context. For example, when generating URLs or JavaScript, use appropriate escaping functions, not raw string interpolation.

import (
    "net/url"
    "github.com/gofiber/fiber/v2"
)

func buildSafeRedirect(c *fiber.Ctx) error {
    id := c.Params("id")
    item, err := fetchDynamoDBItem(id)
    if err != nil {
        return err
    }
    // Assume item has a "redirectURL" field that should be a safe URL
    rawURL, ok := item["redirectURL"].(string)
    if !ok {
        return c.SendStatus(fiber.StatusBadRequest)
    }
    parsed, err := url.ParseRequestURI(rawURL)
    if err != nil || parsed.Scheme == "" || parsed.Host == "" {
        return c.SendStatus(fiber.StatusBadRequest)
    }
    // Use URL-escaped redirect
    safeURL := url.QueryEscape(parsed.String())
    return c.Redirect(safeURL, fiber.StatusFound)
}

These patterns reduce the attack surface by ensuring DynamoDB data is validated, stored as plain text, and escaped according to the output context, which aligns with how middleBrick flags SSTI and input validation issues in scans, providing prioritized findings and remediation guidance without claiming to automatically fix or block execution.