Is a public .vscode folder a vulnerability?

It is an information leak. Remove it and deny the prefix. It is not always a credential dump, but it is not harmless.

Does RoastMyOpsec fetch .vscode?

Not as a scored path today. It does signature-check .DS_Store. Deny editor folders at the edge anyway.

Should recommended extensions stay in the repo?

Yes, in the private git repo. Not as objects on the public CDN next to index.html.

Vulnerabilities

.vscode vs .DS_Store on Production Origins

May 3, 2026

.vscode vs .DS_Store on production origins is two leftover folders next to index.html. .DS_Store is Apple Finder metadata that can list filenames. .vscode (and JetBrains .idea) is editor config: launch.json, tasks.json, settings.json, sometimes extensions.json. Those files can name local paths, debug ports, and — when someone pasted a secret into a workspace setting — tokens. Neither is access control. Autoindex off does not delete them. RoastMyOpsec probes /.DS_Store with a bounded GET and a binary signature. It does not currently score /.vscode or /.idea, does not parse JSON settings, and does not crawl every prefix looking for nested leftovers.

The practical difference

Finder files are OS cache. IDE folders are project config that hitchhiked into the static zip. .env.example is a cousin template. package.json is inventory if you published it. Git is a third channel if /.git is public.

A 200 on /.vscode/settings.json is an information leak even when the values look boring. Deny the directory at the CDN.

How to choose what to strip

CI: fail the build if .vscode, .idea, .DS_Store, or desktop.ini appear in the CDN artifact. Keep editor folders in the private repo only. CDN: deny those prefixes even if CI is perfect. Nested /assets/.vscode counts. Do not 'clean once' on a laptop and call it a pipeline.

Leftover	Typical leak	Public origin	Takeaway
/.DS_Store	Filenames from Finder	Never	Scored path on the roast
/.vscode/*	Paths, tasks, sometimes secrets	Never	Not scored today; deny anyway
/.idea/*	JetBrains workspace	Never	Same class
/.env.example	Variable names / copied values	Never on the CDN	See .env.example vs .env

When .vscode still wins (off the public origin)

Shared recommended extensions in a private repo help onboarding. They never belong on a marketing bucket. Pair with exposed .git if the same zip also shipped history.

What the roast can prove

A .DS_Store signature on a bounded GET can surface. .vscode is not scored. Confirm a 404 yourself. Pair with directory listing if the folder is also autoindexed.

Common mistakes

The first mistake is stripping only .DS_Store because Mac laptops were the known problem.

The second mistake is committing settings.json with a live API key 'just for this workspace.'

The third mistake is Disallow: /.vscode and calling it access control.

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 now

FAQ

Is a public .vscode folder a vulnerability?: It is an information leak. Remove it and deny the prefix. It is not always a credential dump, but it is not harmless.
Does RoastMyOpsec fetch .vscode?: Not as a scored path today. It does signature-check .DS_Store. Deny editor folders at the edge anyway.
Should recommended extensions stay in the repo?: Yes, in the private git repo. Not as objects on the public CDN next to index.html.

Sources

Related guides

Vulnerabilities
Exposed .svn vs .git on Production Websites
Vulnerabilities
.env.example vs .env on Production Origins
Vulnerabilities
Exposed .git vs .env on Production Websites