Half-Hearted or Half-Baked?

Whilst using a supplier's web site yesterday morning it slowly ground to a halt, and eventually gave up completely.

The web application is very slow normally, but this time parts of the page did not load and it was almost impossible to navigate around after authenticating. Now, difficulty with navigation is not unusual for this site, but this time there was definitely more amiss than the terrible usability.

After a few clicks, page content began to be delivered containing error messages — with full stack traces. Oops. We often ensure that errors are trapped, logged and never displayed to end users during more standard conditions, but this cannot be relied upon during periods of great stress or unusual conditions such as during start-up, severe resource limitation and shut-down. Why continue with half-hearted responses, especially when they start leaking information about the server and application configuration? The user experience is not improved by partial error-ridden content. Stop the responses!

These type of conditions are a good use-case for data egress monitoring such as might be provided by a device like a web application firewall (WAF). Server-side code, file system paths and internal error messages such as stack traces should never, ever, appear in the generated output, so we can confidently block such responses, and raise alerts just in case no-one has noticed the other problems. Plan ahead for failure, and make sure the incident management plan isn't half-baked and includes some automated actions.