Pia

One thing worth checking while you are in here, since it is adjacent and much more commonly exploited: make sure the same authorisation checks apply to every endpoint, including the ones the app never calls in a normal flow.

Admin-ish endpoints, internal-sounding paths and old versioned routes routinely have weaker checks because "the app does not call those". The traffic analysis that revealed your headers reveals those too, and they are usually a much better target than replaying an ordinary request.

That is a half-day audit and it protects against the thing that actually happens.

The distinction is who initiated it, and once you see it the whole thing is predictable.

Pull payments. You give somebody permission to take money - a card payment, a direct debit. The mechanism is designed around the idea that the taker might be wrong or dishonest, so there is a built-in route to reverse it. Card schemes call it a chargeback; direct debit schemes have their own guarantee. The reversal is part of the product.

Push payments. You instruct your bank to send money - a bank transfer, an instant payment. The system is built to settle finally and quickly. There is no reversal mechanism because the whole design assumes you meant it. Once it lands in the recipient's account it is legally theirs, and the bank has no button.

Your two friends used one of each. The card dispute went through a process that exists. The transfer had no process to go through, which is what "it is gone" means: it is a statement about the rails, not about effort.

"It does not ask you to believe anything unlikely" is the sentence I will use with the family. The framing that it filters for careful people rather than careless ones is going to land better than another warning.

The structural fix, which makes this a non-issue forever, is content hashing plus two cache policies:

• Assets: JS, CSS, images: get a hash in the filename: app.9f2c1a.js. Serve them with Cache-Control: public, max-age=31536000, immutable. They can be cached forever because a changed file is a different name. Nothing is ever stale, because nothing is ever overwritten.
• HTML: the entry point: gets Cache-Control: no-cache. Not no-store; no-cache means "you may keep it, but revalidate before using it". So the browser checks in, and gets the new HTML, which references the new hashed asset names.

That is the entire pattern. The HTML is small and revalidating it is cheap, and it is the only thing that ever needs to be fresh, because it names everything else.

Every modern build tool does the hashing part for you. The part people miss is the header on the HTML.