Reading about JWT I've come with a very interesting topic, which is the jwt tokens vulnerability if they're not properly secured when using with wordpress.
So, the thing is that storing the token in a cookie would make it vulnerable to XSS or CSRF attacks but the docs of the wp-api-jwt-auth says this:
Once you get the token, you must store it somewhere in your application, e.g. in a cookie or using localstorage.
Is this correct? Wouldn't it be vulnerable?
Your session/auth tokens will always be exposed to some level of risk when stored on the client machine... for example, if you have physical access to the person's browser and they are logged into a service, you could use browser developer tools to view all their cookies and local storage key/value content.
HTTP-Only Cookies and Local Storage are not inherently insecure, but can be vulnerable if there is some other exploitable functionality on your website.
So there's some things you can do to mitigate the risk...
Short-lived session tokens will help to mitigate risk inherent from stolen tokens by reducing the time an attacker has to take advantage of the stolen token. The less time they can exploit a stolen token, the better.
To protect your token from Cross-Site Scripting (XSS) as a cookie, set the cookie to HTTP-Only, so that the browser won't allow JavaScript to read the cookie. This is a property set on the cookie header itself.
XSS attacks are a little trickier with local storage. Both local storage and cookies are protected by allowing only access to code loaded from the same domain. So if the script injection originates from code loaded on the same domain the local storage value originates on, then it may be vulnerable.
You can help protect cookies and local storage by carefully managing where functional code and user-generated content load from, but this is a rather advanced technique. It takes some careful consideration.
Cross-Site Request Forgery (CSRF) attacks should not expose local storage values, but can expose content that is protected by cookie values.
CSRF works by loading content from your domain, on an attacker's page. With your website properly configured, Cross-Origin Resource Sharing (CORS) will help protect content/actions that are typically at-risk of exploit by CSRF. CORS is not fool-proof, though. So it's usually better to use a stronger mitigation like a CSRF token.
