Your Terraform State File Is a Plaintext Secrets Dump, Here Is How to Fix It

The most common exposure paths, in order of frequency:

Committed to git: The default local state file is terraform.tfstate in the working directory. A developer who does not have terraform.tfstate in .gitignore, or who adds it once to share with a colleague, commits it to the repository. If the repository is ever made public, or if an attacker gains read access, every secret in state is compromised. Check your git history: git log --all --full-history -- '*.tfstate' will show you if state was ever committed.

Misconfigured S3 bucket: S3 is the most common remote backend. A bucket created without a Block Public Access policy, or with an overly permissive bucket policy, can expose state to the internet or to any AWS principal in your account. AWS S3 Access Analyzer will flag this if it is configured, but many teams do not have it enabled on the state bucket.

Overpermissive IAM policies: A developer with s3:GetObject on the state bucket can read all state for all workspaces. In many organizations, the Terraform state bucket has the same IAM policies as other S3 buckets, which means application teams, data engineers, and CI/CD service accounts may have read access they should not.

Terraform Cloud / Enterprise token exposure: If you use Terraform Cloud, state is accessible to anyone with a valid organization or workspace API token. A leaked token (via a compromised developer machine, a leaked CI/CD secret, or a public repository) gives full state read access.

Before fixing the backend configuration, determine whether existing state has already been exposed.

Check git history for committed state:

# Find any tfstate files ever committed
git log --all --full-history --oneline -- '**/*.tfstate' '*.tfstate'

# If found, check when and by whom
git log --all -p -- terraform.tfstate | head -100

If state was committed, treat every secret in it as compromised regardless of whether the repository is private, git history is persistent and may have been cloned.

Check S3 bucket access policy:

# Check bucket public access block
aws s3api get-public-access-block --bucket YOUR-STATE-BUCKET

# Should return all four fields as true
# If any are false, public access may be possible

# Check bucket policy for overly broad principals
aws s3api get-bucket-policy --bucket YOUR-STATE-BUCKET | jq '.Policy | fromjson'

Look for Principal: "" or Principal: {AWS: ""} in any Allow statement, this means the bucket is publicly accessible.

Check who can read state:

# Find all IAM principals with s3:GetObject on your state bucket
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::ACCOUNT:role/ROLE \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::YOUR-STATE-BUCKET/*

The minimum required configuration for a secure Terraform S3 backend:

terraform {
  backend "s3" {
    bucket         = "your-terraform-state-bucket"
    key            = "path/to/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true          # Server-side encryption (SSE-S3 or SSE-KMS)
    kms_key_id     = "arn:aws:kms:..."  # Use KMS for key management
    dynamodb_table = "terraform-state-lock"  # Prevent concurrent writes
    
    # Require all access to be authenticated
    # Block public access at the bucket level separately
  }
}

The bucket itself must have Block Public Access enabled:

aws s3api put-public-access-block \
  --bucket YOUR-STATE-BUCKET \
  --public-access-block-configuration \
    'BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true'

Use a customer-managed KMS key (not the default aws/s3 key) for encryption, this lets you control who can decrypt state via KMS key policy, in addition to S3 bucket policy. An IAM principal needs both s3:GetObject and kms:Decrypt permissions to read state.

Create separate IAM roles for different state access patterns:

Plan role (read-only): Can call s3:GetObject and s3:ListBucket on state. Used by developers running terraform plan in local environments or in preview CI jobs. Cannot modify state.

Apply role (read-write): Can call s3:GetObject, s3:PutObject, s3:DeleteObject, and dynamodb actions for the lock table. Used only by production CI/CD pipelines running terraform apply. This role should require MFA for human assumption.

Audit role (read-only with logging): Can call s3:GetObject but all access is logged via S3 server access logging and CloudTrail data events. Used for security reviews and incident investigation.

Never give developers direct write access to the state bucket outside of the apply role. Developers who need to inspect state should use terraform state list and terraform state show through an authenticated CLI session, not direct S3 access.

If you confirmed state was exposed (via committed git history, public bucket, or compromised credentials), rotate in order of blast radius:

Database master passwords: For RDS, generate a new master password and update it:

aws rds modify-db-instance \
  --db-instance-identifier YOUR-DB \
  --master-user-password NEW_PASSWORD \
  --apply-immediately

Then update the Terraform variable and run terraform apply to update state.

IAM access keys: For any aws_iam_access_key resources in state, delete the exposed keys and let Terraform create new ones:

terraform taint aws_iam_access_key.example
terraform apply

TLS private keys: For tls_private_key resources in state, the private key is fully exposed. Regenerate the key pair, re-issue any certificates signed by that key, and update all endpoints using those certificates.

Long-term fix: Move secrets out of Terraform state entirely. Use aws_secretsmanager_secret to store secrets in Secrets Manager and reference them by ARN rather than value. The secret value itself never enters Terraform state.

The most effective mitigation is architectural: do not put secrets into Terraform state in the first place.

For database passwords: Use aws_secretsmanager_secret_rotation with automatic rotation. Terraform creates the secret and configures rotation but never stores the current password value in state, Secrets Manager generates and rotates it independently.

For IAM credentials: Use IAM roles with OIDC federation instead of access keys wherever possible. No long-lived credentials means no credential exposure from state.

For TLS certificates: Use aws_acm_certificate (ACM) rather than tls_private_key (tls provider). ACM manages the private key internally, it is never returned to Terraform and never appears in state.

For arbitrary secrets: Use the vault provider with HashiCorp Vault dynamic secrets. The Vault provider can generate short-lived credentials on-demand during terraform apply without storing the credential values in state.