Frequently Reported Issues
- Content-Security-Policy (CSP) Set to Unsafe Values
- v-curdate & v-wn Reported as CSRF Tokens
- Cross-Site Request Forgery when Fetching Static Resources
- Authentication Bypass when Fetching Static Resources
- Oracle Log File Information Disclosure
- Open Redirection – DOM-Based
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 for the framework to start its client-side engine in the browser. See Required Settings for why, and for how to run an application with a strict policy.
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:
-
VAADIN/build/(bundle-name)-(hash).(js | css)
-
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
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.
Open Redirection – DOM-Based
This issue is reported because the client-side bootstrap script opens a new HTTP request to the application URL. This is done to fetch the initial application state. On first request to an application URL, Vaadin replies with the bootstrap page, which in turn loads the client-side engine and the 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.
E609B892-EB97-44B7-AE4B-A3571C62B3F0