Security Best Practices

Hilla lets you choose which authentication and authorization framework you want to use, instead of bundling any specific one. Hilla is fully compatible with the most-used security solutions in the Java ecosystem, including, but not limited to, Spring Security, JAAS and Apache Shiro. The Hilla Spring add-on has helpers for developers to integrate into the security mechanisms of these frameworks.

Since Hilla is a server-side framework, credential-processing always happens on the server, away from any possible attack surface. Credentials are never transmitted to the client, unless this is explicitly done by the developer.

Generally, it’s recommended that the developer double-check user identity and access rights for each call from the client. This can be automated with, for example, Spring Security and view-based authentication using roles. What typically cannot be automated by these frameworks is data-based access rights, such as limiting access to specific entities.

As an example, if the server receives the ID of a User object to be displayed in, say, a URL request parameter ({yourapp.com}/users/4/edit), the ID in question can be freely changed by an attacker. The application needs to be aware of this and check that the currently logged-in user has access rights to this entity. This is something that’s common to all UI frameworks, and not specific to Hilla.

In a Hilla application, the data-binding API supports data validation on the server, which cannot be bypassed via client-side attacks. Vaadin components do support client-side validation to increase the responsiveness of the application. However, the developer should be aware that these should be used purely for convenience, since they are easily circumvented in the browser.

As with other web applications, data coming from the client should always be validated once it reaches the server. It’s not safe to rely only on client-side validation. Hilla provides a set of pre-created server-side validators for this purpose. In addition, the developer is free to use any Java API to validate the data, including connecting to external services. Hilla also has a built-in integration with Java’s Bean Validation (JSR-303) standard.

Data coming from a data store (such as a database) and inserted as HTML into DOM elements (for example, by setting innerHTML for elements or using HTML mode in component captions) should also be escaped.

By default, an endpoint requires requests to be authenticated. It’s recommended to use stricter access control, such as @RolesAllowed(). Less strict access control, such as @AnonymousAllowed, should be used with caution. See Configuring Security for more information.

Vaadin always recommends developers to set up secure server endpoints and run all communication exclusively under HTTPS. Hilla works out of the box with HTTPS, and there is nothing for the developer to configure in their application code. Refer to the documentation of your servlet container for details on how to set up HTTPS on your server.