> Markdown version of [Frequently Reported Issues](https://vaadin.com/docs/next/flow/security/advanced-topics/frequent-issues). Section index: [llms.txt](https://vaadin.com/docs/next/flow/llms.txt)

# Frequently Reported Issues (False Positives)

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.

## <a id="content-security-policy-csp-set-to-unsafe-values"></a>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 client-side engine, which is the part of the framework that runs in the browser. It consists of JavaScript logic for the communication protocol and DOM control, for example, but not of the application code. The engine is a static resource, and once it’s loaded, it’s started by a script that the bootstrap page includes inline. The engine then evaluates the JavaScript expressions that the server sends — those of `executeJs()` and of the event data expressions — by constructing functions from them in the browser, which is what `unsafe-eval` permits.

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

<!-- vale Vaadin.HeadingCase = NO -->

## <a id="v-curdate-v-wn-reported-as-csrf-tokens"></a>v-curdate & v-wn Reported as CSRF Tokens

<!-- vale Vaadin.HeadingCase = YES -->

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.

## <a id="cross-site-request-forgery-when-fetching-static-resources"></a>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:

<!-- vale Vale.Spelling = NO --><!-- vale Vale.Terms = NO -->

- 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

<!-- vale Vale.Terms = YES --><!-- vale Vale.Spelling = YES -->

## <a id="authentication-bypass-when-fetching-static-resources"></a>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

## <a id="temporary-file-download"></a>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.

## <a id="oracle-log-file-information-disclosure"></a>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.

## <a id="content-type-incorrectly-stated"></a>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.

## <a id="open-redirection-dom-based"></a>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, client-side engine, 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.

## <a id="enabling-x-frame-options"></a>Enabling X-Frame-Options

The `X-Frame-Options` HTTP header is 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 sends the `X-Frame-Options: SAMEORIGIN` header by default (since V25.2) with the application page, so that the application can only be shown in frames on the same origin. The header value can be changed with the `frameOptions` configuration parameter, for example to `DENY` to forbid framing entirely. Applications that are meant to be embedded in a frame on another origin must set the parameter to an empty value to disable the header. See [Configuration Properties](https://vaadin.com/docs/next/flow/configuration/properties.md) for how to set the parameter.

Vaadin only sets the header if the response doesn’t already contain an `X-Frame-Options` header. A header set by other means — for example, by Spring Security or a servlet filter — isn’t overwritten.

`E609B892-EB97-44B7-AE4B-A3571C62B3F0`