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?

1 Answer 1


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 Tokens

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.

  • Shouldn't be HTTPS-only cookie? Could i protect me from CSRF attacks rejecting all external requests with CORs?
    – alex55132
    Jan 27, 2019 at 13:06
  • 1
    I have no intention of covering all possible protection here, just a summary. “secure” option is separate from “http-only” on cookies. Secure cookies won’t be transmitted without https. Http-only keeps javascript from seeing it in the browser. The browser just stores t and sends it to the server with requests.
    – nbering
    Jan 27, 2019 at 15:35
  • 1
    CORS doesn’t handle all cases. For example, CORS is focused on XHR. It won’t block an HTTP request generated by an image or script tag.
    – nbering
    Jan 27, 2019 at 15:41
  • Could secure cookies be read from the browser with javascript?
    – alex55132
    Jan 27, 2019 at 18:29
  • It’s my understanding that you could have a secure cookie that is not http-only and as such would be readable from Javascript by same-origin code.
    – nbering
    Jan 27, 2019 at 23:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .