Security in Flow Applications

Architecture

Vaadin Flow is a server-side framework, where all of your application state, business, and UI logic reside on the server. Unlike client-driven frameworks, a Flow application never exposes its internals to the browser where vulnerabilities could be abused by an attacker.

Flow automates the communication between server and client through a single, secure endpoint. This endpoint has multiple built-in security features detailed in the following chapters.

Example

In the following is an example where we fetch sensitive user data from the database, but do not expose anything we do not want on the client in any form:

  1. User clicks on a button in the UI to edit their own data (such as their name)

  2. This click is caught with framework JavaScript and translated to these two things that are sent to the server:

    1. The unique id of the Button instance (sequentially assigned previously by the framework)

    2. What was done with the button, in this case a click with associated mouse details (what type of click it was, and cursor position)

  3. The data is sent to the server using the single server endpoint. The application server uses standard Servlet Session methods to locate the correct user session, which is then given to Vaadin along with the request payload.

  4. Vaadin double-checks the session info and makes sure a Button with the given ID exists. If it does, the server-side click handler for the button is invoked and given the event details.

  5. The server-side code fetches the user details from storage. This data does not need to be filtered at this point, but can be if the developer so chooses.

  6. The developer chooses what parts of the data to show the user by setting it as the content for any components.

    For example: nameTextField.setValue(user.getName());

  7. After the handler code has executed, Vaadin will not store any reference to the fetched data. Any data that is not specifically set to be displayed is therefore discarded, such as user ID or hashed passwords or salts.

  8. Only the user name string is sent to the client to be displayed, not the full user object. The client is not even aware there is a user object on the server side.

  9. After the user has modified the name, the new value is sent back to the server. On the server, the developer can load the User object again, set the new name, and store the object.

As the example shows, the developer can safely handle confidential data in their code, even when dealing with UI code. The framework only stores data the developer gives it explicitly, and only data that should be visible on the client is actually sent there.

Third Party Libraries

Vaadin always updates dependencies to third part libraries when security patches for them are released. When necessary, a new maintenance version of Vaadin is created to apply the fix.

In most cases, developers can also specifically update versions of external libraries using Maven, where updated versions of Vaadin libraries aren’t yet available. This is done by adding a new dependency definition to the project pom.xml file with the wanted library and version number. This will make Maven override the Vaadin-defined version of the dependency with whatever version the developer added.

Older versions of Vaadin (namely, Vaadin 7 and 8) additionally depend on libraries with known security issues.

These libraries are used only for compiling Java code into JavaScript, and the insecure libraries are never deployed into the runtime and hence do not pose a security risk.

Security Practices at Vaadin

Releasing Security Patches

Security fixes are implemented as fast as possible and released for all currently supported versions. The fix is mentioned in the release notes, and we also send a separate security notification email to all our registered users explaining the issue and how to fix it (typically updating to a new maintenance version).

How Users Can Report Security Issues

If a developer or user finds a potential security issue, they can report it directly to security@vaadin.com. The issue will be reviewed and fixed internally, before publishing to GitHub.

If the issue is minor and public discussion is OK, then issues can reported directly in GitHub.

Internal Security Practices

All code that is committed at Vaadin goes through an internal code review before it is merged. Each change is also ran against our existing battery of tens of thousands of unit, integration and behavior tests that have to pass for the merge to be accepted.

Developers are also encouraged to actively think about security issues while developing the framework and its parts. At Vaadin, we take security extremely seriously. Anyone can escalate an issue that they think might be a security issue, and investigating the issue is given priority over other tasks.