Documentation

Documentation versions (currently viewingVaadin 24)

Frequently Reported Issues (False Positives)

Lists perceived issues reported by users as vulnerabilities.

From time to time, Vaadin users perform security tests on the framework and report issues they find. Most of the time, the issues are false positives. The following is a list of commonly reported false positives and why they’re false.

Content-Security-Policy (CSP) Set to Unsafe Values

The settings script-src 'unsafe-inline' 'unsafe-eval' and style-src 'unsafe-inline' are required during Vaadin application start, that is, the bootstrap process. The bootstrap process that starts the application loads the widget set which is the client-side engine part of the application. This consists of precompiled JavaScript logic, for example, for the communication protocol, DOM control, Buttons, Layouts, etc., but not the application code. The widget set is a static resource. After it’s loaded, the client-side engine needs to be started using JavaScript.eval().

Hence, these settings are architectural limitations in Vaadin, so that the framework can start its client-side engine in the browser.

Reported as: Missing or insecure “Content-Security-Policy” header

v-curdate & v-wn Reported as CSRF Tokens

These values aren’t used as Cross-Site Request Forgery (CSRF) tokens, and they aren’t processed in a way that would let an attacker compromise the application state. Vaadin uses its own CSRF scheme.

Cross-Site Request Forgery when Fetching Static Resources

Many tools report a Cross-Site Request Forgery (CSRF) vulnerability when Vaadin fetches static resources. These requests can’t change the application state. Here is a list of resources that are safe to fetch without a CSRF token:

  • FlowBootstrap.(hash).js

  • FlowBootstrap.(hash).js.br

  • FlowClient.(hash).js

  • FlowClient.(hash).js.br

  • generated-flow-imports-fallback.(hash).js

  • generated-flow-imports-fallback.(hash).js.br

  • generated-flow-imports.(hash).js

  • generated-flow-imports.(hash).js.br

  • web-component/web-component-(ui | bootstrap).(js | html)

  • VAADIN/build/webcomponenthtml-(hash).js

  • web-component/(exported-web-component-tag).js

Authentication Bypass when Fetching Static Resources

As mentioned earlier, some tools misrepresent getting static resources, especially client-engine JavaScript files (see the previous listing). These files shouldn’t be behind authentication, as they are necessary for the application to start, even before the user has authenticated.

Reported as: Authentication Bypass Using HTTP Verb Tampering

Temporary File Download

Some tools mark downloading the vaadinBootstrap.js file as an issue. This file is a required part of starting the application, and is a static resource.

Oracle Log File Information Disclosure

Some tools that check for this don’t check the content of the response, only the response status. Vaadin doesn’t send server log files to the client, even though the response status is set to 200.

Content Type Incorrectly Stated

This happens when Vaadin sends user events to the server and receives JSON data back. The response content type is text/plain, even though the response is JavaScript. This is done because some older Portlet vendors don’t treat JavaScript responses correctly, hence the client side receives incoherent instructions. The data returned from the server is never treated as a script on the client, so there is no security risk here.

Open Redirection – DOM-Based

This issue is reported because vaadinBootstrap.js indeed opens a new HTTP request. This is done to fetch the initial application state. On first request to an application URL, Vaadin replies with the bootstrap file, which, in turn loads the theme, widget set, and application state.

The way this request is done can’t be used by an attacker to modify the application state. Hence, this is a false positive.

Enabling X-Frame-Options

The X-Frame-Options are a way for web pages or applications to tell the browser that they shouldn’t be run inside frames (inside another page). This is done to try to ensure that these sites aren’t wrapped in malicious pages where attackers can intercept user actions.

Vaadin doesn’t automatically set the X-Frame-Options HTTP header, because many times applications need to run inside frames. Developers can set this header either in their server options or by using the Java Servlet API (for example, using the Vaadin BootstrapListener or creating a Servlet Filter).

E609B892-EB97-44B7-AE4B-A3571C62B3F0