O WildFly é um servidor de aplicação Java EE (Jakarta EE) de código aberto, responsável por executar aplicações web desenvolvidas em Java.
No SFA, o WildFly é utilizado para hospedar a aplicação Web (módulo de acesso via navegador), sendo responsável por gerenciar conexões, sessões, autenticação, além de servir como container para o deploy da aplicação.
As versões homologadas e testadas para funcionamento com o SFA são:
O WildFly pode ser baixado diretamente no site oficial do projeto:
https://www.wildfly.org/downloads
Na página, estão disponíveis versões Final e Preview.
Para o SFA, utilizar sempre a versão Final correspondente às versões homologadas.
No ambiente do SFA, o WildFly deve ser instalado em: /ws/serverapp/
Dessa forma, a estrutura de diretórios fica organizada da seguinte forma: /ws/serverapp/wildfly → instalação do WildFly
4.1 Configurações adicionais de segurança no standalone.xml
Neste tópico iremos abordar as configurações adicionais de segurança que devem ser feitas no standalone.xml; Abra o arquivo standalone.xml, localizado em:
● ?:/ws/serverapp/wildfly/standalone/configuration/
4.1.1 Habilitar protocolo TLS 1.3
No trecho indicado pela imagem, adicione “enabled-protocols="TLSv1.3".
Essa configuração define quais versões do protocolo de segurança TLS o servidor aceitará nas conexões HTTPS. Ao restringir para TLS 1.3, garantimos maior segurança, pois versões anteriores possuem falhas conhecidas. Assim, somente conexões modernas e seguras são permitidas, protegendo melhor os dados trafegados entre o sistema e os usuários.
(Antes)
(Depois)
4.1.2 Adicionar filtros de segurança
No trecho demonstrado nas imagens insira:
<filter-ref name="X-Frame-Options"/> <filter-ref name="x-xss-protection"/> <filter-ref name="strict-transport-security"/> <filter-ref name="content-security-policy"/> <filter-ref name="x-Content-type-options"/>
Essas configurações ativam filtros que adicionam cabeçalhos de segurança às respostas do servidor. Eles reforçam a proteção da aplicação contra ataques comuns, como roubo de dados, injeção de código e carregamento indevido em outros sites. Na prática, isso garante que o acesso ao sistema ocorra de forma mais segura, reduzindo riscos e fortalecendo a proteção das informações dos usuários.
(Antes)
(Depois)
4.1.3 Configurar filtros de cabeçalhos HTTP
No trecho indicado nas imagens, insira:
<filters> <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="strict-transport-security" header-name="Strict-Transport-Security" header-value="max-age=31536000; includeSubDomains"/> <response-header name="content-security-policy" header-name="content-security-policy" header-value="default-src 'self'; font-src 'self' data: use.typekit.net https://fonts.gstatic.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; script-src 'self' 'unsafe-inline' 'unsafe-eval' gmaps-utility-library.googlecode.com https://*.googleapis.com https://*.gstatic.com *.google.com https://static.zdassets.com blob:; img-src * data:; connect-src *; frame-src *;"/> <response-header name="x-Content-type-options" header-name="X-Content-Type-Options" header-value="nosniff"/> </filters>
Essa configuração define cabeçalhos de segurança que o servidor envia junto com as respostas HTTP, com o objetivo de proteger a aplicação contra ataques como injeção de código, clickjacking e acessos inseguros. Na prática, ela reforça a segurança dos dados e garante que a comunicação ocorra de forma confiável.
Ela é parecida com a configuração anterior, que apenas referencia filtros já definidos. A diferença é que, neste formato, os cabeçalhos e seus valores são definidos de forma personalizada, permitindo um controle mais detalhado sobre como cada proteção será aplicada.
(Antes)
(Depois)