Is your directory listing turned on without you knowing?

An open /uploads/ index is a menu of everything you never meant to share.

Most exposed-file problems need the attacker to guess a filename. Directory listing removes the guessing. When it's on, requesting a folder with no index.html returns a clickable list of everything inside it, names, sizes, and dates. The stranger doesn't have to know what's there. The server tells them.

What an open index actually shows

Visit https://yoursite.com/uploads/ on a server with autoindex enabled and you get the bare directory page Apache and nginx generate: a table of every file in that folder. It's the same view you'd get from ls on the box, served to anyone with the URL.

The danger is that folders accumulate files nobody chose to publish. User uploads land in /uploads/. Reports get written to /exports/. Old assets pile up in /files/ and /backups/. Each individual file might be obscure enough that nobody would guess its name. The index hands over all the names at once.

Why it turns on by accident

Directory listing is an explicit feature, but it's easy to enable without meaning to. On Apache it's the Indexes option, which gets switched on globally in some default configs and inherited by every folder that lacks an index file. On nginx it's autoindex on;, often pasted into a config from a tutorial about serving downloads and then left in place for the whole site. A static file host or an object storage front-end might default to listing.

The reason it goes unnoticed is that your real pages all have an index.html or are handled by your app, so you never see the listing yourself. The autoindex only appears for the folders without one, which are exactly the folders you don't visit in a browser: upload directories, export directories, asset dumps. The feature is on across the whole site and you only ever see the parts where it's harmless.

What a stranger does with the list

First they read the names, because filenames leak intent. members-export.csv, q3-financials.xlsx, passport-scan.jpg, staging-backup.zip. The name alone tells them which files are worth taking, and the size column tells them which ones hold real data. Then they download the interesting ones directly. There's no auth on a static folder; the listing and the files are equally public.

It also speeds up everything else. An open /uploads/ or /files/ listing often reveals naming patterns that let an attacker guess the files in folders that aren't listed. And if your app writes source maps, logs, or a stray database dump into a served directory, the index puts those on the menu right next to the user content. It's the same root exposure as a public .git folder, just presented as a friendly file browser.

Checking it from the outside

Pick the folders that hold things you didn't intend to publish and request them with a trailing slash. Try /uploads/, /files/, /exports/, /backups/, /assets/, /tmp/, and /.well-known/. What you want back is a 403 Forbidden or a 404. What you don't want is a 200 with a page titled "Index of /…" and a table of files.

If you find an open index, the fix is to turn the feature off, ideally for the whole server rather than folder by folder.

# nginx: tutorial left this on for the whole server
location / {
autoindex on;        # every index-less folder lists itself
}

Turning the listing off doesn't make the individual files private. A file at a known URL is still downloadable. So treat this as two jobs: stop the enumeration, then move anything genuinely sensitive out of a web-served folder and behind real access control. The index just made the problem visible all at once.

You can find an open index in about a minute: it's a folder request and a glance at the response title. SurfaceCheckr does that part for you, walking the common upload, export, and backup paths and flagging any that come back as a generated "Index of /" page. It reads only the listing itself, from the outside, the way any visitor would. It never pulls down the files behind it, and it won't tell you whether those files should have been private in the first place. That part is still your call, and it's the kind of access-control question a real pentest exists to answer. What the scan gives you is the first thing to fix: the folders quietly publishing their own table of contents.