Every request was signed, but not the part that says what it does

The signature that looked strong

The app attached a signed header to each request, which is more than most apps do. The signature covered a one-time number and a timestamp, and nothing else: not the address being called, not the body being sent.

That means a captured set of headers is valid for any request, to any endpoint, for about a minute. The control existed and did almost nothing.

Two sessions, two roles

Most of the findings needed a comparison: what a regular user could do and what an administrator could do. We captured a session of each role and replayed requests between them.

A password-change endpoint had no role check and we confirmed it live. A staff directory could be read by a regular role. Chained with the replay weakness, they made one account-takeover story.

The finding that said the design was sound

The same app denied another endpoint correctly for the same role. Its permission model worked wherever it had been applied.

So the critical findings were gaps in route coverage, not a broken model. That changes the fix: the team did not need to redesign anything, only to apply the existing policy to the routes that had missed it.

What we handed over

The report listed 11 confirmed findings, 4 of them critical, with 18 regression test cases so the team could prove each fix. The fix for the missing role checks was sized at fewer than 20 lines per policy.

The test cases matter as much as the findings. They turn a one-day review into something the team can run on every release.

What to take from it

• A signature is only as strong as what it covers. Ask which fields are signed.
• Test with two roles. Most access flaws only show when you compare.
• Say whether the design or the coverage is at fault. It decides how big the fix is.