When S3 buckets versioning is enabled it’s possible to add an additional authentication factor before being allowed to delete versions of an object or changing the versioning state of a bucket. It prevents accidental object deletion by forcing the user sending the delete request to prove that he has a valid MFA device and a corresponding valid token.

Ask Yourself Whether

• The S3 bucket stores sensitive information that is required to be preserved on the long term.
• The S3 bucket grants delete permission to many users.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

It’s recommended to enable S3 MFA delete, note that:

• MFA delete can only be enabled with the AWS CLI or API and with the root account.
• To delete an object version, the API should be used with the x-amz-mfa header.
• The API request, with the x-amz-mfa header, can only be used in HTTPS.

Sensitive Code Example

A versioned S3 bucket doesn’t have MFA delete enabled:

resource "aws_s3_bucket" "mynoncompliantbucket" { # Sensitive
  bucket = "mynoncompliantbucketname"

  versioning {
    enabled = true
  }
}

Compliant Solution

MFA delete is enabled (it’s not possible to set this option to a new S3 bucket with Terraform but the Terraform template can be updated that way it reflects the state):

resource "aws_s3_bucket" "mycompliantbucket" { # Compliant
  bucket = "mycompliantbucketname"

  versioning {
    enabled = true
    mfa_delete = true
  }
}

See

• OWASP Top 10 2021 Category A7 - Identification and Authentication Failures
• AWS documentation - Configuring MFA delete
• MITRE, CWE-308 - Use of Single-factor Authentication
• OWASP Top 10 2017 Category A2 - Broken Authentication