Unicode Normalization in Fiber

Unicode normalization attacks in Fiber applications often exploit the framework's handling of internationalized input. When users submit data through Fiber's HTTP handlers, the framework processes request bodies and query parameters without automatic Unicode normalization. This creates opportunities for attackers to submit visually identical but technically different Unicode representations.

Consider a password reset endpoint in Fiber. An attacker could submit a username with precomposed characters (NFC) while the database stores the same username in decomposed form (NFD). Fiber's router will match the route correctly, but the string comparison for authentication fails because the underlying byte sequences differ. This creates a bypass scenario where the application logic breaks down due to inconsistent Unicode handling.

Another manifestation occurs in URL path traversal attacks. Fiber's router processes path parameters, but if an application later uses these parameters for file operations without normalization, attackers can craft paths using combining characters. For example, submitting "/../../etc/passwd́" (with a combining acute accent) might bypass simple string-based filtering that only checks for the literal "/../../" sequence.

API endpoints that accept international usernames or email addresses are particularly vulnerable. A Fiber application might validate that a username exists in the database, but if the validation compares the raw input against stored values without normalization, legitimate users could be denied access while attackers find working variations of their target's identifier.

The issue becomes more severe when Fiber applications interface with external systems. If your Fiber API passes user input to a database, another microservice, or cloud storage without normalization, you create inconsistencies that can be exploited across system boundaries. An attacker who discovers that your application stores usernames in NFD form can craft NFC inputs that bypass authentication checks but still reference the correct database records when the application internally normalizes before querying.

Detecting Unicode normalization issues in Fiber applications requires examining how the framework handles request data throughout the request lifecycle. Start by instrumenting your Fiber application to log the raw byte representation of incoming strings. This reveals whether your application is receiving precomposed or decomposed Unicode forms.

middleBrick's scanner specifically tests for Unicode normalization vulnerabilities in Fiber applications by submitting inputs with known Unicode variations and observing how the application responds. The scanner tests both NFC and NFD forms of common characters, checking whether authentication, authorization, and data retrieval behave consistently across these variations.

For manual detection, create test cases that submit the same logical string in different Unicode normal forms to your Fiber endpoints. Use Go's golang.org/x/text/unicode/norm package to generate these variations. Test authentication endpoints by submitting usernames and passwords with different normal forms, then observe whether the application treats them as identical or distinct entities.

Examine your Fiber middleware chain for any processing that might alter Unicode data. Check how your JSON parsers, form handlers, and query parameter extractors handle international characters. Look for places where Fiber's c.Get, c.PostForm, or c.Bind methods return strings that are later used for critical operations without normalization.

middleBrick's API security scanner can automatically detect these issues by testing unauthenticated endpoints with Unicode variations and analyzing whether the application's responses indicate inconsistent handling. The scanner checks for authentication bypasses, data exposure through path traversal, and injection vulnerabilities that exploit Unicode differences.

Monitor your application logs for unusual character patterns or errors related to string processing. Unicode normalization issues often manifest as sporadic authentication failures or data retrieval problems that only occur with specific international character sets.

The most effective remediation for Unicode normalization in Fiber applications is to normalize all incoming request data to a consistent form immediately upon receipt. The Go standard library provides golang.org/x/text/unicode/norm for this purpose. Create a middleware that normalizes all string inputs before they reach your handlers.

package middleware

import (
    "github.com/gofiber/fiber/v2"
    "golang.org/x/text/unicode/norm"
)

func UnicodeNormalizationMiddleware() fiber.Handler {
    return func(c *fiber.Ctx) error {
        // Normalize query parameters
        for key, values := range c.Query() {
            for i, value := range values {
                c.Query()[key][i] = string(norm.NFC.Bytes([]byte(value)))
            }
        }

        // Normalize JSON body if present
        if c.Context().Request().Header.ContentType() == "application/json" {
            var body map[string]interface{}
            if err := c.BodyParser(&body); err == nil {
                normalizeMap(body)
                c.Locals("normalizedBody", body)
            }
        }

        // Normalize form data
        if c.Context().Request().Header.ContentType() == "application/x-www-form-urlencoded" {
            form := c.Context().Form
            for key, values := range form {
                for i, value := range values {
                    form[key][i] = string(norm.NFC.Bytes([]byte(value)))
                }
            }
        }

        return c.Next()
    }
}

func normalizeMap(data map[string]interface{}) {
    for key, value := range data {
        switch v := value.(type) {
        case string:
            data[key] = string(norm.NFC.Bytes([]byte(v)))
        case map[string]interface{}:
            normalizeMap(v)
        }
    }
}

Apply this middleware globally in your Fiber application to ensure consistent Unicode handling across all endpoints:

import "github.com/yourapp/middleware"

app := fiber.New()
app.Use(middleware.UnicodeNormalizationMiddleware())

For authentication specifically, always normalize both the input and the stored value before comparison. When querying databases for user records, normalize the search criteria to match the storage format, or better yet, store all usernames in a normalized form.

When dealing with file paths or URLs, apply additional validation beyond normalization. Use Go's path.Clean function to resolve relative path components, and validate that normalized paths don't escape intended directories. This prevents both Unicode-based and traditional path traversal attacks.

Consider implementing a security scanning step in your CI/CD pipeline using middleBrick's CLI tool. Add a check that scans your Fiber API endpoints for Unicode normalization vulnerabilities before deployment:

# Install middleBrick CLI
npm install -g middlebrick

# Scan your Fiber API
middlebrick scan https://yourapi.com

# Check the security score and findings

For applications that must handle multiple Unicode normal forms (such as when interfacing with external systems that have different requirements), document the normalization strategy clearly and apply it consistently throughout your codebase. Use constants or configuration to define the normalization form (NFC is typically recommended for web applications) and enforce it through code review and automated testing.