3 ms·

That doesn’t prevent injection, and the solution to injection attacks is using parameterized queries and prepared statements, not switching to MongoDB. Plus ORM

by jolux 6y ago

That doesn’t prevent injection, and the solution to injection attacks is using parameterized queries and prepared statements, not switching to MongoDB. Plus ORMs (really query builders) already provide behavior like this against SQL databases anyway.

throwaway894345 6y ago
And those ORMs have to deal with the SQL composability issues as well, often to the effect of dramatically poorer performance.
- romanoderoma 6y ago
  I think Elixir ECTO does a very good job at that https://hexdocs.pm/ecto/Ecto.Query.html#module-composition https://hexdocs.pm/ecto/Ecto.Query.html#module-composition
- jolux 6y ago
  You’re right, using a query layer to access an SQL database is still using an SQL database. You need to know what you’re doing with your queries. The important part is not the object mapping and model tracking part, it’s the part that allows you to build typed queries in the native language. Diesel for Rust is a great example, as is Ecto in Elixir.
013a 6y ago
That's fair, but I didn't say it prevents injection: I said it prevents most injection attacks. MongoDB is absolutely still capable of being vulnerable to injection; its just harder, because it requires the client to provide an object which is parsed by your application with no data validation. In other words, SQL is vulnerable to injection by-default, because everything is a string, while you have to opt-in to being vulnerable with MongoDB, by writing your application to parse user input with no schema. In reality, do applications do this? Hell yeah. Wire up a basic Express API, have it auto-parse any JSON its given, pass it straight to mongo, you'll be vulnerable. But, a backend which has any kind of type safety or API schema or GraphQL or something like that will be safer on mongodb than one with all that, on a SQL database with no ORM or parameterized queries or prepared statements.
- jolux 6y ago
  The difference as minimal. If you know the first thing about what you're doing with SQL you will use prepared statements. It's not some sort of arcane feature that nobody understands.

by jolux 6y ago

throwaway894345 6y ago

And those ORMs have to deal with the SQL composability issues as well, often to the effect of dramatically poorer performance.

romanoderoma 6y ago
I think Elixir ECTO does a very good job at that https://hexdocs.pm/ecto/Ecto.Query.html#module-composition https://hexdocs.pm/ecto/Ecto.Query.html#module-composition
jolux 6y ago
You’re right, using a query layer to access an SQL database is still using an SQL database. You need to know what you’re doing with your queries. The important part is not the object mapping and model tracking part, it’s the part that allows you to build typed queries in the native language. Diesel for Rust is a great example, as is Ecto in Elixir.

013a 6y ago

That's fair, but I didn't say it prevents injection: I said it prevents most injection attacks. MongoDB is absolutely still capable of being vulnerable to injection; its just harder, because it requires the client to provide an object which is parsed by your application with no data validation. In other words, SQL is vulnerable to injection by-default, because everything is a string, while you have to opt-in to being vulnerable with MongoDB, by writing your application to parse user input with no schema. In reality, do applications do this? Hell yeah. Wire up a basic Express API, have it auto-parse any JSON its given, pass it straight to mongo, you'll be vulnerable. But, a backend which has any kind of type safety or API schema or GraphQL or something like that will be safer on mongodb than one with all that, on a SQL database with no ORM or parameterized queries or prepared statements.

jolux 6y ago
The difference as minimal. If you know the first thing about what you're doing with SQL you will use prepared statements. It's not some sort of arcane feature that nobody understands.