> wouldn't the sum of the operations require access to all data How you can access the data matters, and typically not all data (nor all views to that data) ar

> wouldn't the sum of the operations require access to all data How you can access the data matters, and typically not all data (nor all views to that data) are required to run the app. Some info should only ever travel one way (typically from the web server to the backend, like passwords, analytics, or payment data). There are whole categories of information that do not ever need to be queried in bulk by a legitimate user. > This is just security by obscurity, except if the attacker has access to the client code, it's not even very obscure. It's not like this approach in any way relies on that obscurity, but as a measure to increase time and effort required by the hacker, I'll take it. Just increasing the time spent figuring out how to query the backend gives site operators additional opportunities to spot that something is wrong. Compare this to the immeasurably small effort required to dump all SQL tables into a text file. > Why can't you do that from the database logs? Typically logs aren't analyzed in real time, and I'd hazard a guess in most cases they're not even analyzed at all. Most databases don't even keep an access log by default, and in many cases it's hard to implement one that is useful. > A query is just like an API call - you can raise flags if the frontend makes queries outside of a known pattern Theoretically: yes, practically: no. In case of SQL databases, this would practically mean communicating with the DB exclusively through stored procedures (or event handlers/filters in case of document databases), which is a poor man's version of what we're talking about in the first place. In practice, almost nobody uses their database in this way, because it's really painful and does not even offer that much protection.