Missing Tls in Gin with Dynamodb
Missing Tls in Gin with Dynamodb — how this specific combination creates or exposes the vulnerability
When a Gin application communicates with Amazon DynamoDB without enforcing Transport Layer Security (TLS), credentials, tokens, and query parameters can traverse the network in cleartext. This situation commonly arises in development environments or misconfigured production deployments where the HTTP client used by Gin does not require HTTPS or skips certificate validation. Because DynamoDB endpoints support both HTTP and HTTPS, a Gin service that uses an HTTP client or an incorrect endpoint URL will send requests in plaintext, exposing sensitive data to network observers.
The risk is compounded when the Gin application handles user-supplied input that influences DynamoDB request parameters, such as table names or key conditions. Without TLS, an on-path attacker can observe or modify requests, leading to unauthorized data access or manipulation. For example, if a Gin handler constructs a DynamoDB GetItem or Query request using an HTTP client and an HTTP endpoint, session tokens or IAM credentials embedded in AWS signatures may be visible to an eavesdropper. This exposure can facilitate replay attacks or credential theft, especially if the application does not rotate keys frequently.
In the context of middleBrick’s security checks, Missing TLS is flagged as a finding under the Encryption category and contributes to the overall risk score. The scanner validates that endpoints enforce HTTPS and that responses are not delivered over cleartext HTTP. Because DynamoDB traffic often carries sensitive data, failing to require TLS violates encryption-in-transit best practices and can map to compliance frameworks such as PCI-DSS and SOC2, which mandate protection of data in transit.
Dynamodb-Specific Remediation in Gin — concrete code fixes
To remediate Missing TLS in Gin applications that interact with DynamoDB, enforce HTTPS for all AWS service communication and use a properly configured HTTP client. The following examples demonstrate how to construct DynamoDB requests securely in Go using the AWS SDK for Go v2, ensuring TLS is mandatory and credentials are not exposed in logs or error messages.
Secure DynamoDB client setup with TLS
Initialize the DynamoDB client with the AWS SDK’s default configuration, which uses the system’s root CA pool and enforces HTTPS. Do not override the transport to disable TLS verification.
import (
"context"
"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"
)
func newDynamoDBClient() (*dynamodb.Client, error) {
cfg, err := config.LoadDefaultConfig(context.TODO(),
config.WithRegion("us-east-1"),
// The default resolver chain uses HTTPS endpoints; do not disable it.
)
if err != nil {
return nil, err
}
return dynamodb.NewFromConfig(cfg), nil
}
Secure GET request example
Use the client to perform a GetItem call with a table name and key that are validated and do not leak sensitive information in logs. Ensure the request URL is not constructed manually with HTTP.
func getItemSecure(ctx context.Context, client *dynamodb.Client, tableName string, key map[string]types.AttributeValue) (map[string]types.AttributeValue, error) {
input := &dynamodb.GetItemInput{
TableName: aws.String(tableName),
Key: key,
}
output, err := client.GetItem(ctx, input)
if err != nil {
return nil, err
}
return output.Item, nil
}
Secure Query request example
For queries, validate partition key values and avoid exposing them in URLs or logs. Use condition expressions to enforce application-level authorization rather than relying on network isolation.
func querySecure(ctx context.Context, client *dynamodb.Client, tableName string, partitionKey string, partitionValue string) ([]map[string]types.AttributeValue, error) {
input := &dynamodb.QueryInput{
TableName: aws.String(tableName),
KeyConditionExpression: aws.String("pk = :pkval"),
ExpressionAttributeValues: map[string]types.AttributeValue{
":pkval": &types.AttributeValueMemberS{Value: partitionValue},
},
}
var results []map[string]types.AttributeValue
paginator := dynamodb.NewQueryPaginator(client, input)
for paginator.HasMorePages() {
page, err := paginator.NextPage(ctx)
if err != nil {
return nil, err
}
results = append(results, page.Items...)
}
return results, nil
}
In addition to code-level fixes, integrate middleBrick’s CLI and GitHub Action to verify that your Gin endpoints enforce TLS during continuous integration. The CLI can be run locally with middlebrick scan <url>, and the GitHub Action can fail builds if the scan reports an Encryption finding. For ongoing assurance, the Pro plan enables continuous monitoring and Slack/Teams alerts to notify your team when a regression occurs.
Related CWEs: encryption
| CWE ID | Name | Severity |
|---|---|---|
| CWE-319 | Cleartext Transmission of Sensitive Information | HIGH |
| CWE-295 | Improper Certificate Validation | HIGH |
| CWE-326 | Inadequate Encryption Strength | HIGH |
| CWE-327 | Use of a Broken or Risky Cryptographic Algorithm | HIGH |
| CWE-328 | Use of Weak Hash | HIGH |
| CWE-330 | Use of Insufficiently Random Values | HIGH |
| CWE-338 | Use of Cryptographically Weak PRNG | MEDIUM |
| CWE-693 | Protection Mechanism Failure | MEDIUM |
| CWE-757 | Selection of Less-Secure Algorithm During Negotiation | HIGH |
| CWE-261 | Weak Encoding for Password | HIGH |
Frequently Asked Questions
How can I test whether my Gin service is enforcing TLS when communicating with DynamoDB?
middlebrick scan <your-gin-url> and review the Encryption finding; ensure your HTTP client is configured to reject cleartext HTTP and to use the system certificate pool.