Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



QUERY 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.


Yeah, figured that out in thanks to another thread on here. I got confused as all the examples were primarily sql ones.


How 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 :)


It's just an example, not a production use case.


Yeah, I mean, I get that but eventually? no?


Why eventually? It’s a sad reality for quite a few of us here right now and has been for quite some time




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: