A10 · OWASP Top 10 · 3 min

Mishandling of exceptional conditions. What does your site do when things go wrong?

Every system hits errors: a database timeout, a missing field, a payment provider that doesn't answer. This is about whether your site fails safely, or falls open and spills.

I run a

In 10 seconds

When something goes wrong, the site fails open.

What it is

When something unexpected happens, a system should fail safely: stay locked, say little and recover. Mishandling is when an error unlocks a door, reveals technical detail, or leaves a half-finished action behind.

Why you care

Attackers cause errors on purpose, because errors are where checks get skipped. A permission check that crashes into "allow", or a payment that half-succeeds, can reach your names, addresses, phone numbers and purchase history or your money.

What to do

Ask: when a check or a service fails, does the site refuse by default? Has anyone tested the bad day, not just the normal flow?

For your business

What's at stake for you.

I run a

Who is affected

Your customers, and anyone who trusts you with their details.

What could leak

Names, addresses, phone numbers and purchase history.

Ask this first

“If one of those services fails or times out, does our site refuse by default?”

Where it hides

Pick a way things go wrong.

Normal use is tested by everyone. These are the situations that get skipped.

yourbusiness.com/admin (permission service down)

What's here: What happens when the part that checks permission, payment or identity doesn't answer.
What goes wrong: The site is built to carry on if a check fails, so a crash or timeout becomes a green light.
Ask your team: If our login, permission or fraud check fails or times out, does the site refuse by default?
Developers call it: Fail-open logic, missing fail-safe defaults

What it costs

The bad day is where the money goes.

Failing open

A crash becomes a green light: access granted and checks skipped.

Money and mess

Half-finished actions mean wrong charges, lost orders and books that don't match.

A free map

Chatty error messages tell attackers how your system is built.

Downtime

Systems that fall over under strain turn a spike, or an attack, into an outage.

For an online shop: a failed check that defaults to allow could expose names, addresses, phone numbers and purchase history.

Does this apply to you?

Tick what's true. Get your questions.

Firstfor online shop

So the questions fit you

What kind of business do you run?

Real cases

Not always an attack. Always costly.

No safe default, 2012

Forty-five minutes, $440 million.

What it cost: Knight needed an emergency rescue from investors and was soon merged into another firm.
The lesson: Not an attack. Unexpected behaviour with no safe default and no kill switch is what mishandled conditions cost.

Read the full story and sources

On 1 August 2012, a software update left old, unused code active on one of Knight Capital's eight trading servers. When markets opened, it began sending huge numbers of unintended orders. Warning emails went out but weren't acted on, and there was no quick way to stop it. In about 45 minutes the firm lost around $440 million.

Knight needed an emergency rescue from investors and was soon merged into another firm. In 2013 the US SEC fined it $12 million for lacking adequate controls.

Sources: US Securities and Exchange Commission order (October 2013), press coverage.

Your part

Three decisions that are yours.

01Choose the safe defaultFor every check on money, access or data, decide what happens when it fails. Safe usually means refuse and alert.
02Test the bad dayRequire testing of failures: outages, timeouts, empty and extreme input, half-finished actions. Not only the normal flow.
03Plan the way backDecide who can override and recover when things fail closed, and rehearse it, so safe doesn't also mean stuck.

For your developer: the technical layer

Fail closed: treat errors, timeouts and missing responses from security checks as deny. Never default to allow inside a catch block.
Handle exceptions centrally. Show users generic messages, log the detail privately with correlation IDs, and never swallow exceptions silently.
Make multi-step operations atomic with transactions, idempotency keys and compensating actions, plus reconciliation jobs for partial failures.
Validate type, range, size and nullability. Handle missing and malformed values explicitly, including negatives and overflow.
Set timeouts, retries with backoff and circuit breakers for dependencies, and cap request size, rate and concurrency.
Test failure paths with negative tests, fuzzing, fault injection and load tests. Add kill switches and alerts for abnormal behaviour.
Provide logged, strongly authenticated break-glass access for recovery.

Remember

Three things to keep.

Every system hits errors. What matters is whether it fails safe: locked, quiet and logged.
Test the bad day, not just the happy path.
Safe needs a way back. Plan how to recover when things fail closed.

What OWASP says

The essentials, slide by slide.

A10 · owasp top 10 · 01/04

OWASP Top 10 · A10

mishandling of exceptional conditions

Source: OWASP Top 10:2025 (CC BY 3.0) ↗

OWASP is a non-profit that publishes the industry's standard list of web risks. Safety measures adapted from the OWASP Top 10:2025 (CC BY 3.0). The people and businesses in the examples are made up.