CWE-552, Files or Directories Accessible to External Parties, is a broad access problem. MITRE says the product makes files or directories accessible to unauthorized actors, even though they should not be. It applies across languages, technologies and cloud computing.
How it happens
MITRE describes three routes.
Files under a served root. Web servers, FTP servers and similar services keep a set of files under a root directory that users can reach. Applications may store sensitive files under that root without access control to limit who can request them.
Archives that include too much. An application may package multiple files or directories into a ZIP or tar archive and fail to exclude the sensitive files underneath those directories.
Misconfigured cloud storage. In cloud technologies and containers, the weakness may appear as storage accounts that a public or anonymous user can read or write.
MITRE gives one observed example, CVE-2005-1835: a data file under the web root (Gold entry). It is old, and it shows the pattern is not new.
A small code illustration of the archive route:
# Vulnerable: zips everything under the directory, including .env and keys
shutil.make_archive("release", "zip", "app/")
# Better: build the archive from an explicit list
with zipfile.ZipFile("release.zip", "w") as z:
for name in ["app.py", "static/site.css", "templates/index.html"]:
z.write(f"app/{name}", name)
What an attacker gains
MITRE lists two effects: reading files or directories, and modifying files or directories. Confidentiality and integrity both suffer. A public storage location that allows writes lets someone replace content you serve to others.
How to find it
- List what sits under your document root and ask whether each item needs to be public.
- Unpack your own release archives and read the contents.
- Review cloud storage settings for any container or bucket that allows anonymous access.
- Request known sensitive filenames from outside your network and see what answers.
- MITRE notes static analysis can find some instances of this weakness.
How to fix it
MITRE's mitigation for cloud storage is to use the provider's controls to disable public access when storing data in services such as S3 buckets, Azure blobs and Google Cloud Storage. Combined with the other routes:
- Keep sensitive files outside any served directory.
- Enforce access control on any file that must be served but not to everyone.
- Build archives from allowlists, not whole directories.
- Turn off public access at the account or organization level for cloud storage, and open exceptions deliberately.
- Keep watching. Settings drift, so check them continuously instead of once.
Try it yourself
This demo shows how cloud connectors surface storage and configuration risks across accounts.
Click through it at your own pace, or open it full screen.
Quick check
An archive is built from a folder that looks clean. What could still go wrong?
Hidden files such as environment files or keys may sit under the folder. Building from an explicit allowlist avoids including them by accident.
What is the cloud version of this weakness?
Storage accounts that a public or anonymous user can read or write. The fix is to disable public access with the provider's controls.
