IP address binding may not generally best practice as the IP address from users on or tethering to mobile devices is apt to change frequently when roaming.

It's admittedly hard to find good alternatives if the user isn't logged in. I did hesitate for this, as it does cause false negatives. I just wanted to add that there can be other data which can work. I'm happy to drop it if it doesn't add much.

Also, according to the spec, if you try to use a session ID and the session is no longer valid and your request is rejected, you get foreced to re-initialize. That can break the state on a stateful server though, so not exactly ideal, but for most scenarios it would just continue to work.

I was about to add LGTM but tripped over the same thoughts on IP address in the concluding paragraph. Using an IP address in this way is such an unreliable anti-pattern that the mention of it could raise doubt on the credibility of the remainder of the guidance, which is otherwise solid. If it's possible to remove this example, the rest looks good.

Should we move the diagram so that it's next to the description? I also wonder if we should have the "Session Hijack Impersonation" first since it's the simpler variation.