angular.js/docs/content/error/parse/isecprv.ngdoc

51 lines
2 KiB
Text
Raw Normal View History

feat($parse): secure expressions by hiding "private" properties BREAKING CHANGE: This commit introduces the notion of "private" properties (properties whose names begin and/or end with an underscore) on the scope chain. These properties will not be available to Angular expressions (i.e. {{ }} interpolation in templates and strings passed to `$parse`) They are freely available to JavaScript code (as before). Motivation ---------- Angular expressions execute in a limited context.  They do not have direct access to the global scope, Window, Document or the Function constructor.  However, they have direct access to names/properties on the scope chain.  It has been a long standing best practice to keep sensitive APIs outside of the scope chain (in a closure or your controller.)  That's easier said that done for two reasons: (1) JavaScript does not have a notion of private properties so if you need someone on the scope chain for JavaScript use, you also expose it to Angular expressions, and (2) the new "controller as" syntax that's now in increased usage exposes the entire controller on the scope chain greatly increaing the exposed surface.  Though Angular expressions are written and controlled by the developer, they (1) typically deal with user input and (2) don't get the kind of test coverage that JavaScript code would.  This commit provides a way, via a naming convention, to allow publishing/restricting properties from controllers/scopes to Angular expressions enabling one to only expose those properties that are actually needed by the expressions.
2013-10-18 02:44:36 +00:00
@ngdoc error
@name $parse:isecprv
@fullName Referencing private Field in Expression
@description
Occurs when an Angular expression attempts to access a private field.
Fields with names that begin or end with an underscore are considered
private fields.  Angular expressions are not allowed to reference such
fields on the scope chain.  This only applies to Angular expressions
(e.g. {{ }} interpolation and calls to `$parse` with a string expression
argument) Javascript itself has no such notion.
To resolve this error, use an alternate non-private field if available
or make the field public (by removing any leading and trailing
underscore characters from its name.)
Example expression that would result in this error:
```html
<div>{{user._private_field}}</div>
```
Background:
Though Angular expressions are written and controlled by the developer
and are trusted, they do represent an attack surface due to the
following two factors:
- they typically deal with user input which is generally high risk
- they often don't get the kind of attention and test coverage that
JavaScript code would.
If these expression were evaluated in a context with full trust, an
attacker, though unable to change the expression itself, can feed it
unexpected and dangerous input that could result in a security
breach/exploit.
As such, Angular expressions are evaluated in a limited context.  They
do not have direct access to the global scope, Window, Document, the
Function constructor or "private" properties (names beginning or ending
with an underscore character) on the scope chain.  They should get their
work done via public properties and methods exposed on the scope chain
(keep in mind that this includes controllers as well as they are
published on the scope via the "controller as" syntax.)
As a best practise, only "publish" properties on the scopes and
controllers that must be available to Angular expressions.  All other
members should either be in closures or be "private" by giving them
names with a leading or trailing underscore character.