Currently the JsonWebToken ("JWT") is returned without the HttpOnly flag. Consequently, client side script can access the JWT. This introduces a theoretical XSS vulnerability.

Consider the security implication of allowing client side access to the JWT in this scenario:

A bad actor somehow injects a script a client-side script into your app (how it got in could be a wide range of possibilities, given the flexible nature of feathers framework. e.g., somehow some bad client JS code ends up being inserted in a database, and is now served in all client requests). In the script, the hacker inspects localStorage, read the feathers-jwt cookie (if httpOnly is false), and send a POST request to www.badactor.com/xss, and now have a copy of the end user's JWT. The hacker can then issue requests to the application server, authenticated as the end user.

This example illustrates the broader concern of authentication architecture within Feathers, specifically the lifecycle of the JSON Web Token. It's critical to be highly specific in the implementation to mitigate certain attack vectors. JWT's are permitted to be transported and stored through a number of options in feathers, e.g., headers, cookies, query parameters, localStorage, etc. A unique set of security concerns are introduced to each application. The documentation does address the tradeoffs of the transports.

If you set HttpOnly to true, and enforce an architectural pattern of limiting the JWT to cookies, you can effectively mitigate XSS. If the JWT is placed in localStorage, the XSS vector isn't mitigated because localStorage can be read by client side script (which is kind of the point of localStorage, making it a less than ideal place for JWT's to live).