2
votes

Is there a way to configure the Http Headers that Wildfly(10 or more) sends to the client only to configure the following:

HTTPS Strict Transport Security (HSTS) X-XSS-Protection X-Frame-Options Strict-Transport-Security Content-Security-Policy X-Content-Type-Options

I have a configuration file(standalone.xml) where all the configurations are present. I need to add the configurations for headers here.

2

2 Answers

6
votes
    <subsystem xmlns="urn:jboss:domain:undertow:6.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other">
        <buffer-cache name="default"/>
        <server name="default-server">
            <http-listener name="default" socket-binding="http" max-parameters="10000" 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" predicate="not exists[%{o,Content-Security-Policy}]"/>
                <http-invoker security-realm="ApplicationRealm"/>
                <filter-ref name="Content-Security-Policy"/>                
                <filter-ref name="x-frame-options"/>
                <filter-ref name="x-xss-protection"/>
                <filter-ref name="x-content-type-options"/>
                <!--filter-ref name="content-security-policy"/-->
                <filter-ref name="strict-transport-security"/>
                <filter-ref name="my-custom-header"/>
            </host>
        </server>
        <servlet-container name="default">
            <jsp-config/>
            <websockets/>
        </servlet-container>
        <handlers>
            <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
        </handlers>
        <filters>
            <response-header name="server-header" header-name="Server" header-value="JBoss-EAP/7"/>
            <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
            <response-header name="Content-Security-Policy" header-name="Content-Security-Policy" header-value="default-src 'self'"/>   
            <response-header name="x-frame-options" header-name="X-Frame-Options" header-value="SAMEORIGIN"/>
            <response-header name="x-xss-protection" header-name="X-XSS-Protection" header-value="1; mode=block"/>
            <response-header name="x-content-type-options" header-name="X-Content-Type-Options" header-value="nosniff"/>
            <!--response-header name="content-security-policy" header-name="Content-Security-Policy" header-value="default-src https:"/-->
            <response-header name="strict-transport-security" header-name="Strict-Transport-Security" header-value="max-age=31536000; includeSubDomains;"/>             
            <!-- Add line below -->
            <response-header name="my-custom-header" header-name="my-custom-header" header-value="my-custom-value"/>
        </filters> 
    </subsystem>
2
votes

Adding bit more information to the @merly's response.

These are some of the application best practices while setting security headers to prevent illegal attempts on modifying/reading information.

Content-Security-Policy (CSP)
This header restricts the sources from which the browser will load resources including scripts, styles and media. By permitting only trusted sources and secure HTTPS channels, this header can help prevent XSS and sniffing attacks.

For sites that only load resources from a single web application server, configure the CSP header to only allow resources from that server for all resource types. If resources are loaded from other trusted sources, create a more specific CSP header.

<filter-ref name="Content-Security-Policy"/>
<response-header name="Content-Security-Policy" header-name="Content-Security-Policy" header-value="default-src 'self'"/>

X-Content-Type-Options
This header tells the browser not to infer a resource type by its content and stick to the content type advertised by the application. This can mitigate vulnarabilities such as XSS by preventing the browser from transforming non-executable content into executable content.

<filter-ref name="x-content-type-options"/>
<response-header name="x-content-type-options" header-name="X-Content-Type-Options" header-value="nosniff"/>

X-Frame-Options
If this header is set then it does not allow the application to be opened in the cross domain url.

<filter-ref name="x-frame-options"/>
<response-header name="x-frame-options" header-name="X-Frame-Options" header-value="SAMEORIGIN"/>