How to Keep Secrets Out of Web Roots and Into AWS Secrets Manager

Retrospective: this article looks back at events from August 2024, written in 2026 with the benefit of hindsight.

Exposed .env files led to an AWS extortion campaign in 2024. Here is how to keep secrets out of web-accessible locations and move them into AWS Secrets Manager.

Step 1: Block access to configuration files

• Web servers: deny requests for dotfiles and configuration files. For example, in nginx: location ~ /\.(?!well-known) { deny all; }. In Apache, use <FilesMatch "^\."> with Require all denied.
• Deployment: make sure build pipelines don't copy .env or configuration files into public directories or static site buckets.
• Test: request https://yourdomain/.env and similar paths — they should return 403 or 404.

Step 2: Find exposed secrets

• Scan your own domains for exposed configuration files.
• Scan repositories and container images for secrets.

Step 3: Move secrets to Secrets Manager

1. Create secrets in AWS Secrets Manager for database credentials, API keys and tokens.
2. Grant applications access via IAM roles (EC2 instance profiles, ECS task roles, Lambda execution roles) with permission to read only their secrets.
3. Retrieve secrets at runtime using the AWS SDK, or use integrations (ECS and EKS can inject secrets as environment variables from Secrets Manager without files on disk).
4. Enable automatic rotation for database credentials where supported.

Step 4: Eliminate AWS keys in configuration

Applications running on AWS shouldn't need AWS access keys at all — use roles. For applications outside AWS, use IAM Roles Anywhere or OIDC federation.

Step 5: Rotate anything that was in .env files

Assume any secret ever stored in an .env file on a web server may have been exposed.

Step 6: Protect data

Enable S3 versioning and Object Lock for critical buckets, and restrict delete permissions.