Open Redirect in Echo Go with Firestore

An open redirect occurs when an application redirects a user to an arbitrary URL without proper validation. In Echo Go, if a handler accepts a URL or host parameter and passes it directly to Redirect or Location without validating the destination, attackers can craft phishing links that abuse your domain. When Firestore is used to store configuration such as allowed redirect URIs, tenant-specific domains, or feature flags, insecure retrieval or overly permissive Firestore rules can inadvertently expose redirect targets or allow an attacker to modify stored URLs.

Consider an Echo Go handler that reads a redirect target from Firestore based on a path parameter. If the application trusts the Firestore document field as a safe destination and uses it in c.Redirect(http.StatusFound, redirectURL) without validating that the URL is relative or matches an allowlist, the Firestore value becomes the vector. A misconfigured Firestore rule that allows read access to authenticated (or even unauthenticated) users can let an attacker read or overwrite the redirect target. Even when Firestore enforces stricter rules, a server-side component that writes user-controlled input into Firestore without normalization or validation can store malicious URLs that later get served by the Echo Go app.

In practice, this maps to the OWASP API Top 10 A05:2023 — Security Misconfiguration and A03:2023 — Injection (via indirect data exfiltration through stored URLs). Firestore does not perform URL validation; it stores what your code writes. If your Echo Go service reads those values and uses them in redirects without canonicalization, host matching, or allowlisting, you expose users to phishing and session fixation. The risk is compounded when combined with weak authentication checks (BOLA/IDOR) that permit a user to read or update redirect settings they should not access.

middleBrick detects this pattern by scanning the unauthenticated attack surface of your Echo Go endpoints and cross-referencing Firestore-related findings from the OpenAPI spec (if provided) with runtime behavior. It flags insecure Firestore rules, missing host validation, and missing referrer or origin checks in redirects, providing severity-ranked remediation guidance mapped to compliance frameworks such as OWASP API Top 10 and SOC2.

Remediation focuses on strict validation of redirect targets, restricting Firestore data exposure, and ensuring server-side handling never directly trusts client-influenced values. Below are concrete patterns for Echo Go with Firestore.

1. Validate redirect targets with an allowlist

Never use raw Firestore fields as redirect URLs. Instead, map user-supplied keys to pre-approved paths or hosts.

package main

import (
	"net/http"
	"github.com/labstack/echo/v4"
)

var allowedRedirects = map[string]string{
	"dashboard": "https://app.example.com/dashboard",
	"profile":   "https://app.example.com/profile",
}

func redirectHandler(c echo.Context) error {
	key := c.Param("key")
	target, ok := allowedRedirects[key]
	if !ok {
		return c.String(http.StatusBadRequest, "invalid redirect")
	}
	return c.Redirect(http.StatusFound, target)
}

2. Use relative paths when possible

Redirecting within your own service is safest with relative URLs, avoiding host manipulation entirely.

func relativeRedirectHandler(c echo.Context) error {
	path := c.Param("path")
	// Ensure path is sanitized and does not contain // or external hosts
	return c.Redirect(http.StatusFound, "/"+path)
}

3. Secure Firestore access and rules

Configure Firestore rules to limit who can read or write redirect configuration. Avoid allowing client-side reads of redirect mappings unless necessary.

// Firestore security rules (conceptual)
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /redirects/{doc} {
      allow read: if request.auth != null && request.auth.token.role == "admin";
      allow write: if request.auth != null && request.auth.token.role == "admin";
    }
  }
}

4. Sanitize and normalize Firestore values before use

If you must store redirect targets in Firestore, validate and normalize them server-side before use. Use net/url to parse and restrict hosts.

import (
	"net/url"
)

func isValidRedirect(target string) bool {
	u, err := url.Parse(target)
	if err != nil {
		return false
	}
	// Allow only specific hosts
	return u.Host == "app.example.com"
}

5. Use environment-based configuration instead of Firestore for critical mappings

For production, prefer environment variables or secrets for redirect mappings, reducing Firestore as a runtime dependency for security-critical decisions.

Using the middleBrick CLI (middlebrick scan <url>) or GitHub Action helps verify that your endpoints do not expose raw Firestore fields in redirects and that your API spec reflects secure design. The MCP Server can integrate these checks into your IDE for early detection.