Security in Hilla applications

An introduction to the Hilla security architecture and how it works in practice.

Architecture

Hilla enables applications' security by orchestrating server- and client-side security. Although the technical details are taken care of by the framework, it’s 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.

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 Considerations

Application Security is Endpoint Security

Once the client side of an application has been delivered to the browser, the server cannot trust that it hasn’t 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 don’t 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.

Vaadin Security Practices

Releasing Security Patches

Security fixes are implemented as fast as possible and released for all supported versions. The fix is mentioned in the release notes, and Vaadin also sends a separate security notification email to all registered users, explaining the issue and how to fix it. This is typically achieved by updating to a new maintenance version.

Users Reporting Security Issues

If a developer or user finds a potential security issue, they can report it directly to [email protected]. The issue is 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’s merged. Each change is also run against an 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. Vaadin takes security extremely seriously. Anyone can escalate an issue that they think might relate to security, and investigating it’s given priority over other tasks.

Docs