Vulnerabilities
id_rsa vs .env on Production Origins
May 27, 2024
id_rsa vs .env on a production origin is a private SSH key versus dotenv secrets, both sitting where only index.html should live. A reachable /.env is a credential dump — the roast signatures it. A reachable private key file is the same class of miss: material that authenticates as you. RoastMyOpsec may not fetch id_rsa today. Still deny that name at the edge. Do not list private-key filenames in robots.txt. Access control is a CDN deny, not a crawler hint.
The practical difference
.env holds application secrets. id_rsa (and cousins such as id_ed25519 without the .pub suffix) is a key pair's private half. Public keys are meant to be public. Private keys are not. The CDN cannot tell the difference unless you keep the private half off the bucket.
If a private key was public, treat it as stolen: remove the object, deny the name, replace the key on systems that trusted it. This guide does not describe using the key. It describes not hosting it.
How to choose based on what you shipped
Strip SSH key files from static artifacts in CI. Deny private-key basenames at the CDN. Rotate any key that may have been in a public object. Keep deploy keys in a secret manager, not in the web root. Pair with /.git/HEAD if the whole working copy shipped.
| Option | When it wins | Watch-out | Takeaway |
|---|---|---|---|
| .env on the origin | Never | Live app secrets | Incident; roast signatures this path |
| Private key on the origin | Never | Authenticates as a machine or human | Same class of miss; deny the name |
| Public key (.pub) in docs | Sometimes, if you meant to publish it | Do not upload the private half beside it | Still skip the marketing bucket if unused |
| robots.txt Disallow | Not a vault | Names the file | Deny at the edge instead |
When each secret store wins (off the public origin)
.env wins as private runtime config. A private SSH key wins in an agent or hardware-backed store on a machine you control. Neither wins as a static download.
Deploy keys for CI belong in the CI secret store. Copying them 'next to the site so the build can git pull' is how they become public.
Common mistakes
The first mistake is committing a deploy key into the frontend repo and publishing that repo as the CDN root.
The second mistake is deleting id_rsa from the bucket but leaving authorized_keys trust in place without replacing the key.
The third mistake is Disallowing the filename in robots.txt and assuming strangers will not request it.
What a URL roast can prove
The roast signatures /.env, /.git/HEAD, and a short leftover list. id_rsa is not a scored path today. Still deny it. Bounded GETs only. No key parsing as an attack recipe, no SSH attempts. Confirm absence in the bucket, not only from a homepage 404.
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 id_rsa a vulnerability?
- Yes — treat it as a credential incident. Remove the object, deny the name at the edge, and replace the key wherever it was trusted.
- Does RoastMyOpsec fetch id_rsa?
- Not as a scored path today. It does probe /.env and /.git/HEAD. Deny private-key names at the CDN anyway. Same class of miss.
- Is the .pub file safe on the origin?
- It is not a private key, but the marketing origin still does not need it. Never place the private half beside it.
Sources
Related guides
Vulnerabilities
Exposed .git vs .env on Production WebsitesVulnerabilities
.env.example vs .env on Production OriginsVulnerabilities
robots.txt Disallow vs Access Control for Hidden Paths