Every feature I ship goes through an awkward ritual: I finish building it, open Burp Suite, and try to destroy it. Not because I enjoy rewriting code at midnight — because the person who finds a bug first decides whether it becomes a fix or an incident.
The checklist
It's not sophisticated. It's a list, and the list is boring on purpose:
- Send every request twice, mutated the second time — IDs, quantities, roles, prices.
- Drop auth tokens, reuse expired ones, replay them from another IP.
- If it accepts text, it accepts HTML and SQL. Prove it doesn't execute them.
- Do everything the UI forbids, directly against the API.
- Check what the server returns that the UI never renders. That's where secrets leak.
Why this works better than a pentest
External pentests are valuable, but they're periodic and they see the app cold. The developer who wrote the code knows exactly where the lazy assumptions live. I know which endpoint I wrote at 11pm, which one trusts client-side validation because I was tired. That knowledge is a map — attacking my own code with it is fast and precise.
The person who finds a bug first decides whether it becomes a fix or an incident.
The part nobody talks about
Doing this changes how you write code in the first place. Once you've broken your own session handling twice, you stop rolling your own. You reach for the battle-tested library, the boring pattern, the design that fails closed. Attack-mode makes defense a habit instead of a checklist item.