3 ms·

The brower is not a trusted computing environment. Any expressive power you put, intentionally or not, in the hands of your Front End developers, you also put

The brower is not a trusted computing environment. Any expressive power you put, intentionally or not, in the hands of your Front End developers, you also put in the hands of potentially hostile users. The console is just a click away. This is not the case in hypermedia based systems where content is generated on the server side. The server side is a trusted computing environment and, there, you can give developers a fully developed query language such as SQL without risking it falling into the wrong hands (mod coding errors by your developers, of course.) This is a powerful argument for SSR and for hypermedia in general.

digisign 5y ago
Makes sense. Assuming an authenticated connection, wouldn't it be pretty obvious which account was attempting shenanigans?
- recursivedoubts 5y ago
  I mean, I guess so. Typically, in security discussions I've had in the past, the fact you can tell which account was used to compromise your system was not considered a strong argument for a particular approach.
  - digisign 5y ago
    Oh, I thought the concern was from a denial-of-service angle. Compromise would imply the account has access to things it shouldn't. Which while possible should be taken care of, and if not, a rest api isn't going to prevent. (I'm personally thinking of a paid account of a multi-tenant system, so query limits and punitive billing would probably eliminate the worst DOS issues.)
    - recursivedoubts 5y ago
      My point is that giving expressive power to your front end developer puts that expressive power in the hands of an end user as well. So you have to be very careful with that power, and I assert that most people are not. Facebook apparently uses an exhaustive query whitelist to lock down their GraphQL end points, but the vast majority of people jumping on the GraphQL bandwagon aren't going to do that, and likely have little understanding of the security implications for not doing it. A truly REST-ful hypermedia API eliminates this issue by moving the construction of the hypermedia server side, which is a trusted computing environment and which allows you to give the developers a fully developed and arbitrarily powerful query language like SQL. Doing so does not put that query language in the hands of end users, in contrast with things like GraphQL.
      - digisign 5y ago
        Given the limits I was thinking, not whitelists but time, request, and complexity limits, I don't see a huge difference. Theoretically it does sound more dangerous, particularly for a free service, but you'll have to be careful either way, no getting around it.
deleted 5y ago
[deleted]

digisign 5y ago

Makes sense. Assuming an authenticated connection, wouldn't it be pretty obvious which account was attempting shenanigans?

recursivedoubts 5y ago
I mean, I guess so. Typically, in security discussions I've had in the past, the fact you can tell which account was used to compromise your system was not considered a strong argument for a particular approach.
- digisign 5y ago
  Oh, I thought the concern was from a denial-of-service angle. Compromise would imply the account has access to things it shouldn't. Which while possible should be taken care of, and if not, a rest api isn't going to prevent. (I'm personally thinking of a paid account of a multi-tenant system, so query limits and punitive billing would probably eliminate the worst DOS issues.)
  - recursivedoubts 5y ago
    My point is that giving expressive power to your front end developer puts that expressive power in the hands of an end user as well. So you have to be very careful with that power, and I assert that most people are not. Facebook apparently uses an exhaustive query whitelist to lock down their GraphQL end points, but the vast majority of people jumping on the GraphQL bandwagon aren't going to do that, and likely have little understanding of the security implications for not doing it. A truly REST-ful hypermedia API eliminates this issue by moving the construction of the hypermedia server side, which is a trusted computing environment and which allows you to give the developers a fully developed and arbitrarily powerful query language like SQL. Doing so does not put that query language in the hands of end users, in contrast with things like GraphQL.
    - digisign 5y ago
      Given the limits I was thinking, not whitelists but time, request, and complexity limits, I don't see a huge difference. Theoretically it does sound more dangerous, particularly for a free service, but you'll have to be careful either way, no getting around it.

deleted 5y ago

[deleted]