Missing Tls in Fiber with Dynamodb

When a Fiber service communicates with DynamoDB without enforcing Transport Layer Security (TLS), credentials, tokens, and query parameters can be exposed in transit. This typically occurs when the AWS SDK is configured without explicit TLS settings or when an HTTP endpoint (non-TLS) is used to reach DynamoDB. In a black-box scan, middleBrick tests unauthenticated attack surfaces and flags Missing TLS as a high-severity finding under the Encryption category because data in transit is not cryptographically protected.

For example, initializing the AWS SDK with an HTTP endpoint or without enforcing TLS on the client can expose IAM signing information and payloads to interception. If the service does not validate server certificates, a man-in-the-middle attacker could capture or alter requests intended for DynamoDB. This misconfiguration is especially risky when the service uses long-lived credentials or when the API is exposed via an OpenAPI spec that does not reflect the missing encryption controls. middleBrick cross-references OpenAPI/Swagger definitions with runtime findings, so discrepancies between documented encryption and actual network behavior are surfaced as actionable items.

In a typical scan, middleBrick runs checks in parallel, including Encryption and Unsafe Consumption. If the client does not verify TLS certificates or uses plain HTTP, the Encryption check will highlight the exposure, and findings will include severity, guidance, and references to compliance frameworks such as OWASP API Top 10 and PCI-DSS. Because DynamoDB stores sensitive data, missing TLS increases the risk of data exposure and can violate compliance requirements. The scanner does not fix the issue but provides remediation guidance so teams can enforce TLS in their clients.

To remediate Missing TLS when using DynamoDB with Fiber, enforce HTTPS endpoints and ensure the AWS SDK validates TLS certificates. In Go, this means configuring the AWS SDK with the correct endpoint resolver and ensuring the HTTP client enforces TLS verification. Below are concrete, working examples that demonstrate a secure setup.

Secure DynamoDB client with TLS enforced

// main.go
package main

import (
	"crypto/tls"
	"crypto/x509"
	"fmt"
	"net/http"
	"os"

	"github.com/aws/aws-sdk-go/aws"
	"github.com/aws/aws-sdk-go/aws/session"
	"github.com/aws/aws-sdk-go/service/dynamodb"
	"github.com/gofiber/fiber/v2"
)

func main() {
	// Create a custom HTTP client that enforces TLS 1.2+ and verifies certificates
	transport := &http.Transport{
		TLSClientConfig: &tls.Config{
			MinVersion: tls.VersionTLS12,
		},
	}
	client := &http.Client{Transport: transport}

	// Create a session with a custom HTTP client and enforce HTTPS endpoint
	sess := session.Must(session.NewSession(&aws.Config{
		Endpoint:            aws.String("https://dynamodb.us-east-1.amazonaws.com"),
		HTTPClient:          client,
		Region:              aws.String("us-east-1"),
		CredentialsChainVerboseErrors: aws.Bool(true),
	}))

	svc := dynamodb.New(sess)

	// Example: DescribeTable to verify connectivity over TLS
	input := &dynamodb.DescribeTableInput{
		TableName: aws.String(os.Getenv("TABLE_NAME")),
	}

	result, err := svc.DescribeTable(input)
	if err != nil {
		fmt.Fprintf(os.Stderr, "Failed to describe table: %v\n", err)
		os.Exit(1)
	}

	fmt.Printf("Table status: %s\n", *result.Table.TableStatus)

	// Fiber route that safely interacts with DynamoDB
	app := fiber.New()
	app.Get("/items/:id", func(c *fiber.Ctx) error {
		// Securely query DynamoDB using the TLS-enabled client
		itemInput := &dynamodb.GetItemInput{
			TableName: aws.String(os.Getenv("TABLE_NAME")),
			Key: map[string]*dynamodb.AttributeValue{
				"id": {S: aws.String(c.Params("id"))},
			},
		}
		itemResult, err := svc.GetItem(itemInput)
		if err != nil {
			return c.Status(http.StatusInternalServerError).SendString("Failed to get item")
		}
		return c.JSON(itemResult.Item)
	})

	app.Listen(":3000")
}

Remediation checklist for CI/CD and scanning

• Ensure the endpoint URL uses https:// and not http://.
• Configure the AWS SDK to use a custom HTTP client with TLS 1.2+ and default certificate verification.
• In the GitHub Action, set a security threshold so that builds fail if the Encryption check flags Missing TLS.
• Use the middleBrick CLI to validate the fix: middlebrick scan <url> and confirm the Encryption category returns no findings related to Missing TLS.

These steps align with OWASP API Top 10:2023 A05:2021 Security Misconfiguration and can be reported in compliance formats via the Pro plan for continuous monitoring.