From e0ee491633360737599ccdb7e8863048d0e1c2c7 Mon Sep 17 00:00:00 2001 From: Brian Ford Date: Thu, 30 Oct 2014 14:04:47 -0700 Subject: [PATCH] docs($parse): formatting, link to security docs --- src/ng/parse.js | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/ng/parse.js b/src/ng/parse.js index 61a270e7b..b48e589b8 100644 --- a/src/ng/parse.js +++ b/src/ng/parse.js @@ -7,7 +7,7 @@ var promiseWarning; // Sandboxing Angular Expressions // ------------------------------ // Angular expressions are generally considered safe because these expressions only have direct -// access to $scope and locals. However, one can obtain the ability to execute arbitrary JS code by +// access to `$scope` and locals. However, one can obtain the ability to execute arbitrary JS code by // obtaining a reference to native JS functions such as the Function constructor. // // As an example, consider the following Angular expression: @@ -16,7 +16,7 @@ var promiseWarning; // // This sandboxing technique is not perfect and doesn't aim to be. The goal is to prevent exploits // against the expression language, but not to prevent exploits that were enabled by exposing -// sensitive JavaScript or browser apis on Scope. Exposing such objects on a Scope is never a good +// sensitive JavaScript or browser APIs on Scope. Exposing such objects on a Scope is never a good // practice and therefore we are not even trying to protect against interaction with an object // explicitly exposed in this way. // @@ -24,6 +24,8 @@ var promiseWarning; // window or some DOM object that has a reference to window is published onto a Scope. // Similarly we prevent invocations of function known to be dangerous, as well as assignments to // native objects. +// +// See https://docs.angularjs.org/guide/security function ensureSafeMemberName(name, fullExpression) {