Server misconfiguration: headers and exposed files

A house can be built with excellent locks and still be left with a window open. Server misconfiguration is exactly that: nothing is wrong with the application’s code, but the platform around it, the web server, the framework, the cloud account, has been set up in an unsafe way. These problems are among the most common findings in real audits, and fortunately among the easiest to fix.

Why configuration matters

Modern applications stand on many layers: operating system, web server, application framework, database, cloud services, container platform. Each layer has hundreds of settings, and the defaults are often designed for convenience, not for safety. A single oversight in any layer can expose the whole application. OWASP’s Top 10 has a dedicated category for security misconfiguration for this reason.

The usual suspects

Problem	Why it is risky
Default accounts and passwords left active	Public documentation lists them; trying them takes seconds
Debug mode enabled in production	Detailed errors, stack traces, or even interactive consoles are shown to visitors
Verbose error messages	Reveal paths, library names, database details and query fragments
Directory listing enabled	Visitors can browse folder contents, including files not meant to be public
Unneeded features and services enabled	More code and ports exposed means more places to attack
Missing security headers	Browsers lack protective instructions (lesson 4 of chapter 4)
Weak or outdated TLS configuration	Encryption of traffic may be weakened
Overly permissive cross-origin settings	Other sites may be allowed to read responses they should not
Publicly accessible cloud storage or admin consoles	Data or control exposed to the internet

Exposed files: what to look for

Developers and deployment processes leave behind files that were never meant to be public. Typical categories a tester checks, in the lab or on an authorised target:

• Backup and temporary files. An editor or admin makes a copy of a configuration or code file with a suffix like .bak, .old, or ~. The web server may serve it as plain text, revealing source code and secrets, whereas the original would have been executed.
• Configuration files. Environment files, application settings and deployment scripts that contain database passwords, keys and tokens.
• Version control folders. A leftover repository folder on the server can allow someone to reconstruct the entire source code history, including secrets once committed and later “removed”.
• Documentation and diagnostics pages. API documentation, status pages, information pages from the framework, profiler toolbars, and monitoring endpoints.
• Log files and database dumps stored in web-accessible directories.
• Test and staging remnants. Old versions of the site, test accounts, sample applications that ship with the server.

Remember robots.txt from lesson 4 of chapter 1: it politely asks search engines to avoid some paths, and so it also lists interesting ones. It is a map, not a lock.

How testers look for them

There are two complementary approaches.

1. Observation. Read what the application tells you: links, JavaScript files, comments in the HTML, error pages, response headers, and the site map in Burp. Many exposures are discovered just by reading carefully.
2. Controlled path checking. Tools can request a list of common file and directory names and report which exist. In a lab, this teaches how directory discovery works. On a real target, this generates many requests and needs to be explicitly allowed by the rules of engagement, with a limit on speed. Always use a modest rate and respect the agreed scope.

When you find something, apply the “minimum proof” principle: note the path and the type of content (“a configuration file containing what appears to be database credentials”), take one screenshot with sensitive values blurred, and stop. Do not use found credentials to log in anywhere.

Information leakage through headers and errors

Look at the response headers of your lab application in Burp:

HTTP/1.1 200 OK
Server: ExampleServer/9.9 (Unix)
X-Powered-By: ExampleFramework/9.9
Set-Cookie: session=...; Path=/

Headers that announce exact software and versions help attackers find known vulnerabilities in precisely those versions. Removing or generalising them is a small hardening step, valuable mostly as part of a layered approach: it does not fix a vulnerability, it only avoids advertising it.

Trigger a harmless error, such as requesting a path that does not exist or sending an unexpected value in a parameter, and read what the application answers. A production system should return a short, generic error page, and log the details privately.

Cross-origin resource sharing (CORS)

Browsers prevent a page on one site from reading responses from another site (the same-origin policy). CORS headers let a server relax that rule for chosen origins. Misconfigurations occur when a server allows every origin, or reflects whatever origin the request announces, while also allowing credentials. This can let a malicious page read private data from the user’s session on the target site. When you review responses from an API, look at Access-Control-Allow-Origin and Access-Control-Allow-Credentials: the combination of a broad origin policy with credentials is a red flag. The MDN documentation at developer.mozilla.org explains CORS in detail.

HTTP methods and other surfaces

• Unneeded methods such as TRACE, or PUT and DELETE where no feature requires them. Ask the server which methods it accepts for a path and compare with what the application needs.
• Admin interfaces reachable from the internet instead of only from an internal network or through a VPN.
• Open ports and services that your network scans (course 2) have shown to be unnecessary.
• Cloud settings: storage containers readable by anyone, overly broad access roles, publicly exposed databases, missing network rules.

Hardening: the defender’s checklist

• Secure baseline. Start from a recommended configuration guide for each component; recognised benchmarks and guidance exist from bodies such as the ANSSI and NIST (cyber.gouv.fr and nist.gov).
• Disable what you do not need: sample apps, debug modes, unused modules, extra HTTP methods, directory listing.
• Change all defaults and remove default accounts.
• Keep secrets out of the web root and out of the code repository; use environment variables or a secrets manager.
• Return generic errors and log details privately.
• Set the security headers and a restrictive CORS policy.
• Separate environments: development, staging and production should not share credentials or data.
• Automate and verify. Use configuration as code, review changes, and run regular configuration checks so that a change does not silently reopen a window.

Your turn: configuration review of your lab

Review the configuration of your lab application: (1) list the headers that disclose the technology, (2) trigger a harmless error and record what it reveals, (3) check whether the application serves a directory listing for one of its folders, (4) list the HTTP methods that you would expect to be needed. Write each result as a row in a table.

See a solution

An example table for a training application:

Check	Observation	Recommendation
Technology headers	Server and X-Powered-By reveal names and versions	Remove or genericise
Error handling	An invalid parameter shows a stack trace with file paths	Generic error page, details in private logs
Directory listing	The /uploads/ folder lists its content	Disable listing; serve files through the application
HTTP methods	Only GET and POST needed; PUT accepted on one path	Disable unneeded methods

Because it is a deliberately vulnerable application, most rows will show issues. The value of the exercise is the habit of checking each one.

Next, a different kind of weak link: the software your application did not write but depends on.