Formula Injection in Buffalo with Firestore

Formula Injection occurs when untrusted user input is placed into formulas or expressions that are later evaluated by a downstream system. In a Buffalo application that uses Firestore as a backend, this typically happens when dynamic values such as document fields or query parameters are used to construct formulas for computed properties, spreadsheet exports, or report generation without proper validation or sanitization.

Buffalo does not inherently evaluate formulas, but it often coordinates with external services like Firestore to store and retrieve data. If a developer builds endpoints that accept user-controlled parameters (e.g., price, quantity, or discount) and then writes them into Firestore documents that later feed into a templating or calculation layer, the stage is set for Formula Injection. For example, storing a user-supplied string such as "=1+2" in a numeric field and later rendering it in a CSV or Excel export can cause spreadsheet applications to re-evaluate the injected expression, leading to unintended behavior or data leakage.

Firestore-specific risks arise when security rules are misconfigured or when client-side SDKs expose write paths that accept raw formula-like strings. An attacker may supply crafted input that, once stored, affects other users or downstream consumers. If the application later retrieves this data and embeds it into JavaScript templates or server-side report generators that interpret strings as formulas, execution of arbitrary calculations or exposure of sensitive context may occur. This is compounded when Firestore documents are shared across users or exported to systems that automatically evaluate expressions, such as Google Sheets integrations or internal analytics pipelines.

Consider a scenario where a Buffalo handler accepts JSON input to create a discount record:

// handlers/discounts.go
func CreateDiscount(c buffalo.Context) error {
    discount := &models.Discount{}
    if err := c.Bind(discount); err != nil {
        return errors.WithStack(err)
    }
    // Unsafe: storing user input directly into Firestore
    _, err := app.Firestore.Collection("discounts").Add(c.Request().Context(), discount.Data)
    if err != nil {
        return err
    }
    return c.Render(200, r.H{})
}

If discount.Data contains a map with a field like formula: "=A1*B1" provided by an attacker, and this document is later used in a reporting service that evaluates formulas, the injected expression could access unintended data or trigger side effects. Firestore security rules that do not validate the content of fields allow such data to be written, and the Buffalo application may inadvertently propagate the malicious payload to downstream consumers.

Because the scan tests unauthenticated attack surfaces, a middleBrick scan of a Buffalo + Firestore integration would flag exposed endpoints that accept and persist formula-like inputs without validation. Findings would include references to input validation failures and improper data exposure, aligned with OWASP API Top 10 and relevant compliance mappings. The scanner does not fix the issue but provides remediation guidance, emphasizing input sanitization, strict schema validation, and context-aware output encoding before any data reaches calculation or export layers.

Remediation focuses on strict input validation, schema enforcement, and safe data handling before any Firestore write. Avoid storing or evaluating raw formula strings supplied by users. Instead, parse and sanitize inputs on the server side and use Firestore security rules to enforce data integrity.

First, validate and transform user input in the Buffalo handler. Use a dedicated struct with custom validation methods to ensure only expected data types are accepted:

// models/discount.go
package models

type Discount struct {
    Value    float64 `json:"value" valid:"required,numeric"`
    Quantity int     `json:"quantity" valid:"required,min=1"`
    // Do not include raw formula fields from user input
}

// handlers/discounts.go
func CreateDiscount(c buffalo.Context) error {
    discount := &models.Discount{}
    if err := c.Bind(discount); err != nil {
        return errors.WithStack(err)
    }
    if err := discount.Validate(); err != nil {
        return err
    }
    // Compute server-side; do not accept formula strings from clients
    result := discount.Value * float64(discount.Quantity)
    doc := map[string]interface{}{
        "value":   discount.Value,
        "quantity": discount.Quantity,
        "result":  result,
    }
    _, err := app.Firestore.Collection("discounts").Add(c.Request().Context(), doc)
    if err != nil {
        return err
    }
    return c.Render(200, r.H{})
}

Second, enforce strict Firestore security rules to reject documents containing fields that resemble formulas. For numeric fields, use rules to ensure values are numbers and not strings that could encode expressions:

// firestore.rules
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /discounts/{document} {
      allow create: if request.resource.data.keys().hasAll(['value', 'quantity', 'result'])
        && request.resource.data.value is number
        && request.resource.data.quantity is int
        && request.resource.data.result is number
        && request.resource.data.value >= 0
        && request.resource.data.quantity >= 1;
      allow read: if true;
    }
  }
}

Third, if your application must support computed outputs, perform formula evaluation server-side using a controlled library rather than relying on client-supplied strings. For example, use Go’s govaluate package with a whitelisted set of allowed variables:

// services/calculation.go
package services

import (
    "github.com/Knetic/govaluate"
)

func EvaluateExpression(expression string, parameters map[string]interface{}) (interface{}, error) {
    // Whitelist allowed expressions or templates; reject raw user input
    allowedTemplates := map[string]string{
        "discount": "(value * quantity) - (value * discount_rate)",
    }
    tmpl, exists := allowedTemplates[expression]
    if !exists {
        return nil, errors.New("expression not allowed")
    }
    eval, err := govaluate.NewEvaluableExpression(tmpl)
    if err != nil {
        return nil, err
    }
    return eval.Evaluate(parameters)
}

Finally, audit exported data and templates to ensure that any field rendered in spreadsheets or reports is properly encoded or cast to a non-executable type. These steps reduce the risk of Formula Injection by constraining input sources, validating data shapes, and avoiding direct evaluation of user-controlled strings within Firestore-integrated Buffalo applications.