2 ms·

> I can’t tell what their objection to graphql is and why hypermedia API’s are less of a security concern. GraphQL increases client-side expressiveness of an A

> I can’t tell what their objection to graphql is and why hypermedia API’s are less of a security concern. GraphQL increases client-side expressiveness of an API, but it also puts that power in the hands of potentially hostile users who, for example, could open up a console and start crafting dangerous queries (showing data that shouldn't be allowed, creating expensive queries that DoS your system, etc.) Since with hypermedia APIs the UI is produced server side, you can, when producing the HTML, have full access to something like SQL. The server side is a trusted computing environment. Facebook whitelists their GraphQL queries to avoid security issues, but many developers don't even realize that it is one. > And their example with json API’s and close coupling doesn’t address the fact that adding a field doesn’t break backwards compatibility In my example, I remove functionality.

ec109685 4y ago
Anyone can watch the traffic go back and forth and see all the hypermedia urls that are present in the response, just like they could hypothetically see the graphql console. However, the smart way to implement graphql is to map queries to a restful url (that’s a simple tool to build), so that the full graph isn’t exposed to end users.
- recursivedoubts 4y ago
  Again, facebook whitelists every query. Hypermedia URLs are typically specialized and don't expose general query functionality, whereas, as its expressiveness increases, GraphQL approaches the expressiveness of SQL. That's the whole point: you don't want to have to make back end changes to support new front end features. The more powerful you make your GraphQL-based API, the more dangerous the security implications are. The less powerful you make it, the more it fails to address the fundamental problem of requiring back end changes to support front end needs. It boils down to the fact that you simply can't increase the expressiveness of an untrusted computing environment like the browser without increasing security risk, whereas on the server side you can hand full SQL-style query access to your developers.
  - ec109685 4y ago
    Whitelisting doesn’t limit expressiveness at all. It’s part of their build system so it’s a very easy issue to address (especially if you are okay with a manual mapping file).

ec109685 4y ago

Anyone can watch the traffic go back and forth and see all the hypermedia urls that are present in the response, just like they could hypothetically see the graphql console. However, the smart way to implement graphql is to map queries to a restful url (that’s a simple tool to build), so that the full graph isn’t exposed to end users.

recursivedoubts 4y ago
Again, facebook whitelists every query. Hypermedia URLs are typically specialized and don't expose general query functionality, whereas, as its expressiveness increases, GraphQL approaches the expressiveness of SQL. That's the whole point: you don't want to have to make back end changes to support new front end features. The more powerful you make your GraphQL-based API, the more dangerous the security implications are. The less powerful you make it, the more it fails to address the fundamental problem of requiring back end changes to support front end needs. It boils down to the fact that you simply can't increase the expressiveness of an untrusted computing environment like the browser without increasing security risk, whereas on the server side you can hand full SQL-style query access to your developers.
- ec109685 4y ago
  Whitelisting doesn’t limit expressiveness at all. It’s part of their build system so it’s a very easy issue to address (especially if you are okay with a manual mapping file).