1

I will explain first what I mean by "back-end controlled" and "front-end controlled".

I have been developing web applications for many years with php frameworks. It was always with the php back-end handling all the logic and also sending the "views" to the client. This is what I call a "back-end controlled web application".

Now I understand the advantage of separation of concerns of what I call a "front-end controlled application" where the back-end never sends the html views to the client. It only sends data and the view is completely handled by the client (angularjs, vuejs, ...). This allows the same back-end (which is now just a REST API) to be used also by a mobile application eventually.

So now I explained what I mean by "back-end controlled web application" and "front-end controlled web application" and explained that I understand some of the advantages of front-end controlled web applications. Now I will mention some of the doubts that I have regarding this, and I am expecting answers to these doubts because I am sure there are answers that I am just not aware of:

  1. In a back-end controlled web application the forms are Cross-Site Request Forgery protected (at least when you use a decent back-end framework). Behind the scene a token is added to the session to confirm that the request comes from the same application form. How do you do that in a front-end controlled application?

  2. I have seen front-end controlled applications making multiple requests for the same page (one request for authentication, and a request for each component (say section of the web page)). On the other hand we know that it is a good practice to "browserify" our assets (css and js) to reduce the number of requests to the server. So, on one hand making as few requests to the back-end as possible is a good practice but on the other hand, with front-end controlled applications, It is very common to see a page that has 5 requests for example to the back-end. The same page would have needed only 1 request if it was a back-end controlled application.

Thanks

Karim Mtl
  • 1,223
  • 3
  • 11
  • 39
  • Sorry; what's the question? (Number 2 that is.) – Progrock Oct 29 '16 at 18:21
  • You are confusing initial page load optimization with data requests. Also not hard to implement csrf with ajax – charlietfl Oct 29 '16 at 19:37
  • @Progrock, 1 and 2 are the questions/doubts about things that are not clear for me. – Karim Mtl Oct 29 '16 at 22:33
  • 1
    @charlieft, I understand page load of css and js different from loading json data, I am just wondering why in one case multiple requests are avoided and in the other case encouraged. – Karim Mtl Oct 29 '16 at 22:39

1 Answers1

0

  1. I researched again on csrf and IIUC, XHRs are better against csrf since:

    • modern browsers automatically add origin headers to all XHRs, which blocks all requests from unexpected domains (together with allow-origin config on server-side).

    • And we can do even more by manually adding csrf tokens to js code when rendering pages on server-side (to be sent with requests in XHRs later). The tokens inside js code are impossible for the attacker to acquire. EDIT: this is not unique for single-page apps, I've learned that traditional server-rendered sites can do the same by writing the token in a hidden field in a form after reading the Synchronizer token pattern chapter of wikipedia. Rather than <input type="hidden" name="csrftoken" value="..." />, I thought of <script>var csrfToken={{server.token()}}</script> ({{}} is the server side template). The former is used when the form is posted, mine is used when js code sends XHRs. My idea is a mix of the Synchronizer token pattern chapter and its next in the wikipedia page. By these means, if our site is XSS free, the attacker won't be able to get the token in the session/page/js, and the request he tricks the user's browser to send will fail without the token.

      Which leads to: modern single-page apps are XHR heavier than traditional web apps, which utilizes full-page server-side render with js-manipulated view changes (with XHRs) on different occasions. And thus, more secure.

  2. 1 request is definitely better than 5, if only for request counts' sake. Here we make the trade-off: By adding a few traffic to loading the page, we gain:

    • As OP addressed, server interfaces reusable by mobile apps since they return pure data rather than htmls which mix data with webpages.

    • Better separation of concerns for both front and back ends. Backend developer writes smaller single-functionality interfaces. And even better for frontend developer: views, styles, interaction logic scripts (as we can see in .vue files) are all organized in components, fewer things to worry about, happier we can be.

      Therefore I think the trade is totally worth it.

JJPandari
  • 3,454
  • 1
  • 17
  • 24
  • could you explain what you mean by sending csrf tokens from js to back-end when the page is rendered in server side? Any link explaining this? – Karim Mtl Nov 01 '16 at 16:24
  • @KarimMtl Edited that section. Also, your question may be essentially the same as http://stackoverflow.com/questions/21862054/single-page-application-advantages-and-disadvantages – JJPandari Nov 02 '16 at 13:33