Security

Crashtest first blood: 30 attacks, 29 refused, 1 exploited

Running our adversarial QA tool against fresh code: one campaign broke both handlers in under a minute, and the fix changed how we write handlers everywhere.

The experiment

Crashtest is our adversarial QA tool: a seeded attack suite that runs against real handlers through a fake transport - no network, no bans, no invoice - and produces a hardening ledger your CI fails on regressions. To test the hammer, we built a two-handler demo target: one deliberately weak, one properly guarded.

The hit

First run: 30 attacks, 29 refused, 1 exploited - in under a minute. The exploited finding was the instructive kind. The request-shape campaign sent hostile request shapes, and both handlers threw: "Cannot read properties of undefined." A thrown exception is an oracle for an attacker; a 400 is a shrug. The handlers assumed friendly shapes and crashed on hostile ones.

The fix

We wrapped each handler with a safe() guard and validated request shapes inside - refuse, never fail. Re-run: 30 for 30 refused, zero exploited, exit code 0, and the ledger remembered the whole arc. If that guard ever rots, the regression fails CI automatically.

The lesson

One line, now house law: handlers refuse, never fail. Every new handler surface gets a crashtest run before it ships - and we found a scaffold bug in crashtest itself along the way, filed upstream like any other sighting.

Build with people who write this down.

Methodical, transparent, and documented - on our site and yours.

Start a Project