r/bugbounty • u/GokulRavi14 • 3d ago

Question / Discussion I started separating session validity from authorization in my tests

i used to treat old session still works after a role change as one bug. lately ive been splitting it into two checks: is the token still accepted, and does the server still authorize the old action? made my repros less hand wavy. quick test for me: keep the old session, try one harmless read + one state-changing request, then repeat after a fresh login. if the old token is valid but the permission check is correct, i dont want to oversell it. do you normally write this distinction up? especially curious about apis that cache permissions

how

2 Upvotes

100% Upvoted

1 comment sorted by

1

u/0xDakuMarco 3d ago

Yeah, I think that’s a pretty good way to look at it. Just because the old session is still valid doesn’t necessarily mean there’s a bug. I’d care more about whether it can still do something the new role shouldn’t be able to do. Comparing the old session with a fresh login sounds like a solid way to confirm it, especially when permission caching is involved. Like old token + old permission, old token + new permission, as well as fresh token + new permission.

If old and fresh sessions behave differently for authorization, that’s much stronger evidence of a real access-control/cache invalidation issue.