7 ms·
SQL-like queries in the request body seem like a bad idea, what are the security implications and how do we protect against it? Or will the QUERY method end up
by ta-run 3y ago
SQL-like queries in the request body seem like a bad idea, what are the security implications and how do we protect against it?
Or will the QUERY method end up with the same fate as GraphQL - wherein it's more effective and "secure" in a server-to-server setup and the client only deals with REST.
- sarthak-ag 3y agoIt's just an example, not a production use case.
- crooked-v 3y agoQUERY has nothing to do with the actual contents of the request body beyond "it is hashable text". That could be JSON, GraphQL, weird SQL cousins, or anything else.
- ta-run 3y agoYeah, figured that out in thanks to another thread on here. I got confused as all the examples were primarily sql ones.
- 9dev 3y agoHow is that less secure than a REST API Frontend to an SQL database, like PHPMyAdmin? I don’t think anyone suggests we all open our databases to the web; but if you choose to do so, or if you happen to work on a modern database, like Elasticsearch or CouchDB, which accept queries via HTTP, now there’s a better way to implement queries in regard to caching. That being said: I’ve been wondering for a long time what a backend API could look like that used SQL instead of JSON as the query format - not to pass it to the database verbatim, but with an application layer that speaks SQL, applies business logic, queries the database, and responds in SQL. That would save a lot of reinvented wheels in terms of filtering, ordering, joining, and so on, and give developers a query language they already know. And suddenly, having a QUERY method available sounds useful, too :)