How to configure CORS on WildFly

If you are running your web applications on WildFly, you can configure CORS to allow cross-domain requests. In this article, we will go through the steps to configure CORS on WildFly.

What is a Cross Resource Sharing (CORS)?

Cross-Origin Resource Sharing (CORS) is a security mechanism that allows web applications to make requests to a different domain than the one the application originated from. By default, web browsers enforce same-origin policies that prevent web applications from accessing resources on different domains. However, you can configure CORS to allow web applications to make cross-domain requests in a controlled manner.

There are two types of CORS: simple requests and non-simple requests.

A CORS request is simple if the following conditions are met:

  • It is issued against an API resource that allows only GET, HEAD, and POST requests.
  • If it is a POST method request, it must include an Origin header.
  • The request payload content type is text/plain, multipart/form-data, or application/x-www-form-urlencoded.
  • The request does not contain custom headers.

For simple CORS POST method requests, the response from your resource needs to include the following Header:

Access-Control-Allow-Origin: *

Or the Header is set to the origins allowed to access that resource.

All other CORS requests are non-simple requests and therefore you need to enable CORS support.

How to enable CORS in WildFly

When a browser receives a non-simple HTTP request, the CORS protocol requires the browser to send a preflight request to the server and wait for approval (or a request for credentials) from the server before sending the actual request. The preflight request appears to your API as an HTTP request that:

  • Includes an Origin header.
  • Uses the OPTIONS method.
  • Includes at least the following headers: Access-Control-Request-Method Access-Control-Request-Headers

Let’s see how to configure it in practice on WildFly application server. Start the CLI from the bin folder of the application server.

$ ./ -c

We will update Undertow’s configuration. At first, we will at first add a filter to Undertow’s configuration the Response Header’s fields:

/subsystem=undertow/configuration=filter/response-header="Access-Control-Allow-Methods":add(header-name="Access-Control-Allow-Methods",header-value="GET, POST, OPTIONS, PUT")
/subsystem=undertow/configuration=filter/response-header="Access-Control-Allow-Headers":add(header-name="Access-Control-Allow-Headers",header-value="accept, authorization, content-type, x-requested-with")

Then, we will bind these filters to the default-server of Undertow:


The above commands will reflect in the following XML Configuration:

 <subsystem xmlns="urn:jboss:domain:undertow:11.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other" statistics-enabled="${wildfly.undertow.statistics-enabled:${wildfly.statistics-enabled:false}}">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
        <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
        <host name="default-host" alias="localhost">
            <location name="/" handler="welcome-content"/>
            <http-invoker security-realm="ApplicationRealm"/>
                <filter-ref name="server-header"/>
                <filter-ref name="x-powered-by-header"/>
                <filter-ref name="Access-Control-Allow-Origin"/>
                <filter-ref name="Access-Control-Allow-Methods"/>
                <filter-ref name="Access-Control-Allow-Headers"/>
                <filter-ref name="Access-Control-Allow-Credentials"/>
                <filter-ref name="Access-Control-Max-Age"/>
    <servlet-container name="default">
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
        <response-header name="server-header" header-name="Server" header-value="WildFly/10"/>
        <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
        <response-header name="Access-Control-Allow-Origin" header-name="Access-Control-Allow-Origin" header-value="*"/>
        <response-header name="Access-Control-Allow-Methods" header-name="Access-Control-Allow-Methods" header-value="GET, POST, OPTIONS, PUT"/>
        <response-header name="Access-Control-Allow-Headers" header-name="Access-Control-Allow-Headers" header-value="accept, authorization, content-type, x-requested-with"/>
        <response-header name="Access-Control-Allow-Credentials" header-name="Access-Control-Allow-Credentials" header-value="true"/>
        <response-header name="Access-Control-Max-Age" header-name="Access-Control-Max-Age" header-value="1"/>

With this configuration in place, you have enabled CORS in WildFly application server.

As a proof of concept, you can check the Response Headers of WildFly’s Web Server using the Development Tools of your browser:

enable cors wildfly jboss

Enabling CORS (Cross-Origin Resource Sharing) filters on WildFly can help improve the accessibility of web applications by allowing cross-domain requests. By default, browsers block such requests due to security concerns, but with CORS, web developers can allow selected domains to access their web application. In this tutorial, we went through the process of enabling CORS filters on WildFly using the CLI commands for the Undertow subsystem. We added the necessary response headers to HTTP responses, which specified the allowed methods, headers, and credentials for cross-domain requests. By following these steps, you can ensure that your web application is accessible to a broader audience, while also maintaining security by limiting cross-domain access to only trusted domains. Overall, enabling CORS filters on WildFly is a relatively straightforward process that can provide significant benefits for your web application.