A banking integration allowed authorized staff to trigger production financial transaction batches by sending a specifically-worded email. Convenient, fast, easy to use during an incident when someone needed a batch started, stopped, or finalized without waiting on a deploy or a console login. I wasn't investigating the trigger mechanism itself — a client had sent a message out of the expected order, and I was tracing why the automation had responded the way it did.
What I found instead was more concerning than the original issue.
Reading the Code That Decides Who's Allowed
The function behind the email trigger parses incoming messages and, based on subject line, executes real production actions — start a transaction batch, stop one, finalize one. Naturally, the first thing I looked for was the authorization check: where does it confirm the sender is someone actually allowed to do this?
There wasn't one. The code read the subject line to decide what action to take. It never looked at the sender address at all.
Which means: anyone whose message reached that inbox — regardless of who they were, spoofed or not, internal or external — could trigger real start, stop, or finalize actions against production financial transaction batches, as long as the subject line matched the expected format.
What Made This Easy to Miss
This isn't the kind of gap that shows up in normal operation. The people using the trigger day to day were, in fact, always the authorized staff — because in practice, only they knew the feature existed and the exact subject-line format it expected. The system worked correctly for every legitimate use, every time, which is exactly why nobody had gone looking for the authorization check that wasn't there. It's a gap that only fails badly, and it fails badly for someone else to find.
The Response
Two separate tracks, deliberately not conflated:
Immediate operational safeguard: a proper manual-trigger SOP, built around a verification chain rather than trusting the email channel alone — customer confirmation required before any trigger, product-team approval required specifically for stop and finalize actions (the two with the most potential for damage), and a mandatory audit log entry for every single trigger, successful or not.
Security follow-up: the sender-validation gap itself, flagged separately and explicitly as a security issue rather than folded into the SOP as if a process document could substitute for an actual code fix. A process can reduce how often the gap gets exercised by legitimate users doing the wrong thing; it does nothing about someone illegitimate finding the same email address.
Why I'm Writing This Down
The scariest bugs I've found weren't the ones I was looking for — they were sitting one layer under whatever I was actually investigating. This one would have stayed invisible indefinitely under normal use, because normal use never exercises the failure path. That's a useful thing to internalize: "it's worked fine for two years" is not evidence that an authorization boundary exists. It's only evidence that nobody's tested it yet, on purpose or otherwise.
Takeaways
- An automation trigger that "always works correctly" for legitimate users tells you nothing about whether it rejects illegitimate ones — those are different code paths, and only one of them gets exercised in normal operation.
- When convenience features are built directly against production financial or otherwise sensitive actions, check the authorization boundary explicitly — don't assume it exists because the feature has been in use without incident.
- Keep the operational safeguard (process, audit trail) and the actual security fix (real validation) as separate tracked items — a good SOP is not a substitute for closing the underlying gap.