Oh man, that is classic sloppy web development.

It's often so easy to reach for the values in the params/payload first because you're already working with them, instead of remembering to use the session values instead.

This would be a great audit to do for entire codebases.. Just check all places that are using params/payload values and see if there's actually already a session value that should be used instead.

Don't just audit. Strengthen the critical APIs with types. A user provided string is not the same type as an authentic identity. Make the developer be explicit about the critical mistake about to be made. Perl had this down decades ago with the tainted checks.

This, thousand times. Don't just fix the bug, fix the process that led to the bug. Developers are (usually) not malicious, but we are often working with tooling which makes mistakes easy to do, difficult to detect and grave in consequences. Fix the tooling, not just the bug.

I wonder if encoding the query params with some dumb encoding (maybe a custom variant of base64?) and forcing decoding at every usage site would make it inconvenient enough to cause programmers to use the session values instead?

That also explains why Apple could exclude abuse happening in the logs, which some commenters have refuted.

If they have all the JWTs, seeing if one had a different e-mail than the logged-in user should be fairly doable.

Oh. Ok, so you did have to have an existing logged in session for any account, then could leverage that to get the token for another account by changing out the email?

Ah. So this creates a valid JWT for any email you want, but it is now associated with your own apple account?

> but it is now associated with your own apple account?

On the backend, maybe they can look up who requested a token at a time.

But otherwise, no it doesn’t seem to be

This is certainly logged.

I don't have any way to confirm, but yes, this is what I interpreted from the article.