Security misconfiguration: what a filter sees of a setting

Figures are from the A02:2025 page of the OWASP Top 10.

OWASP lists the forms it takes.

• Missing hardening. Anywhere in the stack, including cloud permissions set too wide.
• Unneeded features left on. Extra ports, services, pages, accounts, test frameworks or privileges.
• Default accounts still active. With their default passwords unchanged.
• Errors that say too much. Stack traces and detailed messages reach the visitor.
• Security features off after an upgrade. New protections exist but were never enabled.
• Insecure values kept for compatibility. Old behaviour preserved at the cost of safe settings.
• Missing security headers. The server sends no security directives, or sends them with insecure values.

A misconfiguration is a state, and a state does not arrive in a request. What arrives is someone looking for it.

OWASP's scenarios show the pattern: a sample application with an administrative console left on a production server, directory listing that lets an attacker download compiled classes, stack traces returned to the visitor. Finding each of these starts with requests for paths and files an ordinary visitor never asks for, which scanners send in bulk.

One weakness in the category does carry a payload. An XML external entity attack puts a document type declaration that references an outside resource into an XML body, and that structure is recognisable.

• It can slow down the search. Requests for well-known sensitive paths and bulk scanning can be matched and refused, which raises the cost of finding a mistake.
• It can refuse a recognisable payload. XML external entity declarations are one example.
• It cannot change what the server answers. A stack trace returned to one request is not something a filter in front of the request can see.
• It cannot reach what is outside the site. Storage opened to the internet by a cloud default is accessed directly, without passing through your request path.

Of all the categories, this is the one where a filter is most tempting as a substitute and least suited to be one, because the misconfiguration stays in place behind it.

OWASP's measures are about process as much as settings.

• A repeatable hardening process. New environments come up locked down, and development, test and production are configured the same, each with its own credentials.
• A minimal platform. No unneeded features, components, documentation or samples.
• Configuration reviewed with patches. Including cloud storage permissions.
• Segmented architecture. Components and tenants separated.
• Security directives sent to clients. Security headers, for example, or a CORS policy that trusts any origin.
• Automated verification in every environment. And a central handler that stops detailed errors as a backstop.
• No static secrets in code or pipelines. Short-lived credentials or platform roles instead.

In the OWASP Core Rule Set, REQUEST-913 detects scanners, REQUEST-920 enforces the HTTP protocol, and REQUEST-930 covers local file inclusion, which includes requests for sensitive files. On the response side, the RESPONSE-95x files look for data leaks such as error output.