Hilla Documentation

Security in Hilla Applications

Architecture

In contrast to Vaadin Flow applications, where all application logic (including authentication and authorization) is processed on the server side, Hilla applications involve the orchestration of server- and client-side security. Although the technical details are taken care of by the framework, it is important to understand how to design the application so that the server responds to client requests in a secure way.

Authentication

Most applications need to ensure that only eligible users can access sensitive data stored on the server. The client side authenticates by first obtaining an access token identifying the server session. The token contains, among other attributes, the principal (current user). This token is then included in subsequent endpoint calls. In Hilla, the token is a JSESSIONID cookie obtained via either the Spring-provided login form or an authentication helper method.

See Authentication with Spring Security for more information on configuring authentication. These sections also describe how to configure Spring Security to use different authentication providers, such as a SQL database or LDAP.

Authorization

Apart from authenticating users, applications often need to enforce restrictions on who can view what data. When the server receives an HTTP request targeting an endpoint, Hilla first checks whether the accessing user is authorized to invoke that endpoint. It does this based on the standard role-based access control scheme. The application developer can specify role-based access rules as annotations for the endpoint class or its individual methods. For example:

@Endpoint
public class MyEndpoint {
  @PermitAll
  public void permittedToAllMethod() {
    // Any authenticated user can access
  }

  @RolesAllowed("ROLE_ADMIN")
  public void permittedToRoleMethod() {
    // Only users with admin role can access
  }
}

In the above example, all endpoints in the MyEndpoint class are denied by default. The annotations @PermitAll and @RolesAllowed relax this restriction on the two methods permittedToAllMethod() and permittedToRoleMethod(), respectively. Endpoints can also be exposed for unauthenticated requests using the @AnonymousAllowed annotation. See Configuring Security for more details and code examples on endpoint security.

Security Notes

Application Security Is Endpoint Security

Once the client side of an application has been delivered to the browser, the server cannot trust that it has not been tampered with. This means that validation and sanitation of data received at endpoints should always occur on the server, regardless of the client-side logic.

Cross-Site Request Forgery (CSRF) Protection

A CSRF token is delivered to the browser when the Hilla application is first loaded, as part of the initial bootstrap HTML. Its purpose is to protect the session from requests that do not originate from the client code that was served to that browser. The CSRF token is included in each endpoint call and validated as matching by the server.

Cached Data

Hilla-based PWAs may choose to cache data retrieved from the server on the client side, using, for example, browser local storage, in order for a data-centric application to work offline. The developer needs to make an informed decision on whether the data is safe to store, and implement the clean-up of such stored local data if necessary – for example, at log-out.

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. This is typically achieved by 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 acceptable and appropriate, then issues can reported directly in GitHub.

Internal Security Practices

All code goes through an internal code review before it is merged. Each change is also run against our existing battery of tens of thousands of unit, integration and behavior tests that have to be passed 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 relate to security, and investigating it is given priority over other tasks.