Sanitation hooks for each db type

[marshallswain]

From @ekryski's feathersjs-ecosystem/authentication#132 (comment)
See more comments at feathersjs/feathers#280 (comment)

One thing we may want to do though, is have a built in hook that runs on every POST, PATCH, PUT request and escapes script code rather than relying on making sure the ORM or the developer handle it.
We ought to provide this for at least the db adapters that don't have an ORM that does it already. I'm pretty sure Mongoose takes care of this, but we ought to check everything.

Must be explicitly added.
Each DB type will need its own sanitation hook.

[ekryski]

I'm not sure if every DB type will need it's own sanitization hook. We should be able to just use 1 hook for all the adapters.

[marshallswain]

I see. I was thinking that we would filter/sanitize the data, but that's apparently not a good idea.

[ekryski]

Hmmm. You are probably right there. Shoot. I was hoping to avoid having to update every adapter.

[daffl]

Does this have to be built in? If we were recommending a full stack solution then I'd say yes but at the moment I'm not sure. Even in the getting started guide we are already showing how to do basic sanitization and the ORMs should also take care of that.

[marshallswain]

I think it would be really nice of us to point out which adapters already do this and which don't. Just include a pro tip on each adapter's docs, or something.

[ekryski]

Ya I agree with @marshallswain at a minimum that. Going along with "helping people be successful by default", for non ORMs we should have a hook that people can use to sanitize/escape unsafe content and make sure to specifically mention escaping content in the sanitization section. There are so many people that don't understand CSRF and XSS attacks we should do what we can to help prevent them imho.

[petermikitsh]

Even a seasoned developer can still build apps with CSRF and XSS vulnerabilities. I like the idea of having this at the service layer. My abstracting sanitization away from the ORM layer, developers can more easily switch between different ORM's and databases. From the docs, I get the vibe that's a core tenant of service hooks.

[marshallswain]

It seems to me like we would have to create database-specific implementations, so upon changing databases you would remove the MongoDB escaper and add the MySQL escaper, for example.

[petermikitsh]

Oh ok! As long as it's trivially easy to specify the add-on (a couple lines of code), it would still jive with the concept of effortlessly switching a service's ORM / DB.

[daffl]

I am going to close this issue. Please reopen if it is still relevant but I think for now we should focus on generating more secure applications by default (e.g. default filters, secure hooks etc.) and after that see where the one-model approach will take us for this.