[azalemeth]

Interesting article. I for one absolutely hate single page web applications. Amongst other things, it out-sources a lot of the computational load from the business to the customer, and they have a habit of riding roughshod over a user's browser preferences, patterns, and desires -- leading to a proliferation of grease monkey scripts and umatrix use amongst technical users and I suspect frustration among everyone else. Moreover, as this article shows, rather than exposing a finite number of "user data input" devices, you have to expose literally all your APIs and make them secure and robust. I just inherently think that's a larger attack surface.

[resonious]

I'm finding it hard to grasp the effective difference between an SPA and a traditional webpage when it comes to security. The only real difference is your Content-Type, right? SPAs usually serve more JSON, and traditional pages serve more HTML. "Oops I accidentally exposed the wrong API" is basically the same as "oops I accidentally failed to lock down /admin/orders". I think all of the examples in the article are not specific to SPAs or "APIs" at all, and can all occur on any public HTTP endpoint that does any kind of real work.

[marcosdumay]

In a server rendered site, the developers create pages with a complete model of the user interaction on their heads. On a SPA, the API tends to be data-driven, so the backend developers have no idea what users will access what data, and why.

There's nothing inherent about that. You can design a server rendered site using only generic data-driven pages, and you can design an SPA API with a concrete interaction model. But, for some reason, people tend to not do those.

[ridaj]

In theory yes, in practice I've observed many seasoned software engineers operate without being paranoid enough about the fact that APIs they publish can be hit by clients other than the one they designed.

[Winsaucerer]

Depends on your API, I think. API's are usually more flexible and powerful than the rendered pages that make use of them. At some point, we have to lock down the data. And in a server rendered multi-page website (henceforth just 'MPA'), that point is on each page, while for an SPA it's in the API.

In an SPA, we call the API to fetch x, y, & z to render it. In an MPA, we query the database to fetch x, y, & z to render it.

Since the query to the database is entirely server side, it does not need to be locked down in the same way that the API does.

Mentally, it's a lot easier to look at the /admin/orders page and say "should this user be able to see all this data that I can see is visible?". It's a lot harder to wrap your head around all the myriad ways that someone might call the API, and understand whether you've let anything slip through. With the MPA, those items that shouldn't be there should be pretty obvious, just by looking at the page and seeing what data is visible.

For an MPA, the data available to the client is all and only what is rendered on a page. For an SPA, it's all and only what is available through the API. You'll be looking at rendered pages frequently as you develop, but you will rarely (never?) be looking at the full possible output of the API.

Some people will lock down which queries can be called against the API in production. This can mitigate some of the issues here, and is probably good practice for websites that aren't intending to make their API available directly. Particularly GraphQL API's.

[unlimit]

I also always have the same tick at the back of my head. I have put off learning/playing around with all SPA technologies because of this.

To me it looks like we are increasing the surface area for a attack - again this is a hunch, a kind of smell test.

But I also see that react etc are running away with all job offers.

[mewpmewp2]

This would also depend on the implementation.