Built-in Protections & Hardening
Vaadin Flow keeps the application state and logic on the server, and protects the communication between the browser and the server against common attacks. This page describes the protections that follow from this architecture. The pages below describe protections against specific attacks, and what to do to harden an application further.
Application State
In a Vaadin Flow application, the server is always aware of your application’s state. This means that, like client-side applications, the server is aware of what’s currently visible on the end user’s screen. Hence, Vaadin denies actions to components that aren’t currently visible on the screen, or those that have been disabled on the server.
For instance, if the developer sets a component to be disabled, this effect is set on both the server and the client. On the client, an attacker can circumvent this, since attackers have full control over anything in the browser. However, the server blocks any interaction with the component and logs a message about the ignored request.
Source code
Java
Button button = new Button("Click me for effect!");
button.setEnabled(false);
button.addClickListener(e -> {
// If the Button is disabled, this listener doesn't run,
// even if an attacker enables the button client side.
});Data Validation
In a Vaadin application, the data binding API supports data validation on the server, which can’t be bypassed by client-side attacks. Vaadin components do support client-side validation to increase the responsiveness of the application, but the developer should be aware that these should be used purely for convenience, since they can be circumvented in the browser.
As with other web applications, all data coming from the client should always be validated once it reaches the server. It isn’t safe to rely only on client-side validation. Vaadin provides a set of pre-created server-side validators for this purpose. In addition, the developer is free to use any Java API for validating the data, including connecting to external services. Vaadin also has a built-in integration with the Jakarta Bean Validation standard.
Data coming from a data store (such as a database) and inserted as HTML into DOM elements (for example, setting innerHTML for elements or using HTML mode in component captions) should also be escaped. See Cross-Site Scripting for more information.
Web Services
No public Web Services are necessary in Vaadin applications. All communication in Vaadin goes through a single HTTP request handler used for Remote Procedure Calls (RPC) requests using the standard Servlet Java API. With Vaadin, you never open up your business logic as Web Services and thus there are fewer attack entry points to your Vaadin application.
SSL and HTTPS
Vaadin always recommends developers to set up secure server endpoints and run all communication exclusively under HTTPS. Vaadin works out of the box with HTTPS, and there is nothing for the developer to configure in their application code. See the documentation of your servlet container for details on how to set up HTTPS on your server.
Topics
- Common Vulnerabilities
- Descriptions of common vulnerabilities such as SQL injections, cross-site request forgeries, cross-site scripting.
- Content Security Policy
- The Content Security Policy settings that Vaadin Flow needs, and how to use a strict policy.
- Frequently Reported Issues
- Lists perceived issues reported by users as vulnerabilities.
- Storing Sensitive Data
- Advice on storing sensitive data in Spring Boot applications.