I was reading articles about `JWT` security in SPA apps, but got confused about it being prone to many types of attacks, and unintuitively hard to grasp and set up.

As far as I am aware, this whole thing with the user-friendly security is about a user staying logged in even after a browser restart, and about still being protected from CSRF attacks.

I read some crazy approaches using localStorage, cookies, or in-memory values, and about setting some flags like httpOnly on cookies, and some headers in a browser, while being vulnerable to stuff like XSS or CSRF attacks if not set properly.

So, my question is if the following security scheme would work?:

1. store JWT token anywhere on user's device (localStorage, cookies, whatever,...) (as a public information, readable by anyone)
2. backend would return an anti-CSRF header on each request
3. app would store and refresh the header value in a memory every time and consecutively send it to prove being the originally logged-in user
4. an attacker could eventually get the JWT and/or try some XSS or CSRF, but it would be useless, because he wouldn't know the anti-CSRF header value

(Note that with such an approach I basically consider the JWT token to represent authentication, and the CSRF header to represent authorization.)

CodePudding user response：

the answer to your question is no.

If i manage to do a XSS on your site, i will have access to everything that your javascript has access to and that includes both the CSRF token, and the JWT. Its your javascript that will run my malicious javascript, which means i have all access to everything you have.

JWT tokens as session trackers are very bad from many perspectives. Cookies have been around since Netscape created them back in the late 90s. They have been enhanced with several security features like HttpOnly flags etc which JWTs just don't have.

JWTs are good if you have server to server stateless communication, since you can include claims, which add extra information so that the server doesn't need to do extra calls to for instance an issuers /userInfo endpoint.

Server to server communication is also usually done in secured networks so the risk for token stealing or MITMs are reduced.

Security is hard, much harder than many think, there is no one "easy solution" you need to protect your sites from multiple different attacks, and combination of these.

You should NEVER build your own custom solutions, because there is always people smarter that can break custom solutions.

And you should constantly consult the OWASP Cheat Sheet series which tries to gather everything you should think about when building modern web pages.