Security

The most important thing to understand about angular is that the business logic executes in the browser. In general browser can not be trusted to enforce all of the logic in HTML template, it is more of a suggestion. It is possible that the browser is compromised with JavaScript code which will execute the code differently.

For this reason the only kind of security which angular can enforce is which user is allowed to read/write specific database / entity / document. In other words you can prevent a specific user from reading or writing data, but you can not force the user from executing the logic in your template.

NOTE: currently only database level security is implemented.

All of the permissions are controlled from your account. Log in, find the library and database and administer your permissions.

User Permissions

Angular can prevent a user from reading or writing to a specific library/database/entity/document. The permission is managed as a set of +/- right to read/write for users.

• Grant: +/-
  • +: add right to users
  • -: subtract right from users
• Right: read/write
  • R: users can read
  • W: users can write
• Users:
  • user@domain.com: specific user
  • *@domain.com: any user at a domain
  • *@*: any logged in/authenticated user

The permissions are executed in following order:

1. All grants (+) executed first
2. All revocations (-) executed last

NOTE: Anonymous user have a separate place to enter rights.

NOTE: As owner of database you always have full permissions to your data.

NOTE: currently only database level security is implemented.

Site Permissions

JavaScript code is susceptible to Cross Site Scripting attacks. Here is a scenario:

1. User logs in to angular account and receives a cookie. From here the user is free to access the database through the script tag. The database grants the user full permission to modify data per User Permissions defined above.
2. User visits malicious site which loads the script tag for the user database and maliciously modifies data. This is possible since the user has a valid cookie.

To prevent this scenario from occurring every web request from the browser carries a HTTP referrer tag which identifies the site making the request. It is not possible to fake the referrer in JavaScript. The database can be set to only answer request coming from a specific website. (The malicious website will not be on the list and will be denied.)

We strongly encourage you to enable this feature.

There is a special case when accessing the database from non browser (such as command line tools) or from a browser which loaded the HTML from the file (the URL reads file://). In such a case the server creates a pseudo Referrer URL: http://remote-ip/$non_browser_request$