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:
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:
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