Wednesday, September 14, 2016

Today, at a special meetup at Google HQ, we announced the final release version of Angular 2, the full-platform successor to Angular 1.

What does "final" mean? Stability that's been validated across a wide range of use cases, and a framework that's been optimized for developer productivity, small payload size, and performance. With ahead-of-time compilation and built-in lazy-loading, we’ve made sure that you can deploy the fastest, smallest applications across the browser, desktop, and mobile environments. This release also represents huge improvements to developer productivity with the Angular CLI and styleguide.

Angular 1 first solved the problem of how to develop for an emerging web. Six years later, the challenges faced by today’s application developers, and the sophistication of the devices that applications must support, have both changed immensely. With this release, and its more capable versions of the Router, Forms, and other core APIs, today you can build amazing apps for any platform. If you prefer your own approach, Angular is also modular and flexible, so you can use your favorite third-party library or write your own.

From the beginning, we built Angular in collaboration with the open source development community. We are grateful to the large number of contributors who dedicated time to submitting pull requests, issues, and repro cases, who discussed and debated design decisions, and validated (and pushed back on) our RCs. We wish we could have brought every one of you in person to our meetup so you could celebrate this milestone with us tonight!

What’s next?

Angular is now ready for the world, and we’re excited for you to join the thousands of developers already building with Angular 2. But what’s coming next for Angular?

A few of the things you can expect in the near future from the Angular team:

Bug fixes and non-breaking features for APIs marked as stable

More guides and live examples specific to your use cases

More work on animations

Angular Material 2

Moving WebWorkers out of experimental

More features and more languages for Angular Universal

Even more speed and payload size improvements

Semantic Versioning

We heard loud and clear that our RC labeling was confusing. To make it easy to manage dependencies on stable Angular releases, starting today with Angular 2.0.0, we will move to semantic versioning. Angular versioning will then follow the MAJOR.MINOR.PATCH scheme as described by semver:

the MAJOR version gets incremented when incompatible API changes are made to stable APIs,

the MINOR version gets incremented when backwards-compatible functionality are added,

the PATCH version gets incremented when backwards-compatible bug are fixed.

Moving Angular to semantic versioning ensures rapid access to the newest features for our component and tooling ecosystem, while preserving a consistent and reliable development environment for production applications that depend on stability between major releases, but still benefit from bug fixes and new APIs.

Wednesday, September 7, 2016

Important Announcement

The Angular expression sandbox will be removed from Angular from 1.6 onwards, making the code faster, smaller and easier to maintain.

The removal highlights a best practice for security in Angular applications: Angular template, and expressions, should be treated similarly to code and user-provided input should not be used to generate templates, or expressions.
Removing the expression sandbox does not change the security surface of Angular 1 applications. In all versions of Angular 1, your application is at risk of malicious attack if you generate Angular templates using untrusted user-provided content (even if the content is sanitized to contain no HTML). This is the case with or without the sandbox and the existence of the sandbox only made some developers incorrectly believe that the expression sandbox protected them against such attacks.

What is the expression sandbox?

Angular puts an emphasis on the idea of separating business logic from user interface rendering. Application business logic should always reside in the code of controllers and components, where it can be unit tested effectively and more easily maintained.
Angular expressions were designed to allow a limited subset of JavaScript inside templates to support the basic logic that is necessary to be able to render the user interface. Angular templates encourage a clear separation of concerns between the simple logic used in rendering and the more complex logic of the application business domain.

The expression sandbox is a mechanism that checks Angular expressions to attempt to prevent accidental access to arbitrary JavaScript code and to discourage business logic from appearing in templates.

Why did we add the sandbox?

We added the sandbox to check that applications were not naively running JavaScript in their expressions since this implies that the template could be doing too much work. The aim was to provide feedback to the developer to prevent them from inadvertently designing applications that would be difficult to test and maintain.
Some time after the sandbox appeared in the codebase, a developer noticed that they could create an XSS attack to an Angular application if they had access to the template such that they could insert an arbitrary Angular expression. A number of these attacks were due to vulnerabilities in the sandbox combined with access to the template. Examples of these have been published on the web:

This blog post describes an attack that can be made if the template contains user provided content.

Initially we thought that we could tighten up the sandbox to prevent these attacks. But it became apparent that this was not an adequate defense: control of the Angular templates makes applications vulnerable even when the sandbox is completely secure:

