Security in Fusion Applications

Architecture

In contrast to Vaadin Flow applications, where all application logic (including authentication and authorization) is processed on server side, Vaadin Fusion applications involve the orchestration of server and client-side security. While 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, which contains among other attributes the principal (current user), and then including the token in subsequent endpoint calls. In Fusion, the token is a JSESSIONID cookie obtained either via the Spring-provided login form or an authentication helper method.

Configuring authentication is further described in Authentication with Spring Security. These sections also describe how to configure Spring Security to use different authentication providers, such as an SQL database or LDAP.

Authorization

Apart from authenticating users, applications often need to enforce restrictions on who can view what data. When an HTTP request targeting an endpoint reaches the server, Fusion first checks whether the accessing user is authorized to invoke that endpoint 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, with the annotations @PermitAll and @RolesAllowed loosening this restriction on the two methods permittedToAllMethod and permittedToRoleMethod, respectively. Endpoints can also 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 Fusion application is first loaded as part of the initial bootstrap HTML. Its purpose is to protect the session from requests not originating from the client code served to that browser. The CSRF token is included in each endpoint call and validated to be matching by the server.

Cached Data

Fusion-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 must make an informed decision on whether the data is safe to store or not, and implement the cleanup of such stored local data (for example at logout), if necessary.

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.