The idea: a setting, not a bug

Security misconfiguration is OWASP Top 10:2025 item A02. The code can be perfect and the application still be wide open, because the hole is in a setting: a shipped default account, a debug flag, a web-server option, a cloud permission, a parser feature. The same application is safe or exposed depending on one line of config. The umbrella weakness is CWE-16 (Configuration), and the list below gathers several concrete ones.

The animation draws one server, shop.example, with a config panel of six lines. A config switch flips every line between a vulnerable value (red) and a hardened value (green). Each scenario sends the same attack against both and shows which line decided the outcome: the attack request flies from the client on the left to the server on the right, the server consults the highlighted line, and the response comes back exposed or marked blocked.

A server config panel with six lines; one line, app.debug, is shown flipping from the vulnerable value true (red) to the hardened value false (green), and the same request gives a leaked stack trace in the first case and a generic error in the second.
One config line decides the outcome: flip it from the vulnerable to the hardened value and the same request is stopped.

The CWE examples the page shows:

ScenarioMisconfigurationCWE
Default admin accountadmin/admin left enabled on an admin consoleCWE-1392 (default credentials), CWE-489 (active debug/admin feature)
Verbose error pagedebug=true returns a stack trace and framework versionCWE-209 (information exposure through an error message)
Directory listingautoindex on lists /backup/db.sqlCWE-548 (exposure through directory listing)
Missing framing headersno X-Frame-Options / CSP frame-ancestorsCWE-1021 (clickjacking, rendered UI layers)
Public cloud bucketstorage ACL set to public-readCWE-732 (incorrect permission on a critical resource)
XML external entitiesXML parser with external entities enabledCWE-611 (XXE)

Defaults, debug and verbose errors

Software ships to be easy to start, not to be safe: sample accounts, admin consoles, management ports and verbose logging are often on by default. A manager console reachable with admin/admin is a full compromise for anyone who tries it (Demo 1). Leaving debug=true in production turns every unhandled error into a gift: the browser receives a stack trace, the framework name and version, and sometimes the failing database query (Demo 2). Hardening is the same move each time: remove the default account, turn debug off, and return a generic error page with an id that only the server-side log can resolve.

The same GET request to a crashing endpoint: on the left with debug=true the response is a 500 with a full stack trace and Framework 4.2.1; on the right with debug=false the response is a 500 with a generic message and an error id, no internal details.
Same request, two configs: a verbose error leaks internals (left); the hardened config returns only an error id (right).

Directory listing and public buckets

A web server with directory listing (Apache autoindex on, nginx autoindex on) turns any folder without an index page into a browsable file list. A forgotten /backup/ then hands out db.sql, .env and log files to anyone who guesses the path (Demo 3, CWE-548). The cloud version is a storage bucket whose ACL is public-read: the bucket is reachable by the whole internet with no login, and its objects are downloaded anonymously (Demo 5, CWE-732). Both are fixed by the same idea — turn listing off, make the bucket private, and give read access only to the application's own role.

Missing security headers and clickjacking

A browser only enforces protections the server asks for. With no X-Frame-Options and no CSP frame-ancestors directive, another site may load yours inside a hidden <iframe>, lay an invisible overlay on top, and trick the victim into clicking a real button on your page — clickjacking (Demo 4, CWE-1021). Sending X-Frame-Options: DENY (or CSP frame-ancestors 'none') tells the browser to refuse to render the page in a frame, and the attack fails. The same family includes a missing Content-Security-Policy, HSTS (Strict-Transport-Security) and secure cookie attributes — see the cookies page.

Left: evil.example frames shop.example in an iframe with an overlay, and with no framing header the shop page renders inside it so the click is stolen. Right: with X-Frame-Options DENY the browser refuses to display the frame and it stays blank.
Without a framing header the attacker's page can embed yours; X-Frame-Options: DENY makes the browser refuse.

XML external entities (XXE)

Many XML parsers will, by default, resolve an external entity — a placeholder in the document that points at a URL or a local file. An attacker uploading XML can declare an entity that names a file on the server, and a parser left in its permissive default returns that file's contents, or reaches internal network addresses on the attacker's behalf (Demo 6, CWE-611). XXE has sat under Security Misconfiguration since the 2021 list (it was its own item, A4, in 2017) because the fix is a configuration one: disable DOCTYPE processing and external entities (enable "secure processing", or simply use a safer format such as JSON). The page does not show a working document; it shows the parser setting that decides whether the entity is expanded at all.

How to prevent it

  • Harden by default. Remove sample accounts, default passwords, unused pages, features and ports (CWE-489, CWE-1392); turn off debug and directory listing in production.
  • Least privilege. Give each account, role and cloud resource the narrowest access that works; buckets and admin consoles are private unless there is a reason otherwise (CWE-732).
  • Send the headers. Set X-Frame-Options/CSP frame-ancestors, a Content-Security-Policy, HSTS and secure cookies (CWE-1021).
  • Fail quietly. Return a generic error to the user and keep the stack trace in the server log only (CWE-209).
  • Lock down parsers. Disable XML DTDs and external entities; prefer formats without them (CWE-611).
  • Make it repeatable. Build config from version-controlled, reviewed templates; scan images and deployed settings, and re-check after every change — a hardened app drifts back to vulnerable one manual tweak at a time.

OWASP Top 10:2025 series

This page is one of a ten-part series. The others:

See also How Browser Cookies Work (SameSite, HttpOnly, Secure, HSTS) and How OAuth 2.0 Works.

See also Server-Side Request Forgery: IMDSv1 left on turns one SSRF bug into leaked cloud keys; requiring IMDSv2 blocks it.

What the page leaves out

The real responses are much longer, and a real server has hundreds of config lines, not six. The page shows one deterministic outcome per setting and does not run any actual exploit: there is no working XXE document, no credential list and no live overlay. It also skips the detection side (vulnerability scanners, image and infrastructure-as-code checks), TLS and cipher configuration, CORS misconfiguration, verbose logging as a leak, and the many framework-specific hardening guides that turn these defaults off.