This blog post shows a (now closed) vulnerability in the Plunker application due to server-side rendering inside an Angular template.

This blog post describes an attack, which does not rely upon an expression sandbox bypass, that can be made because the sample application is rendering a template on the server that contains user entered content.

The only effective security strategy is to ensure that users are never able to provide content that will be used in an Angular template, or expression.

As long as the Angular templates, and expressions, are not constructed using user provided content, there is no possibility of attack via these methods.

Why are we removing the sandbox?

While the sandbox was not a security defense mechanism, developers kept relying upon it as a security feature even though it was always possible to access arbitrary JavaScript code if a malicious user could control the content of Angular templates in applications.

Unfortunately we continued to patch up Angular 1 whenever people found new ways to undermine the sandbox despite the fact that it was not a defense mechanism.

These patches sent the wrong message to developers that they could continue to rely upon the sandbox for security, when they could not.

Removing the sandbox has the following benefits:

It clarifies to developers that Angular expression sandbox is not a security feature

It simplifies the parser codebase making it easier to maintain and extend.

It reduces the size of the parser codebase and therefore the size of the core Angular library distribution file (~1.3% smaller for angular.min.js.gzip).

It removes extra checks thus improving the speed and performance of Angular at runtime (~14% faster for complex expression parsing).

It provides opportunities to add further performance improvements to the parser.

You can view and comment on the Pull Request that removes the sandbox here.

What are the security implications?

If an attacker has access to control Angular templates or expressions, they can exploit an Angular application regardless of the version. There are a number of ways that templates or expressions can be controlled:

Passing user provided content as the predicate parameter to the orderBy filter:

{{ value | orderBy : userContent }}

Each version of Angular 1 up to, but not including, 1.6 reduced the surface area of the vulnerability but never removed it.

If you dynamically generate Angular templates or expressions from user-provided content then you are at risk of XSS whatever version of Angular you are using.

If you do not generate your Angular templates or expressions from user-provided content then you are not at risk of this attack whatever version of Angular you are using.

See the Angular 1 security guide (once the PR has landed) for more information about the sandbox and possible vulnerabilities if you allow access to Angular templates.

What should I do?

If all your templates are static HTML files, or files that are generated without any user-provided input (e.g. using jade), and you are not generating any Angular expressions from user-provided content, then no action is needed and all the security measures provided by Angular are in effect.

If you dynamically generate Angular templates, or expression, using user-provided content then you should conduct a security review of your deployment and assess the risk that the user-provided content poses.

If you have to keep on using the user-provided content then the safest option is to ensure that it is only present in the part of the template that is made inert via the ngNonBindable directive. Be aware that you must ensure that all HTML is sanitized from the user content to prevent a malicious user from closing the tag containing the ngNonBindable directive and getting access to the rest of the template.

Size and performance comparison

Initial benchmarks of the removal show a small file size decrease and an increase in performance of the parser:

Faster Angular 2

Ahead of Time (AoT) Compilation

We’re really excited about the speed and bundle size improvements developers get when compiling applications ahead of time. To take advantage of AoT compilation, you’ll need to install the @angular/compiler-cli and make a small addition to your tsconfig.json file.

"angularCompilerOptions": { "genDir": "./ngfactory" }

Once you make this change, you can run the Angular compiler from the command-line, by typing ngc.

These two changes will get you started with using ngc and AoT, but we have more documentation and tools coming. Developers looking to try AoT may run into errors the first time they try - don’t panic! One of the benefits of the introduction of NgModules is that your code does not have to change based on whether you’re running in AoT or just in time (JiT) mode, so you can continue to be productive while we continue to improve these tools and work with third-party library authors to make sure code is AoT compilable.

ES2015 modules

In RC6, we’ve changed the output structure of our NPM packages to better enable tools like Rollup and Webpack2 to optimize your applications during bundling.

Each @angular/* package now contains:

“ESM” code - this is ES5 code with ES2015 style import/exports. This works great with Rollup and Webpack2 and allows more efficient tree shaking. This code replaces the commonJS source in the root of each directory.

A UMD bundle in the bundles/ directory of each package.

A new field in the package.json - “module” - that allows Rollup and Webpack to opt into using the ESM code.

If you’ve previously deep imported from @angular packages (e.g. @angular/core/src/foo/bar), note that this no longer works in RC6. Always import from the root of a package (eg, @angular/core). Deep imports are private APIs, and likely to change.