[Owasp-leaders] From a security point of view: Angular or React?

Mike Goodwin mike.goodwin at owasp.org
Mon Jun 29 10:16:28 UTC 2015


"jquery is a banned API"

That is an interesting statement. Angular comes with a built-in, home grown
implementation of jQuery called jqlite, which automatically falls back on
full jQuery if it is present. From their docs
<https://docs.angularjs.org/api/ng/function/angular.element>:

*"all element references in Angular are always wrapped with jQuery or
jqLite; they are never raw DOM references"*

The Angular way is to encapsulate all your DOM manipulation using
jQuery/jqlite inside directives. When you are writing a custom directive,
the target DOM element is passed in as a jQuery/jqlite element, so you
can't really avoid it.

Mike


On 29 June 2015 at 08:22, Dinis Cruz <dinis.cruz at owasp.org> wrote:

> Thanks all for the great feedback, which matches the research I had done
> on it (see
> http://blog.diniscruz.com/2015/06/why-we-are-going-to-use-angularjs-13-on.html
> for the list of reasons we are going to go with Angular).
>
> Joanna, regarding jQuery, my experience (in both developing and reviewing
> jQuery apps) is that it tends to promote an 'lets just hack it to make it
> work' kind of development workflow. In jQuert code, there are always tons
> of DOM manipulations, which will always include (browser specific and
> other) hacks, and create code with quite a lot of dependencies and
> lack-of-isolation between components. Basically you shown me an large
> jQuery app (like the one we developed) and It most likely be an app hard to
> refactor, hard to maintain and hard to understand what really is going on
> (ironically the power of jQuery tends to create this stuff, since it is
> always possible to 'fix something' by adding a bit of jQuery somewhere).
>
> And of course jQuery is also a nightmare from a security point of view,
> since as mentioned on this thread there are quite a lot of sinks that will
> transform strings into code.
>
> In order to make our app secure and easy to code we are using the
> following stack/technologies:
>
> - no jQuery (as far as I am concert it is a banned API :)  )
> - Jade for creating html (i.e. no raw html and encoding by default on all
> variables)
> - 95%+ Unit Test coverage
> - NodeJs on the server (with one a version of the website created with NO
> Javascript)
> - AngularJS on the client, with full use of Angular components to keep
> code clean, easy to test and isolated (Controllers, Directives, Services,
> etc...)
> - CoffeeScript on both server and client (to promote good Javascript
> practices, keep code clean and easy to test)
> - Git Flow, with git submodules used to separate the code into different
> areas of responsibility
> - Docker for deployment and testing (with ability to start new instances
> of the site in seconds (on any branch))
> - Slack for team collaboration
> - GitHub for Issues (and of course code hosting :)  )
>
> I also have to say that I like the maturity and amount of thinking that
> has gone into AngularJS security. Yes there is a level of moving parts, but
> they push the development teams to have a really good architecture (which
> is key to enable all team members to write secure code).
>
> In fact, what I really like about our current development
> environment/workflow (the one based on Node, CoffeeScript and Jade) is that
> there are large parts of the code base that at the moment it is REALLY hard
> to create a security vulnerability. For example, since we use Jade for the
> views, I don't have to 'security review' design and UI changes since they
> are secure by default (and I have a test to check for the on case where
> un-escape content can be enabled). Compare this to the normal JSP or jQuery
> world where any code change is one small mistake away from creating a
> security issue. Basically the best way to prevent HTML injections (aka XSS)
> is to not have any HTML coding at all :)
>
> Dinis
>
> On 29 June 2015 at 00:21, Kim Carter <kim.carter at owasp.org> wrote:
>
>>  With Angular: Generally a lot of work for a large non-trivial
>> application. Angular is pretty much an all or nothing framework.
>>
>> With React and Flux: As much or as little work as you want it to be. Many
>> teams use React to replace small pieces at a time. The last client I used
>> React with I used it to replace the backbone views. Why only the views?
>> Because there was nothing wrong with the router or models and the problem
>> with the existing code base was the manual DOM manipulation and events
>> being in unknown states due to having many teams work on the code base and
>> all of which did things a different way. By using React to replace a
>> Backbone view at a time, the work load was very manageable. I attacked the
>> worst views first, unravelled them and replaced them with React components.
>> React is essentially a view engine, but can be used for everything. With
>> React, you can use as little or as much as you like.
>>
>>
>>  Kim Carter
>>
>> OWASP New Zealand Chapter Leader (Christchurch)
>>
>> c: +64 274 622 607
>>
>>
>>   On 29/06/15 08:35, Jim Manico wrote:
>>
>> JQuery was originally built to help with cross-browser quirks which is
>> becoming less of an issue. I see plenty of folks migrating away from it to
>> Angular and similar. There are a variety of migration resources on the net
>> and it's doable - but migration can be time consuming work.
>>
>> --
>> Jim Manico
>>   Global Board Member
>> OWASP Foundation
>> https://www.owasp.org
>>  Join me at AppSecUSA <http://appsecusa.org/> 2015!
>>
>> On Jun 28, 2015, at 10:22 AM, johanna curiel curiel <
>> johanna.curiel at owasp.org> wrote:
>>
>>   From a developer point of view, if I had to replace Jquery with
>> Angular or React how much work is that?
>>
>>  Imagine my entire front is completely dependent on Jquery...any
>> instructions or ideas how to achieve this without an excruciating QA?
>>
>> On Sun, Jun 28, 2015 at 4:09 PM, Jim Manico <jim.manico at owasp.org> wrote:
>>
>>>  Angular is much better for XSS defense today, but React was built with
>>> a much more sound core and is likely to have a better future.
>>>
>>>  #nuance
>>>
>>> --
>>> Jim Manico
>>>   Global Board Member
>>> OWASP Foundation
>>> https://www.owasp.org
>>>  Join me at AppSecUSA <http://appsecusa.org/> 2015!
>>>
>>> On Jun 28, 2015, at 4:21 AM, Dinis Cruz <dinis.cruz at owasp.org> wrote:
>>>
>>>   Which one makes it easier to write secure code, has more features to
>>> help security and has better support for Security-focused tests?
>>>
>>> What do you see on the ground?
>>>
>>> Which one tends to create apps with more vulnerabilities?
>>>
>>>   _______________________________________________
>>> OWASP-Leaders mailing list
>>> OWASP-Leaders at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>
>>>
>>> _______________________________________________
>>> OWASP-Leaders mailing list
>>> OWASP-Leaders at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>
>>>
>>
>>
>> _______________________________________________
>> OWASP-Leaders mailing listOWASP-Leaders at lists.owasp.orghttps://lists.owasp.org/mailman/listinfo/owasp-leaders
>>
>>
>>
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>
>>
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20150629/fe1915db/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: owasp_member_EmailSignature.gif
Type: image/gif
Size: 3735 bytes
Desc: not available
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20150629/fe1915db/attachment-0001.gif>


More information about the OWASP-Leaders mailing list