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

Dinis Cruz dinis.cruz at owasp.org
Tue Jun 30 09:48:30 UTC 2015


Correct, and the idea is that jqlite should be enough for any DOM
manipulations (with DOM hacks kept under control :) )

This means that there shouldn't be any need to have the jQuery api added to
the application

Dinis
On 29 Jun 2015 11:16, "Mike Goodwin" <mike.goodwin at owasp.org> wrote:

> "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/20150630/75fdaa85/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/20150630/75fdaa85/attachment-0001.gif>


More information about the OWASP-Leaders mailing list