4 ms·

Wouldn't users be able to tamper with their own data? Seems like another attack vector.

• eximius 8y ago
  If you write web apps, you should be used to treating user input as hostile. You just need to write your application with a clear perimeter around user supplied input.
  • needz 8y ago
    Let's say the web app is a game and it keeps track of your high score when you play it, if the high score is stored somewhere you have complete control over, what's to stop someone from modifying that score? Substitute high score for any variable a server tracks about a user that isn't explicitly supplied by that user.
    • eximius 8y ago
      The only way to prevent cheating in a game is to run the code on the server based on transmitted user actions. Even with a server side DB, they could lie about their results or hack the game to do better.
• gojomo 8y ago
  I don't notice any authorization model in this, where (for example) you could grant a service read/write on a portion of your data but commit yourself to read-only access. But maybe it's in there, or possible. If that were a part of the conventions, or even if it isn't, services could sign their own versions of data in legal states – as with signed/encrypted cookies. Then out-of-agreement edits could be detected, and possibly rejected as errors, rather than causing other surprises. (This could make for some ugly partial-failure/unexpected-state cases, though.)