The attack surface mostly has to do with input validation. Good security presupposes that you validate all input and escape all output. That means that you have to be aware of the semantics of all server I/O, which is difficult to automate effectively.
Regarding SEO, the point is irrelevant to most SPA's. If your data is private, whether google can index it is not a relevant topic.
I suspect the validation probably should be developed twice. We build our server-side framework to be client-agnostic, published as web services. It is reused across multiple clients: a full desktop web front-end, a mobile web front-end, and a set of third-party interfaces. The use cases and needs of every front-end are very different, so I have a difficult time imagining a way that the validation logic could automatically be integrated into the different front-ends.
Comments
The attack surface mostly has to do with input validation. Good security presupposes that you validate all input and escape all output. That means that you have to be aware of the semantics of all server I/O, which is difficult to automate effectively.
Regarding SEO, the point is irrelevant to most SPA's. If your data is private, whether google can index it is not a relevant topic.
I suspect the validation probably should be developed twice. We build our server-side framework to be client-agnostic, published as web services. It is reused across multiple clients: a full desktop web front-end, a mobile web front-end, and a set of third-party interfaces. The use cases and needs of every front-end are very different, so I have a difficult time imagining a way that the validation logic could automatically be integrated into the different front-ends.