Missing Tls in Echo Go with Dynamodb

When an Echo Go service communicates with DynamoDB without enforcing Transport Layer Security (TLS), credentials, query parameters, and data payloads can traverse the network in cleartext. This typically occurs when the AWS SDK is configured with an endpoint that uses http:// instead of https://, or when custom HTTP clients skip TLS verification. An attacker who can observe or tamper with network traffic—such as on shared WiFi, compromised routers, or misconfigured VPC peering—may capture AWS signature components, session tokens, or sensitive item attributes.

Echo Go applications often expose this risk when developers use the AWS SDK for Go v2 with a custom http.Client or override the default resolver without enforcing TLS. For example, if the service uses aws.Config with an explicitly set HTTP client that disables tls.Config verification or uses an HTTP-only endpoint, the SDK will send requests without encryption. DynamoDB does not require TLS by default in such misconfigurations, allowing network observers to intercept GetItem, Query, or Scan requests. This can lead to exposure of IAM role credentials embedded in the application, primary key values, and potentially sensitive item attributes, which may map to findings in Data Exposure and Encryption checks in middleBrick scans.

In a middleBlack scan, Missing TLS would appear under the Encryption and Data Exposure categories, with severity correlated to the sensitivity of data transacted. Findings would include references to insecure endpoint configurations and unencrypted communication paths, mapped to OWASP API Security Top 10 and relevant compliance frameworks. The presence of TLS enforcement does not remediate other issues such as over-privileged IAM policies, but it is a necessary control to protect data in transit between the Echo Go service and DynamoDB.

Remediation focuses on ensuring all DynamoDB calls from an Echo Go service use TLS-encrypted endpoints and validate server certificates. The AWS SDK for Go v2 respects the EndpointResolver and Transport configuration in aws.Config. Below are concrete, working examples that enforce HTTPS and preserve expected SDK behavior.

The simplest and recommended approach is to rely on the SDK defaults, which use HTTPS for AWS public endpoints. Do not override the HTTP client in a way that disables TLS verification.

// Correct: default HTTPS endpoint with standard TLS verification
package main

import (
	"github.com/aws/aws-sdk-go-v2/config"
	"github.com/aws/aws-sdk-go-v2/service/dynamodb"
	"github.com/labstack/echo/v4"
)

func main() {
	e := echo.New()

	// Load SDK configuration from environment, shared config, or IAM role
	cfg, err := config.LoadDefaultConfig(e.Logger) // region from env or AWS_PROFILE
	if err != nil {
		e.Logger.Fatal("failed to load AWS config:", err)
	}

	// Create DynamoDB client with default HTTPS endpoint
	dbClient := dynamodb.NewFromConfig(cfg)

	// Example handler that safely queries DynamoDB
	e.GET("/items/:id", func(c echo.Context) error {
		id := c.Param("id")
		input := &dynamodb.GetItemInput{
			TableName: aws.String("ItemsTable"),
			Key: map[string]types.AttributeValue{
				"PK": &types.AttributeValueMemberS{Value: id},
			},
		}
		result, err := dbClient.GetItem(c.Request().Context(), input)
		if err != nil {
			return c.JSON(500, map[string]string{"error": err.Error()})
		}
		return c.JSON(200, result.Item)
	})

	e.Logger.Fatal(e.Start(":8080"))
}

If you must use a custom endpoint (e.g., DynamoDB Local or a proxy), explicitly configure TLS with certificate verification instead of disabling it.

// Correct: custom HTTPS endpoint with enforced TLS verification
package main

import (
	"crypto/tls"
	"github.com/aws/aws-sdk-go-v2/aws"
	"github.com/aws/aws-sdk-go-v2/config"
	"github.com/aws/aws-sdk-go-v2/credentials/stscreds"
	"github.com/aws/aws-sdk-go-v2/service/dynamodb"
	"github.com/labstack/echo/v4"
	"net/http"
)

func main() {
	e := echo.New()

	// Create a custom HTTP transport that enforces TLS 1.2+ with secure defaults
	transport := &http.Transport{
		TLSClientConfig: &tls.Config{
			MinVersion: tls.VersionTLS12,
		},
	}

	// Build SDK config with custom endpoint and secure transport
	cfg, err := config.LoadDefaultConfig(e.Logger,
		config.WithEndpointResolver(aws.EndpointResolverFunc(func(service, region string) (aws.Endpoint, error) {
			return aws.Endpoint{
				URL:           "https://dynamodb.local:8000",
				SigningRegion: "us-east-1",
			}, nil
		})),
		config.WithHTTPClient(&http.Client{Transport: transport}),
	)
	if err != nil {
		e.Logger.Fatal("failed to load config:", err)
	}

	dbClient := dynamodb.NewFromConfig(cfg)

	e.GET("/scan", func(c echo.Context) error {
		input := &dynamodb.ScanInput{
			TableName: aws.String("ItemsTable"),
		}
		result, err := dbClient.Scan(c.Request().Context(), input)
		if err != nil {
			return c.JSON(500, map[string]string{"error": err.Error()})
		}
		return c.JSON(200, result.Items)
	})

	e.Logger.Fatal(e.Start(":8080"))
}

• How does middleBrick relate to Missing TLS in Echo Go with DynamoDB?

  middleBrick scans API endpoints and returns security risk scores for issues such as Missing TLS, Data Exposure, and Encryption. It helps identify insecure communication between your Echo Go service and DynamoDB, providing prioritized findings and remediation guidance without performing fixes or blocking traffic.

• Can middleBrick detect Missing TLS in unauthenticated scans?

  Yes. middleBrick runs unauthenticated black-box scans and includes checks for Encryption and Data Exposure. While it does not fix or block issues, it maps findings to frameworks like OWASP API Top 10 and provides actionable remediation guidance for TLS enforcement.