nginx.conf, .user.ini, authorized_keys: the config files that map your server for free

Not every exposed file is a password. Some are blueprints. A web-server config doesn't contain a credential, but it names your upstream services, your internal hostnames, your vhosts, and how requests get routed. An IDE's datasource config doesn't carry the database password (usually), but it tells a stranger which database, on which host, with which driver. An authorized_keys file isn't a private key, but it lists who's trusted to log in.

These are low-severity on their own and the scanner grades them that way. The reason to care is that an attacker doesn't look at them one at a time. They collect the map, and a server that hands over its config files is a server that's been pre-mapped for whoever shows up. Here are the four the scanner checks for.

Web-server config: nginx.conf and httpd.conf

Your nginx or Apache config is the routing table for the whole site. It names every vhost, every proxy_pass upstream, every internal service the public server forwards to, sometimes with internal IPs and ports right there in the file. It can reveal auth setups, rate-limit rules, which paths are special-cased, and where the "real" backend lives behind the public face.

Downloadable, that's a free architecture diagram. An attacker reads it once and knows your internal topology without sending a single probe: the admin path you thought was obscure, the upstream API server on a private IP, the staging vhost you forgot was still configured.

These files have no business in the document root, they live in /etc/nginx/ or /etc/apache2/, not next to your HTML. When one is downloadable it's because a copy got deployed with the site or a backup landed in a served directory.

PHP per-directory runtime config: .user.ini

.user.ini lets PHP set runtime directives per directory. The file itself is low-stakes, but served, it confirms you're running PHP, often reveals settings like upload_max_filesize, open_basedir, or custom auto_prepend_file paths, and quietly fingerprints your stack. It's a small confirmation that narrows an attacker's guesses, which is the whole point of recon.

IDE datasource config: .idea/dataSources.xml

This one is a developer footgun. JetBrains IDEs (PhpStorm, IntelliJ, DataGrip) store database connection definitions in .idea/dataSources.xml. When the whole project folder, .idea directory and all, gets deployed, that file becomes downloadable. It typically carries the database host, port, database name, and driver, the full topology of where your data lives. The password usually isn't in this file (JetBrains stores it separately), so the scanner rates it medium, not critical. But "here is exactly which database, on which host, listening on which port" is a precise target handed over for free, and it pairs nastily with any other leak that does carry a credential.

SSH authorized_keys

authorized_keys lists the public keys allowed to log into an account over SSH. It contains no private key, so it can't be used to log in directly, which is why it's medium and not critical. What it gives an attacker is the guest list: which identities are trusted, often with user@hostname comments that name your team members and their machines. That's reconnaissance, who to target, whose laptop to compromise, which usernames are real, and a confirmation that this path of the filesystem is web-reachable at all.

The fix is the same for all four

These don't get fixed one by one. They get fixed by fixing what put them in the web root: deploying more than the build output. Config files, IDE folders, and dotfiles belong outside the document root, and ideally never leave the machine that generated them.

# the project folder, deployed wholesale
/var/www/html/
.idea/dataSources.xml   <-- DB host + port
.user.ini
nginx.conf              <-- a copy, served as a file
.ssh/authorized_keys

Reading it from outside

Whether each of these answers an anonymous GET is something a stranger checks by requesting the path, and that's what SurfaceCheckr does, from outside, with no credentials. Each is gated on a real content signature, the actual nginx/Apache directive tuple, the PHP .user.ini directive shape, the JetBrains DataSourceManagerImpl marker, the line-anchored SSH key-type token, so a soft-404 catch-all that 200s everything doesn't trip them. They're individually low-severity by design, scored so they tidy your surface without flooding the report, but they're worth knowing about, because the map they hand over is the map an attacker would otherwise have to build by probing. If you want the higher-stakes cousins in the same family, the cloud and infra config files and the small leaks that fingerprint your stack are the next thing to read.