Vulnerabilities
Rails master.key vs .env on Production Origins
May 28, 2025
Rails master.key vs .env on a production origin is two ways to spill the app's secret material. /.env is plaintext runtime secrets — the roast signatures it. master.key is the key that unwraps Rails encrypted credentials. Serving either next to index.html is the same class of miss. RoastMyOpsec may not fetch master.key today. Still deny that name at the edge. Do not advertise it in robots.txt. The control is a CDN deny, not a crawler suggestion.
The practical difference
.env is a bag of KEY=value lines. master.key is a small file whose only job is cryptographic. Public bytes of either are a credential incident. Encrypted credentials files without the key are a different problem; this guide is about not hosting the key on a CDN.
Teams copy config/ into static exports, or deploy the Rails tree as if it were a brochure. The production document root is not config/.
How to choose based on what you shipped
If master.key or .env was public: take the objects off the origin, deny those names at the CDN, rotate the Rails secret and anything the credentials file named, and stop publishing config trees. Inject the key via the platform secret store on app servers, never via a static bucket.
| Option | When it wins | Watch-out | Takeaway |
|---|---|---|---|
| .env on the origin | Never | Live secrets in text | Incident; roast signatures this path |
| master.key on the origin | Never | Unwraps encrypted credentials | Same class of miss; deny the name |
| master.key as a platform secret | App hosts you control | Do not write it into public/ | Keep it off every CDN object |
| robots.txt Disallow | Not for keys | Publishes the path | Edge deny instead |
When each secret wins (always off the brochure origin)
.env wins as private runtime config where the framework expects it — on the server. master.key wins as an injected secret on that same server. Neither wins in public/ or in a Jamstack dist folder.
If /.git/HEAD was also public, assume history. Rotate rather than arguing about which copy was current.
Common mistakes
The first mistake is gitignoring .env and still committing master.key, then syncing the repo to a public bucket.
The second mistake is rotating RAILS_MASTER_KEY in the host env while the old master.key file stays downloadable.
The third mistake is Disallowing /config in robots.txt and calling it access control.
What a URL roast can prove
The roast signatures /.env and /.env.local. master.key is not a scored path today. Still deny it. Bounded GETs, no decryption walkthrough, no use of leaked keys. Confirm the bucket, not only a soft-404 homepage.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Is a public master.key a vulnerability?
- Treat it as a credential incident. Remove it, deny the name at the edge, and rotate the Rails secret and related credentials.
- Does RoastMyOpsec fetch master.key?
- Not as a scored path today. It does probe /.env. Deny master.key at the CDN anyway. Same class of miss as /.env.
- Can I keep credentials.yml.enc on the CDN if the key is private?
- The marketing origin still does not need Rails config. Keep the whole credentials pair off public objects.
Sources
Related guides
Vulnerabilities
.env.example vs .env on Production OriginsVulnerabilities
Exposed .git vs .env on Production WebsitesVulnerabilities
Public JavaScript API Keys vs Server Secrets