4

We are trying to come up with a permissions/security implementation on our MongoDB backend/Angular front-end environment that accomplishes what we need it to, without being over-bearing or too difficult to build-out/adjust in the future. And, to clarify, I'm referring to the permissions that apply to the end-user of data provided by the API and being displayed in the front-end Angular app. I'm not referring to our back-end admin privileges that apply among our DBAs.

One approach would be to make the permissions schema/model-based, using a plugin such as this (https://www.npmjs.com/package/mongoose-authorization). That way, because this would be granular enough to be defined on each property within each model, only the properties that a front-end consumer should be able to read and/or write to -- based on their role permissions -- are returned when a request is made.

The advantage to this implementation is that the front-end Angular app can consume documents agnostically (i.e., the document has been vetted before it is returned, so there's no checking to do on the front-end).

In terms of best practices, is this the way to do this -- handle all permissions on the API rather than on the front-end consuming app? And does it make sense to do this at the model/property level?

A drawback to this approach would be that we'd have to impact all documents when it came time to change permissions. Maybe there's a way to link the models to a central permissions object?

Or, is there a different way to approach this that's considered more common in terms of following best practices? Knowing that other organizations have all faced these same questions, we want to make sure we're following best practices, and not unnecessarily re-inventing the wheel.

2
  • the options presented are slightly unclear to me, but your mongo shouldn't know about any of your front-end users, if that helps. You also can't typically validate perms client-side, if that helps.
    – dandavis
    Commented Mar 14, 2019 at 16:41
  • What you're looking for is called ABAC or attribute-based access control Commented Mar 15, 2019 at 0:45

1 Answer 1

4

I am less used to angular frontends, but this as always been a question: should the control of user permissions be done client-side or server-side?

The answer was (and IMHO still is) that client side and server side controls serve different purposes:

  • client side controls help in customizing the UI to only present what the user is allowed to use. The ultimate goal is to avoid the user getting an error because they naively clicked on an apparently valid button
  • server side controls are there for security reasons.

Even if you can control the UI client side with Angular or other Javascript frameworks, you cannot prevent an attacker (or a user thinking themselves advanced enough...) to analyze the data exchanged between the browser and the server and send forged requests. It is often realized in a legitimate goal to automate some processes, but can have terrible security consequences if the security was implemented client side.

TL/DR: implementing validation controls client side is good practice and generally provides user a better experience, but security has to be implemented server side, so for your question, at API level.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .