If you follow OWASP recommendations, then you should already be safe enough ;-)

To answer your question, the 'token system' @josfaber is mentioning is more likely to be (but he'll correct me if this was not his idea) a CSRF token system, not a session-one, and you might have both:

• a JWT (or similiar) token to store the session id (http header, or cookie, depending on your various systems)
• a CSRF token to validate any request accessing potentially sensitive data (ie, not required to load static assets or generic files, but required to load anything from a db).

If you follow the 'by-the-book' way to do CSRF protection, you cannot send parallel requests. You might - for private but not critical data - want to consider small variation on that: once a CSRF token has been consumed, and a new one generated, you could have a very short 'grace period' during which other request using this token are still considered valid. This lets you use a CSRF token multiple times for parallel requests, for instance:

• you use token A with req1.
• while Req1 answer has not been received (hence no new token), you send req2 with the same token A.
• Server respond to req1 and send a new token B.
• Client receive it.
• Server receive req with the old token A. Traditional CSRF would reject this request. If the consumption time of token A is very close to the reception time of req2 by the server, you might still consider it valid.
• Server respond to req2 without no new token (because you only generate a new token when you invalidate one, and token A has already been invalidated).
• Client receive response to req2, without a token, and so still keep the token B has the current one.
• Client send rep3 with token B.
• and so on...

For critical applications, this is a very small security flaw, because a token should only be valid once. But for daily use, this is usually a nice compromise. Assuming you're using https (and that should be one of your very first steps, with HSTS), exploiting this small flaw (compared to standard CSRF) would imply that the malicious user is performing a MIIM attack, to re-use a CSRF token during this very small grace period added (we're talking of something like 10 to 500ms depending on your use-cases and settings). This is a very very small risk compared to the huge performance gain brought by enabling parallel requests.

side note - We also considered having a 'bag' of one-time usage CSRF token: when you open the connection, the server respond with a few tokens, each only valid exactly only one time. I would prefer this approach. For some inner constraints we finally had to choose the grace-period trick, and it passes or sec-specialists checks, but I still find a bag of csrf token easier: each request consume a token, and the response comes back with a new token to put in the bag for a next request. This also solves the problem of parallel requests and race between them.

Hope this helps