Get Hacker Buddy

Exposed admin pages and forgotten files

Hacker's handbook • 3 min read

The simplest attacks don't exploit anything. They just ask for a file or a page that shouldn't be public, and the server hands it over. Automated tools request the same list of well-known paths from every site they find, all day. If one of those paths answers on your site, it will be found.

What attackers ask for first

  • Configuration files: /.env and similar files hold database passwords and API keys. One successful request can hand over the whole application.
  • Version control folders: an exposed /.git/ directory lets anyone download your full source code and its history, including secrets that were committed and later removed.
  • Backups and dumps: files like backup.zip, db.sql, or site-old.tar.gz left in the web root after a migration.
  • Admin and login pages: /admin, /wp-admin, database tools, and dashboards reachable by anyone, protected only by a password.
  • Debug and status pages: framework debug screens, server status pages, and API documentation that reveal internals.
  • Directory listings: a folder that shows its contents instead of a page, so nothing in it needs to be guessed.

Check your own site

Ask for these paths the way an attacker would and look at the status code on the first line of each response:

curl -sI https://yourapp.com/.env
curl -sI https://yourapp.com/.git/config
curl -sI https://yourapp.com/admin

A 404 or 403 is what you want for files. A 200 means the server returned something, and you should look at what. Some sites return 200 with a "not found" page for every path, so read the response before you worry.

Close them

Keep private files out of the web root

The most reliable fix is for the file not to be there. Configuration belongs outside the folder your web server serves, or in environment variables. Backups belong in private storage, never next to the site.

Deny what should never be served

As a safety net, tell the web server to refuse hidden files entirely. In nginx:

location ~ /\.(?!well-known) {
    deny all;
}

This blocks every path starting with a dot, except /.well-known/, which certificate renewal and some standards rely on.

Don't rely on a password alone for admin pages

  • Restrict who can reach them: a VPN, single sign-on, or an allowlist of addresses means an attacker never sees the login form.
  • Require a second factor for every admin account.
  • Limit attempts so passwords can't be guessed at speed. See Locking down logins.
  • Change default credentials before a tool is ever reachable. Default usernames and passwords are public knowledge.

Turn off debug mode in production

Debug screens show source code, settings, and sometimes an interactive console. They are for your laptop. Check that production runs with debugging off and that errors show visitors a plain message while details go to your logs.

If something was exposed

Removing the file isn't enough. Assume it was downloaded. Change every password and key it contained, and check your logs for requests to that path. If a .git folder was exposed, treat every secret that was ever committed as leaked.

Conclusion

Attackers try the easy things first because they work so often. Request the well-known paths on your own site, keep private files out of the web root, put admin pages behind more than a password, and check again after every deploy, because this kind of exposure usually arrives by accident.

Up next