I asked something kind of similar on stackoverflow with a particular piece of code however I want to try to ask this in a broader sense.So I have this web application that I have started to write in backbone using a Single Page Architecture (SPA) however I am starting to second guess myself because of security.  Now we are not storing and sending credit card information or anything like that through this web application but we are storing sensitive information that people are uploading to us and will have the ability to re-download too.The obviously security concern that I have with JavaScript is that you can't trust anything that comes from JavaScript however in a Backbone SPA application, everything is being sent through JavaScript. There are two security features that I will have to build in JavaScript; permissions and authentication.The authentication piece is just me override the Backbone.Router.prototype.navigate method to check the fragment it is trying to load and if the JavaScript application.session.loggedIn is not set to true (and they are not viewing a none authenticated page), they are redirected to the login page automatically.  The user could easily modify application.session.loggedIn to equal true (or modify Backbone.Router.prototype.navigate method) but then they would also have to not so easily dynamically embedded a link into the page (or modify a current one) that has the proper classes, data-* attributes, and href values to then load a page that should only be loaded when they user has logged in (and has the permissions).So I have an acl object that deals with the permissions stuff.  All someone would have to do to view pages or parts of pages they should not be able to is to call acl.addPermission(resource, permission) with the proper permissions or modify the acl.hasPermission() to always return true and then navigate away and then back to the page.Now certain things is EMCAScript 5 like Object.seal() or Object.freeze() would help with some of this however we have to support IE 8 which does not support those pieces of functionality.Now the REST API also performs security checks on every request so technically even if they are able to see parts of the interface that they should not be able to, they still should not be able to actually affect any data.The main benefits for me in developing a JavaScript SPA application is that the application is a lot more responsive since it is only transferring the minimum amount of JSON data for the requested action and performing the minimum amount of work too.  There are also other things that I think are beneficial like you are going to have to develop an API for the data (which is good if you want expand your application to different platforms/technologies) or their is more of a separation between front-end and back-end however if security is a concern, it is really wise to go down the road of a JavaScript SPA application for the front-end?
Should I be using a JavaScript SPA designed when security is important
javascript;architecture;security
I wouldnt rely on the client side javascript to tell you if the user is logged in.  That can easily be changed.The couple of times I've made 'single page' type web interfaces, I did it with two 'pages'.  The first page encountered was a login page.  When submitted, that allowed for the creation of a traditional web session on the server, and then returned back the 'application' page, which then immediately loaded everything by ajax requests.  For all subsequent ajax calls the cookie was sent with the request, so authentication worked the same way as it does in traditional applications.  So there's nothing particular you have to do differently in your javascript to support this.  Every server side response must, of course, validate the session.I say two 'pages', but they were really the same 'index.php' - it just returned either a login page or the main application page depending on whether a valid 'login' was set in the server-side session.  In your case, you'd just have node return two different page templates.