Replay Attack in Echo Go with Api Keys

A replay attack in the Echo Go context with API keys occurs when an attacker intercepts a valid request—typically containing a static API key in a header—and re-sends it to the API to reproduce the original effect. Because API keys are often long-lived credentials transmitted with each request, they do not inherently prevent replay unless additional protections are applied. In Echo Go, if requests rely only on the API key for identification and lack a mechanism to guarantee uniqueness per interaction, an attacker can capture a signed request (for example, an HTTP POST that modifies state or initiates a transaction) and replay it at a later time. This is especially relevant when the API uses a simple header like X-API-Key without a nonce, timestamp, or request hash, and when the server processes the same keyed request identically whether it was seen before.

Echo Go endpoints that accept API keys over HTTP without transport layer protections, or where the key is logged or stored insecurely, increase exposure. If the API does not enforce strict idempotency controls or server-side one-time-use tracking, the intercepted request can be replayed with identical parameters, potentially leading to duplicate operations, unauthorized data access, or privilege escalation depending on the endpoint semantics. The risk is compounded when API keys have broad permissions and are not scoped with short lifetimes or when TLS is not strictly enforced, allowing passive network observers to harvest the credentials. Therefore, the combination of static API keys, lack of request uniqueness mechanisms, and insufficient server-side validation creates a viable replay surface that an attacker can exploit by simply re-sending captured traffic.

To mitigate replay risks while continuing to use API keys in Echo Go, introduce per-request uniqueness and server-side validation so that captured requests cannot be reused. Below are concrete remediation patterns and code examples.

1. Include a nonce and timestamp in the request

Have the client generate a random nonce and a current timestamp, include them in the headers, and have the server ensure freshness and uniqueness. This prevents identical requests from being accepted more than once within an acceptable time window.

// Client-side example in Go
package main

import (
	"crypto/rand"
	"encoding/hex"
	"fmt"
	"net/http"
	"time"
)

func buildRequest(url, apiKey string) (*http.Request, error) {
	// Generate a random nonce
	nonce := make([]byte, 16)
	if _, err := rand.Read(nonce); err != nil {
		return nil, err
	}
	// Current Unix timestamp in seconds
	now := time.Now().Unix()

	req, err := http.NewRequest("POST", url, nil)
	if err != nil {
		return nil, err
	}
	req.Header.Set("X-API-Key", apiKey)
	req.Header.Set("X-Nonce", hex.EncodeToString(nonce))
	req.Header.Set("X-Timestamp", fmt.Sprintf("%d", now))
	// Important: include a deterministic signature if you add a payload
	return req, nil
}

2. Server-side replay protection in Echo Go

On the server, validate the timestamp for freshness and ensure nonces are not reused for the lifetime of the key. Store recently seen nonces temporarily (e.g., in-memory cache with TTL) and reject requests with stale timestamps or duplicated nonces.

// Server-side handler sketch in Go using Echo
package main

import (
	"net/http"
	"strconv"
	"time"

	"github.com/labstack/echo/v4"
)

const nonceCacheSize = 10000
const timeSkewSeconds = 300 // allow 5 minutes clock skew

var seenNonces = make(map[string]bool) // in production, use a concurrent cache with TTL

func isReplay(c echo.Context, apiKey, nonce string, ts int64) bool {
	// Check timestamp freshness
	if time.Now().Unix()-ts > timeSkewSeconds || ts-time.Now().Unix() > timeSkewSeconds {
		return true
	}
	// Check nonce uniqueness
	if seenNonces[nonce] {
		return true
	}
	// Basic scope check: in real code you would look up key metadata
	if apiKey == "" {
		return true
	}
	seenNonces[nonce] = true
	return false
}

func handleAction(c echo.Context) error {
	apiKey := c.Request().Header.Get("X-API-Key")
	rawNonce := c.Request().Header.Get("X-Nonce")
	ts, err := strconv.ParseInt(c.Request().Header.Get("X-Timestamp"), 10, 64)
	if err != nil {
		return c.JSON(http.StatusBadRequest, map[string]string{"error": "invalid timestamp"})
	}
	if isReplay(c, apiKey, rawNonce, ts) {
		return c.JSON(http.StatusForbidden, map[string]string{"error": "rejected as potential replay"})
	}
	// Proceed with the action
	return c.JSON(http.StatusOK, map[string]string{"status": "ok"})
}

3. Short-lived keys and binding

Where feasible, use short-lived API keys or key rotation so that captured credentials expire quickly. Bind keys to specific client attributes (e.g., IP or TLS certificate hashes) to reduce the window for successful replay across different contexts.

// Example of key metadata structure (not runtime enforcement)
type APIKey struct {
	Key          string    `json:"key"`
	Scopes       []string  `json:"scopes"`
	ExpiresAt    time.Time `json:"expires_at"`
	AllowedIPs   []string  `json:"allowed_ips"`
}

4. Enforce TLS and avoid logging sensitive headers

Ensure all requests use HTTPS to prevent passive sniffing of API keys. Avoid logging full API key or sensitive headers in access logs to reduce accidental exposure and potential replay vectors derived from log leaks.

By combining unique per-request nonces, timestamp validation, short key lifetimes, and strict HTTPS, you significantly reduce the replay surface for API keys in Echo Go without changing the fundamental use of API keys as credentials.