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.
Tools & Automation
The spreadsheets and copy-paste routines your team runs every week are automations waiting to happen. We build the small, sharp tools that delete the busywork - and the integrations that make your systems talk to each other.
See how we do it →Back End & Infrastructure
The front end gets the compliments; the back end keeps the promises. We build and run the server side - APIs, databases, email, and the business logic in between - so the whole thing holds up under real use.
See how we do it →