I'm on the faculty at Boston University in the computer science department, where I teach software engineering, intro courses, and application architecture and development. Also a bit of a Deadhead.
A really good point; maybe one of our security wonks will drop in and offer an opinion.
One approach might be to use the JWT in combination with a session identifier which changes on each request/response pair. The client would need to present both the signed JWT and the correct session identifier; both would be sent on the request automatically and both would be deleted when the browser or tab is closed. On the server side, seeing the same session identifier twice would be an error and would indicate a possible attack.
Also, requiring HTTPS would reduce the chance of a man-in-the-middle or sniffing attack.
In your case, where some data needs to be visible on the client, I think I'd still use the secure JWT and then send a second object back on the response with the data.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
A really good point; maybe one of our security wonks will drop in and offer an opinion.
One approach might be to use the JWT in combination with a session identifier which changes on each request/response pair. The client would need to present both the signed JWT and the correct session identifier; both would be sent on the request automatically and both would be deleted when the browser or tab is closed. On the server side, seeing the same session identifier twice would be an error and would indicate a possible attack.
Also, requiring HTTPS would reduce the chance of a man-in-the-middle or sniffing attack.
In your case, where some data needs to be visible on the client, I think I'd still use the secure JWT and then send a second object back on the response with the data.