Mobile App Logic Research
Finding where a consumer ordering app trusted the client instead of the server.
Overview
Consumer mobile apps push a lot of logic onto the phone for speed, and that convenience is usually where trust leaks. This project was me testing that premise directly on a national chain's ordering app: not to take anything, but to see whether the server actually re-checked the decisions the app was making on the client. I ran the app through an intercepting proxy so I could read the traffic between the phone and the backend, then worked through the order flow one request at a time to see where the real decisions were being made.
How I worked
Most of the effort was observation before anything else. I mapped the order flow as a sequence of requests and responses, and for each step I asked a single question: is this value decided on the phone, or is it decided and verified on the server. An intercepting proxy sitting between the app and its backend let me watch the exact fields the client sent and compare them against what came back. The interesting cases are the ones where the app presents a rule as fixed, a limit or a price or a state, but the server takes the client's word for it rather than recomputing it independently.
The flaw
What I found was a business-logic issue rather than a memory or injection bug: the app trusted a piece of client-side state that it should have validated server-side. Once I could see which value the server was accepting without re-checking, the impact followed logically from there. I documented that the trust boundary was in the wrong place and reasoned through what it would allow, then stopped. The skill in this kind of work is not producing a payload, it is reading a normal-looking exchange and spotting the one assumption the backend should never have made about the client.
Why it stays anonymised
I have deliberately kept this framed as research. The company is not named, the exact steps and requests are not published, and it is not presented as a way to get anything for free. What I am showing is the class of flaw, client trust in an ordering system, and the ability to find it and describe its impact responsibly rather than abuse it. That framing is the point: the same reasoning that finds a flaw like this is the reasoning that closes it.
The hardest problem
The hardest part was not technical execution, it was disciplined reasoning about a trust boundary. Anyone can run a proxy and watch traffic. The difficulty is looking at a stream of ordinary, valid-looking requests and identifying the single value that the app decided locally and the server then accepted without independently recomputing it. That means holding a mental model of which side should own each decision, and resisting the assumption that because the app enforces a rule, the backend must too. Once I identified the misplaced trust, the second hard part was restraint: reasoning through the real impact carefully enough to be sure it was genuine, then documenting it and stopping there rather than exercising it. Getting the analysis right without turning it into abuse was the whole discipline of the project.
Start a project
Want something built like this?
Everything on this page was designed, built and hosted by one person. Tell me what you need and I reply with scope, cost and timeline, usually within two working days.