Vulnerabilities
Exposed Procfile vs package.json on Production Origins
October 1, 2023
An exposed Procfile vs package.json on a production origin is two process maps that must not sit next to index.html. /package.json donates scripts and dependency names — the roast signatures it. A Procfile donates process types and the commands that start them: web, worker, release. That is not a password file, and it is still the same class of miss as leftover inventory on a CDN. RoastMyOpsec may not fetch /Procfile today. Still deny the name at the edge. Do not Disallow it in robots.txt.
The practical difference
package.json scripts are the Node-shaped list. Procfile is the dyno-shaped list. Together they describe how the app boots more clearly than a marketing page should.
A release command that points at a migrator or a one-off task is an operational hint. Keep that in the private repo. The brochure origin only needs hashed assets.
How to choose based on what you shipped
Fail CI if Procfile or package.json appear in a static marketing artifact. Deny those basenames at the CDN. If you already shipped them, remove the objects and fix the publish root so the repo root is not the web root.
| Option | When it wins | Watch-out | Takeaway |
|---|---|---|---|
| /package.json | Almost never on the CDN | Scripts and dependency names | Roast signatures this path today |
| /Procfile | Never on the CDN | Process types and start commands | Same class of miss; deny the name |
| Procfile in private git / PaaS | Platform process formation | Do not copy it into dist/ | Keep off the public bucket |
| robots.txt Disallow | Not for this | Advertises the file | Edge deny instead |
When each inventory file wins (off the public origin)
package.json wins in the private repo. Procfile wins in the private repo and on the PaaS that reads it at deploy time from git, not from a stranger's GET. Neither wins as a static object beside index.html.
Dockerfile in the same export is the same pipeline bug. Fix the artifact once.
Common mistakes
The first mistake is deploying the Heroku or Dokku project root as the CDN folder.
The second mistake is calling Procfile 'not a secret' while it names internal workers and release tasks.
The third mistake is Disallowing /Procfile in robots.txt instead of denying it at the CDN.
What a URL roast can prove
The roast signatures /package.json. Procfile is not a scored path today. Still deny it. Bounded GETs, no process-start attempts, no exploit payload. A pass on package.json is not proof Procfile is absent.
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 Procfile a vulnerability?
- It is an information leak. Remove it from the origin and deny the name. It is not usually a credential dump, and it still does not belong on a marketing CDN.
- Does RoastMyOpsec fetch Procfile?
- Not as a scored path today. It does probe /package.json. Deny Procfile at the CDN anyway. Same class of miss.
- Does the platform need Procfile on the public site?
- No. The platform reads it from the app repo at deploy. Browsers do not need it.
Sources
Related guides
Vulnerabilities
Public package.json vs Lockfile Advisories on ProductionVulnerabilities
Dockerfile vs package.json on Production OriginsVulnerabilities
.env.example vs .env on Production Origins