Sails is committed to providing a secure framework, and quickly responding to any suspected security vulnerabilities. Contributors work carefully to ensure best practices, but we also rely heavily on the community when it comes to discovering, reporting, and remediating security issues.
Security announcements are sent to the Sails newsgroup, and are released roughly at the same time NSP advisories are issued.
If you believe you've found a security vulnerability in Sails, Waterline, or one of the other modules maintained by the Sails core team, please send an email to critical at sailsjs dot io. In the spirit of responsible disclosure, we ask that you privately report any security vulnerability at that email address, and give us time to patch the issue before publishing the details.
A security vulnerability is any major bug or unintended consequence that could compromise a Sails.js app in production.
For example, an issue where Sails crashes in a development environment when using non-standard Grunt tasks is not a security vulnerability. On the other hand, if it was possible to perform a trivial DoS attack on a Sails cluster running in a production environment and using documented best-practices (a la the Express/Connect body parser issue), that is a security vulnerability and we want to know about it.
Note that this definition includes any such vulnerability that exists due to one of our dependencies. In this case, an upgrade to a different version of the dependency is not always necessary: for example, when Express 3 deprecated multipart upload support in core, Sails.js dealt with the feature mismatch by implementing a wrapper around the
multipartymodule called Skipper.
Please respect the core team's privacy and do not send bugs resulting from undocumented usage, questions, or feature requests to this email address.
When you report a vulnerability, one of the project members will respond to you within a maximum of 72 hours. This response will most likely be an acknowledgement that we've received the report and will be investigating it immediately. Our target patching timeframe for most security vulnerabilities is 14 days.
Based upon the nature of the vulnerability, and the amount of time it would take to fix, we'll either send out a patch that disables the broken feature, provide an estimate of the time it will take to fix, and/or document best practices to follow to avoid production issues.
You can expect follow-up emails outlining the progression of a solution to the vulnerability along with any other questions we may have regarding your experience.
No. The Sails framework is available under the MIT license, which does not include a service level agreement. However, the core team and contributors care deeply about Sails, and all of us have websites and APIs running on Sails in production. We will always publish a fix for any serious security vulnerability as soon as possible-- not just out of the kindness of our hearts, but because it could affect our apps (and our customer's apps) too.
For more support options, see http://sailsjs.com/support.