Open Redirect in Echo Go with Dynamodb

An Open Redirect in an Echo Go service that uses DynamoDB typically arises when a handler accepts a user-supplied URL or location target and performs an HTTP redirect without strict validation. If the handler also interacts with DynamoDB—for example, to look up tenant or campaign data that includes redirect URIs—the risk is compounded: an attacker can poison stored redirect configurations or leverage reflected parameters to craft malicious flows.

Consider an Echo Go handler that reads a redirect_uri from a query parameter and optionally fetches a registered callback URL from a DynamoDB table keyed by client_id. If the redirect_uri is not validated against an allowlist or strict pattern, an attacker can supply a malicious external URL. Even if the stored value in DynamoDB is trusted, insufficient validation on the runtime parameter enables the redirect to be overridden. This becomes a stored or second-order Open Redirect if the attacker can inject a malicious URI into DynamoDB through another vector (such as a compromised admin interface or an insecure import/export process).

In the context of middleBrick’s 12 security checks, an unauthenticated scan can detect patterns such as HTTP 3xx responses with a Location header derived from user input, combined with DynamoDB read activity. Because the scan tests the unauthenticated attack surface, it does not require credentials and can surface risky redirect logic that depends on DynamoDB lookups. The presence of DynamoDB does not introduce the redirect flaw by itself, but it can provide a persistence layer that makes the impact more severe, enabling phishing or token theft via trusted-looking domains.

Real-world parallels include findings mapped to OWASP API Top 10 A05:2023 (Security Misconfiguration) and A03:2023 (Injection), where untrusted inputs lead to unintended execution paths. An attacker may chain a vulnerable redirect with SSRF or credential-phishing payloads, especially if the Echo Go service is part of a broader microservice workflow that includes DynamoDB-based session or token storage.

Remediation focuses on two areas: strict validation of redirect targets and safe DynamoDB access patterns. Never use raw user input for Location headers. Instead, maintain an allowlist of domains or use a pre-approved mapping stored in DynamoDB that is keyed by an internal identifier rather than a raw URL.

Example: safe redirect handler in Echo Go that uses a DynamoDB client to fetch allowed redirect URIs by an internal ID, with strict pattern checks and no direct reflection of user-supplied URLs.

// handler.go
package main

import (
	"context"
	"fmt"
	"net/http"
	"regexp"

	"github.com/labstack/echo/v4"
	"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/types"
)

var allowedDomains = map[string]bool{
	"https://app.example.com": true,
	"https://dashboard.example.com": true,
}

var re = regexp.MustCompile(`^https?://[a-z0-9\-]+\.example\.com(/.*)?$`)

type RedirectService struct {
	client *dynamodb.Client
	table  string
}

func NewRedirectService() *RedirectService {
	cfg, _ := config.LoadDefaultConfig(context.TODO())
	return &RedirectService{
		client: dynamodb.NewFromConfig(cfg),
		table:  "RedirectConfig",
	}
}

func (s *RedirectService) GetAllowedRedirect(ctx context.Context, key string) (string, error) {
	out, err := s.client.GetItem(ctx, &dynamodb.GetItemInput{
		TableName: aws.String(s.table),
		Key: map[string]types.AttributeValue{
			"ID": &types.AttributeValueMemberS{Value: key},
		},
	})
	if err != nil {
		return "", err
	}
	if out.Item == nil {
		return "", fmt.Errorf("not found")
	}
	urlAttr, ok := out.Item["RedirectURL"]
	if !ok {
		return "", fmt.Errorf("no url")
	}
	return aws.ToString(urlAttr), nil
}

func SafeRedirect(c echo.Context) error {
	service := c.Get("redirectService").(*RedirectService)
	key := c.Param("id")
	url, err := service.GetAllowedRedirect(c.Request().Context(), key)
	if err != nil || !re.MatchString(url) || !allowedDomains[url] {
		return c.String(http.StatusBadRequest, "invalid redirect target")
	}
	return c.Redirect(http.StatusFound, url)
}

Key points: the DynamoDB lookup uses a keyed ID instead of raw user input; the retrieved URL is validated against a strict regex and an allowlist of domains before issuing a 302. This prevents open redirect regardless of what is stored in DynamoDB, and it aligns with remediation guidance that emphasizes input validation and least privilege.

Additionally, ensure that any write path to DynamoDB (such as admin configuration updates) validates and sanitizes URIs, uses IAM policies with minimal permissions, and logs changes. middleBrick’s CLI can be used to scan the endpoint and confirm that no unvalidated redirects remain by running: middlebrick scan <url>. The dashboard and GitHub Action integrations can then track this security score over time and fail builds if risky patterns are detected.