SPAs, client based-REST, and other architectures that expose data/JSON on the Web have probably increased vulnerabilities by an order of magnitude.
Now you've got data moving off of the server that would have normally been selectively parsed/rendered server-side. It's also easy to use marshalling tools/framework features that serialize entire domain objects, which contain sensitive IDs/data that is then inadvertently leaked. You really have two views to think about; one not as visible.
Not to mention, it can take a lot of additional effort and forethought to expose what you need on the client, so that the UI is robust and responsive, but you're not exposing too much.
And, frankly, some devs naively have in mind the common user, 90% of whom couldn't go beyond what's rendered. So, they are falsely comforted by the idea that the data isn't being shown explicitly in the browser.
Ironically, of course, it's exactly the other 10% they need to be thinking about.
I don't think the problem is in architecture. API might be sometimes easier to analyze because it usually has a detailed description, often even in machine-readable form.
> It's also easy to use marshalling tools/framework features that serialize entire domain objects, which contain sensitive IDs/data that is then inadvertently leaked.
This is just poor code quality. Sensitive data can be hidden in HTML attributes and inline scripts too.
The same thing happens when the data is serialised into HTML rather than JSON. Sensitive primary keys get encoded in weird places, like element IDs or class names, even in embedded JS within the page.
I agree with your premise but filtering fields selected by the database, or serialized into JSON, isn't exactly an unsolved problem. It's probably easier to muck up true... but it's not hard to prevent either.
Now you've got data moving off of the server that would have normally been selectively parsed/rendered server-side. It's also easy to use marshalling tools/framework features that serialize entire domain objects, which contain sensitive IDs/data that is then inadvertently leaked. You really have two views to think about; one not as visible.
Not to mention, it can take a lot of additional effort and forethought to expose what you need on the client, so that the UI is robust and responsive, but you're not exposing too much.
And, frankly, some devs naively have in mind the common user, 90% of whom couldn't go beyond what's rendered. So, they are falsely comforted by the idea that the data isn't being shown explicitly in the browser.
Ironically, of course, it's exactly the other 10% they need to be thinking about.