Are Vaadin or RAP/RWT prone to denial of service attacks

Question

Vaadin and Eclipse RAP/RWT are web application frameworks with - as far as I understand - similar architecture. My question is if an application built with Vaadin or RAP is prone to denial of service attacks? I am currently evaluating the frameworks and want to be sure that this is not a concern.

Here is my reasoning:

With Vaadin or RAP you don't build HTML output but instead construct a Widget tree similar to an Swing/SWT application (in case of RAP it is SWT). The frameworks renders the widget tree as HTML in the browser, and sends user interactions back to the server, where the application gets notified in terms of events. The events are delivered to listener objects, which have previously been registered on widget.

Therefore the widget tree must be kept in some sort of user session and of course consumes some memory.

If the application is public (i.e. does not sit behind a login page), then it seems that there is a possible denial of service attack for such an application: Just fire requests to the apps landing page, and probably fake a first response. For any such request, the framework will build a new widget tree, which will live some time on the server, until the session expires. Therefore the server memory should be filled with tangling users sessions very soon.

Or did these frameworks invent protection against this scenario? Thanks.

Answer 1

A framework only can not protect you from DoS attacks.

Vaadin has some features built in to prevent attacks, but of course these features depend on how you code your application.

There is a long webinar about vaadin security: https://vaadin.com/de/blog/-/blogs/vaadin-application-security-webinar

Vaadin does some validation of the client<->server traffic to prevent XSS and other attacks.

But when you do some special things, you can open doors for such attacks.

As for the scenario you described:

• The initial vaadin session takes some memory on the server (Just as all other sessions on any server)

• How large this memory footprint is, depends on the initial number of widgets and what you load in memory for this. (DB connections etc.)

• Usually this is not a problem when you have a very lightweight login page

• But if you display large tables and many other fancy things, then you will have to have enough memory for the number of requests. (The same apply to all othe http servers/applications, they also need memory for this)

• If the number of requests surpasses the capacity of your server, any web service can be brought down in a DoS attack

EDIT:

Due to good points in Andrés answer I want to sharpen my question.

First of all, of course I agree, if you put an application behind a login-wall then the DOS-threat is not that big. At least you can identify the attacking user. And the login page itself can be lightweight or even must not be implemented with Vaadin/RAP. And as Vaadin/RAP applications are most likely used in RIA-style intranet settings then the DOS scenario does not invalidate their use in these settings.

But at least both frameworks itself expose demo pages without logins on the internet: See http://www.eclipse.org/rap/demos/ and http://demo.vaadin.com/dashboard/ These are not simple pages, and probably use quite a bit of memory.

My concern is about such a scenario, a non access-restricted internet page: Once these frameworks responded to a request, they must keep serverside memory for that request for quite some time (say the classical 30 minutes of a HTTP session, at least in minute scale). Or to express it differently, if the application retains memory per intial user request for some substantial time it will be prone to DOS attacks.

Contrast this with an old-style roundtrip web application which does not require user identification. All the information needed to decide what to return is contained in the request (path, parameters, http-method, ...), so a stateless server is possible. If the user interacts with such an application, the application is still free to store session-persistent data on the client (shopping cart contents in a cookie, etc.).