Important: This is the documentation for a previous version of Feathers.
For the latest documentation please visit docs.feathersjs.com.
We take security very seriously at Feathers. We welcome any peer review of our 100% open source code to ensure nobody's Feathers app is ever compromised or hacked. As a web application developer you are responsible for any security breaches. We do our very best to make sure Feathers is as secure as possible.
Where should I report security issues?
In order to give the community time to respond and upgrade we strongly urge you report all security issues to us. Send us a PM in Slack or email us at email@example.com with details and we will respond ASAP. Security issues always take precedence over bug fixes and feature work so we'll work with you to come up with a resolution and plan and document the issue on Github in the appropriate repo.
Issuing releases is typically very quick. Once an issue is resolved it is usually released immediately with the appropriate semantic version.
Here are some things that you should be aware of when writing your app to make sure it is secure.
- Escape any SQL (typically done by the SQL library) to avoid SQL injection.
- Events are sent by default to any client listening for that event. Lock down any private events that should not be broadcast by adding filters. Feathers authentication does this for all auth services by default.
- JSON Web Tokens (JWT's) are only signed, they are not encrypted. Therefore, the payload can be examined on the client. This is by design. DO NOT put anything that should be private in the JWT
payloadunless you encrypt it first.
- Don't use a weak
secretfor you token service. The generator creates a strong one for you automatically. No need to change it.
- Use hooks to check security roles to make sure users can only access data they should be permitted to. We've provided some built in authorization hooks to make this process easier (many of which are added by default to a generated app).
Some of the technologies we employ
- Password storage inside
feathers-authenticationuses bcrypt. We don't store the salts separately since they are included in the bcrypt hashes.
- JWT is used instead of cookies to avoid CSRF attacks. We use the
HS512algorithm by default (HMAC using SHA-512 hash algorithm).
- We run nsp as part of our CI. This notifies us if we are susceptible to any vulnerabilites that have been reported to the Node Security Project.
As with any web application you need to guard against XSS attacks. Since Feathers persists the JWT in localstorage in the browser, if your app falls victim to a XSS attack your JWT could be used by an attacker to make malicious requests on your behalf. This is far from ideal. Therefore you need to take extra care in preventing XSS attacks. Our stance on this particular attack vector is that if you are susceptible to XSS attacks then a compromised JWT is the least of your worries because keystrokes could be logged and attackers can just steal passwords, credit card numbers, or anything else your users type directly.
For more information see: