I would like some advice on how best to architect a website comprising the following: tool

  • a landing page, open to the public, main marketing tool

  • the main website/app, that people can access only if registered, where users can access certain modules depending on their level of registration (free/casual/premium user) I'm thinking of using AngularJS for front-end for the double-binding and to bring UI interaction

  • an admin part:

    • where we can either interact with the database
    • check user analytics

I'm afraid that if I use Angular for the 3 parts, the admin part might be accessible to even the public/free users as basically everything is stored as static files on the client. Is it just a routing problem on the server side? should I use Jade/handlebars for the admin part/landing page (helps for the SEO) and Angular just for the app? is there a best practice in this regard?

  • One best-practice I have seen and can recommend is only using JavaScript where unavoidable (due to quality of language) - just build a minimal client only having view models and services that wrap calls to server.
    – Den
    Oct 24, 2014 at 8:22

1 Answer 1


When building angular apps, here's my general philosophy in a nutshell. I can add more clarification if necessary.

All actual security must be implemented server-side. Any security logic you put in the angular app (and it should be there) is for convenience and usability only, not actual security.

You must gate your REST api calls in nodejs using some kind of authentication and authorization scheme, and you should return a 401 to any client asking for data or trying to save data they don't have access to.

At the same time, it's a bad idea to show users functionality that will not work (ie, will return a 401). So if there's a button that does something a user isn't allowed to do, you should hide it from them before they have a chance to click on it and receive an error.

To do this, you'll need to send the client information about the currently authenticated users access-level, and drive visibility of features/behavior off of that. But understand that this is easily circumvented by a sophisticated user (using the F12 Developer Tools, for example). So this is not something that secures your application, per se, but something that makes your application more user-friendly.

You have to decide how important it is to keep the admin functionality secret. Is it a secret that there exists an admin function that your users can't use? Or do you need to just secure the functionality itself? If you are serving static files, then a clever user can get any of those files from the server. But of what value is that? Those files will not contain any actual data, and clicking the buttons won't do anything (because you secured your api calls on the server). All our hacker can see is an angular html template. That's not worth very much. Some sucker spent all that energy trying to figure out the names of the files to download and all s/he sees are a bunch of mustaches and ng-* directives. Whoopdedoo.

But if you want to secure even that, you'll need to gate access to the static files. There's no reason you have to serve those to freely. You can implement security on the server and check authorization before returning html and js. It's a bit more work to do this, so it isn't worth it unless it's necessary, but it's possible.

One final thought: there's no reason you are limited to a single angular app for your application. You might want to try a setup that looks like this:

  • Landing Page (rendered server-side, public)
  • About Page (rendered server-side, public)
  • Any other server-side pages to market your app
  • App (index.html, the entry point to your main angular app)
  • Admin App (index.html, the entry point to your admin angular app)

Here you have two SPAs being served from the same webserver. This structure separates your admin functionality cleanly. From a security standpoint, you still have all the same considerations, but this might make it easier to implement your security rules.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.