openxava / documentation / Web security (OWASP)

Table of contents

Web security (OWASP)
Configure your aplicación
Error pages
Same site cookies
Configure ROOT application
Disable web security
Since OpenXava 7.3 your applications can comply with OWASP Top Ten, which means having the highest security standards for web applications. In fact, OpenXava passes the OWASP ZAP web security test 100%, without any critical, medium or low level alerts.
This does not mean that applications made with OpenXava are automatically secure or automatically comply with the OWASP Top Ten, because your own code could be vulnerable, you could use your own vulnerable libraries, you could not correctly configure your application, not correctly configure your application server or disable some security feature of OpenXava. Therefore, it is important that you run the ZAP test on your application yourself, or even hire a security auditor to verify the security of your application and compliance with the required standards.

Configure your application

When you run your application in development, OpenXava uses an embedded Tomcat configured to meet all the necessary security requirements to pass the ZAP. However, when you generate a WAR and deploy it on your production Tomcat, your application may not be completely secure, nor pass the ZAP. You have to configure some details.

Error pages

To pass the ZAP, error pages cannot offer information about the server that is being used, let alone display an error trace. When you start the application from the embedded Tomcat for development, it is already configured to offer secure error pages. Also, if your application was created with OpenXava 7.3 or higher, the error pages are already well configured. But if you created your application with an OpenXava prior to v7.3 and you are deploying a WAR on a Tomcat, you will have to add the following in the web.xml of your application, which is located in src/main/webapp/WEB-INF of your project:
There is no need to create error404.html or error500.html, because they are included in openxava.jar.

Same site cookies

The same applies to cookie settings. If you use the embedded Tomcat or your application was created with v7.3+ there is no problem, but otherwise you have to define Same Site Cookies as Lax in the context.xml, located in src/main/webapp/META-INF. Add the entry <CookieProcessor sameSiteCookies="lax" />, as you see here:
    <JarScanner scanClassPath="false" />
    <CookieProcessor sameSiteCookies="lax" /> <!-- ADD THIS LINE -->

Configure ROOT application

The ZAP test, in addition to analyzing the URL of the application you indicate, also makes some checks in the root context where your application is deployed. The root context in Tomcat is defined by the ROOT application, if you do not have control over the ROOT application or you do not mind ignoring the indications that ZAP makes about the root context, you do not need to do anything. However, if you want to pass the ZAP 100% with your WAR deployed in Tomcat, you will have to make sure that the root application generates CSP headers and the X-Content-Type-Options header.
Unfortunately, there is no quick way to configure Tomcat for this. You will have to write the code for a filter that generates these headers. The following code may be useful to you:
import javax.servlet.*;
import javax.servlet.annotation.*;
import javax.servlet.http.*;

public class ContentSecurityPolicyFilter implements Filter {
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        HttpServletResponse httpResponse = (HttpServletResponse) response;
        httpResponse.setHeader("Content-Security-Policy", "default-src 'self'; frame-ancestors 'self'; form-action 'self';");
        httpResponse.setHeader("X-Content-Type-Options", "nosniff");
        chain.doFilter(request, response);
    public void init(FilterConfig cfg) throws ServletException { // For Tomcat 8.x
    public void destroy() { // For Tomcat 8.x
Compile the class and leave it inside webapps/ROOT/WEB-INF/classes of your Tomcat, in the same folder structure of the package where you have written the class. That is, if the class is in the package com.yourcompany.root.filters the ContentSecurityPolicyFilter.class should be left in the folder webapps/ROOT/WEB-INF/classes/com/yourcompany/root/filters of your Tomcat.
To recognize the filter, you have to ensure that metadata-complete is set to false in ROOT’s web.xml:

Finally, you should download ZAP and run it on your application deployed on your Tomcat.

Disable web security

It’s not a good idea to disable security, but if your application does not require strict security compliance and will be run in a secure environment, there may be times when it is convenient to disable web security either totally or partially. This may be necessary if we have a lot of our own old web code that does not follow good security practices or if we use third-party libraries that also do not comply with them.
Specifically, OpenXava, since version 7.3, has a strict Content Security Policy (CSP). This means that the browser is instructed not to do things that can potentially be dangerous. Which in turn restricts the things that can be used.
For example, you can only download images, scripts, CSSs or open frames from the same address from where the application has been downloaded. If we need to download resources from another site, it can be done by adding the properties trustedHostsForImages, trustedHostsForScripts, trustedHostsForStyles and trustedHostsForFrames in the file of our project, as in this example:
In this example, it is allowed to download images, JavaScript, CSSs and open iframes from Using these properties is not dangerous if the addresses we put are trustworthy. We can put several separated by commas.
On the other hand, by default, the CSP is configured to not allow the use of eval() in JavaScript. If we have our own code that uses eval() or a third-party library that needs it, we can enable the use of eval() with the following line in
Enabling the use of eval() is always dangerous, so this should be a temporary measure and you should start thinking about rewriting your code to not use eval() or update the corresponding JavaScript library.
In addition, the Content Security Policy (CSP) header can be completely disabled. Add to
Doing this is a quick way to see your application working if you have updated to version 7.3+ from an old version of OpenXava, but it constitutes a significant security risk, because strict CSP is what allows inhibiting most security risks.