OPSWAT Announces FileScan.IO Asset Acquisition. Read More

AWS S3 Configuration Best Practice: Use HTTPS (TLS) to Protect Data in Transit

In our last blog we explored the history of pre-flight checklists to avoid catastrophic failures from human errors and misconfiguration. In this blog we’ll delve in-depth into a critical public cloud storage security check.

A major AWS S3 configuration error is neglecting to enforce HTTPS (TLS) to access bucket data since unencrypted traffic is vulnerable to man-in-the-middle attacks that can steal or modify data in transit. These sort of attacks can lead to the loss of valuable enterprise data and compliance violations with regulations such as PCI DSS and NIST 800-53 (rev 4).

Amazon has produced its AWS Well-Architected Framework to help organizations achieve best practices related to operational excellence, security, reliability, performance efficiency, and cost optimization. The Security Pillar provides guidance to implement best practices in the design, delivery and maintenance of secure AWS workloads.

Shared Responsibility

The concept of “Shared Responsibility” is one of the foundations of the Security Pillar. According to Amazon, AWS is responsible for “security of the cloud” while its customers are responsible for “security in the cloud.” These customer responsibilities include identity and access management, threat detection, infrastructure protection, data protection and incident response.

Data Protection

Data protection encompasses data classification, as well as protecting data at rest and data in transit. According to Amazon:

Data in transit is any data that is sent from one system to another. This includes communication between resources within your workload as well as communication between other services and your end users. By providing the appropriate level of protection for your data in transit, you protect the confidentiality and integrity of your workload’s data.

Amazon highlights four best practices for protecting data in transit:

  • Implement secure key and certificate management
  • Enforce encryption in transit
  • Authenticate network communications
  • Automate detection of unintended data access

    Transport Layer Security

    In order to enforce encryption in transit, AWS services provide HTTPS endpoints using TLS for communication. AWS Config offers numerous predefined and customizable managed rules, which can be easily configured to enforce best practices. Among these rules is s3-bucket-ssl-requests-only, which checks if Amazon S3 buckets have policies that explicitly deny access to HTTP requests. Bucket policies that allow HTTPS without blocking HTTP are considered non-compliant.

    Organizations can enforce this rule with the "aws:SecureTransport" condition key. When this key is true the request was sent via HTTPS, but when it is false organizations need a bucket policy that explicitly denies access to HTTP requests.

    Amazon provides this example of a bucket policy that denies access when “aws:SecureTransport”: “false”:

     "Id": "ExamplePolicy",
     "Version": "2012-10-17",
     "Statement": [
     "Sid": "AllowSSLRequestsOnly",
     "Action": "s3:*",
     "Effect": "Deny",
     "Resource": [
     "Condition": {
     "Bool": {
     "aws:SecureTransport": "false"
     "Principal": "*"

    Fig: Example Bucket Policy

    Avoid Common Configuration Errors with OPSWAT

    When it comes to common configuration errors, such as HTTPS (TLS), organizations should use checklists to ensure they are implementing best practices. Automating this process with technology can help to avoid time-consuming and expensive manual errors.

    MetaDefender for Secure Storage enhances its cloud storage security solution with an integrated security checklist, so that cybersecurity professionals can ensure their organization’s cloud storage is not misconfigured as it is provisioned which includes the development and production stages of cloud storage.

    Enforcing HTTPS (TLS) to access bucket data is a critical checklist item in MetaDefender for Secure Storage, but it isn’t the only one. In future blogs, we will be exploring other major configuration errors for protecting data at rest, including bucket versioning, server-side encryption, and bucket access logging.

    Contact an OPSWAT cybersecurity expert to learn more.

    Sign up for Blog updates!
    Get information and insight from the leader in advanced threat prevention.