Como configurar a Política de Segurança de Conteúdo para os relatórios FastReport .NET WEB

A Política de Segurança de Conteúdo (CSP) é uma ferramenta essencial para proteger aplicativos web contra ataques XSS, mas sua integração com sistemas de relatórios geralmente apresenta dificuldades. Nas versões mais recentes do FastReport .NET WEB, a arquitetura do lado do cliente foi significativamente reformulada, o que simplifica o cumprimento de uma CSP rigorosa sem perda da funcionalidade do relatório. Neste artigo, examinaremos como configurar corretamente a CSP para relatórios do FastReport e levar em consideração os riscos típicos.

Como a CSP funciona e por que ela é necessária

A Política de Segurança de Conteúdo (CSP) é um mecanismo de segurança ou até mesmo um padrão para aplicativos web que permite controlar quais recursos (scripts, estilos, fontes, imagens, conexões, etc.) podem ser carregados e executados em uma página. A CSP é implementada por meio do cabeçalho HTTP Content-Security-Policy ou da tag meta HTML.

O principal objetivo da CSP é prevenir ataques de Cross-Site Scripting (XSS) e a introdução de código malicioso. A política proíbe a execução de scripts não assinados ou não autorizados, mesmo que um invasor consiga injetar uma tag <script> na página.

Além disso, a CSP pode:

• Restringir o envio de dados para domínios de terceiros.
• Controlar o uso de eval() e construções semelhantes.
• Bloquear o carregamento de estilos, fontes ou plugins indesejados.

Diretivas CSP Principais

Valores CSP Principais

• 'self' — apenas o próprio domínio (incluindo esquema e porta).
• 'unsafe-inline' — permite scripts e estilos inline (use com cautela).
• 'unsafe-eval' — permite eval() e construções semelhantes.
• 'nonce-{value}' — token criptográfico de uso único.
• 'sha256-{hash}' — hash do conteúdo do script/estilo inline.
• data: — permite URLs data.
• https: — permite qualquer fonte HTTPS.

Exemplo de como habilitar a CSP em aplicativos ASP .NET Core:

app.Use(async (context, next) =>
{
	context.Response.Headers.ContentSecurityPolicy = "script-src 'self' 'unsafe-inline' 'unsafe-eval';style-src 'self' 'unsafe-inline'";
	await next();
});

Você também pode fazer isso na marcação HTML:

<meta http-equiv="Content-Security-Policy" 
      content="default-src 'self';
               script-src 'self';
               style-src 'self';
               img-src data: https:;
               object-src 'none';">

Mudanças na Arquitetura do Lado do Cliente do FastReport .NET WEB

Nas versões mais recentes do FastReport .NET WEB, a arquitetura do lado do cliente foi significativamente reformulada:

• Os scripts JavaScript foram movidos para arquivos estáticos – não é mais necessário especificar unsafe-inline para scripts.
• Os estilos para os controles se tornaram arquivos CSS estáticos – isso simplifica o gerenciamento da aparência.

Observação importante sobre estilos inline em relatórios: os estilos gerados para o conteúdo das páginas do relatório (tabelas, texto, bordas) permanecem inline. Para a exibição correta do relatório, é necessário permitir unsafe-inline na diretiva style-src.

Mover JS e CSS para arquivos estáticos não apenas forneceu compatibilidade com a CSP, mas também a capacidade de substituir os estilos do WebReport sem alterar os arquivos de origem (por exemplo, por meio de um arquivo CSS adicional com maior prioridade). Além disso, o comportamento foi expandido; agora você pode conectar seus próprios scripts, substituir métodos e adicionar manipuladores. E, claro, o cache foi aprimorado – o navegador carrega o conteúdo estático apenas uma vez.

Cenários para Contornar a CSP e Formas de se Proteger Contra Eles

Apesar da confiabilidade da CSP, existem cenários para contorná-la. A maioria deles não está relacionada às falhas do padrão, mas a erros de implementação.

1. Suporte Fraco do Navegador

O Internet Explorer oferece suporte parcial à CSP – pode ignorar diretivas importantes. Os navegadores modernos (Chrome, Opera, Safari, Firefox) funcionam corretamente.

Solução: Não dependa apenas da CSP em navegadores desatualizados – use mecanismos de segurança adicionais.

2. JavaScript Dentro de um iframe Automático

Ao abrir um documento de texto ou imagem, o navegador pode criar automaticamente um wrapper de iframe. Esta página não possui uma CSP configurada, o que permite a execução de código malicioso.

Solução: Configure a CSP para todas as páginas geradas, incluindo recursos para download.

3. Falta de CSP em Páginas de Erro (4xx, 5xx)

Os desenvolvedores geralmente protegem apenas as páginas que funcionam, esquecendo-se dos erros 404, 403, 500. Um invasor pode injetar um script em um frame com uma dessas páginas.

Solução: Aplique a CSP globalmente – por meio de middleware ou de um servidor web (Nginx, IIS, Apache).

4. Carregamento de Scripts de Serviços de Compartilhamento de Arquivos

Alguns sites usam armazenamento em nuvem (Google Drive) como fontes de conteúdo. Um invasor pode colocar um arquivo ou script malicioso lá.

Solução: Não use 'unsafe-inline' e https: em script-src se isso não for absolutamente necessário. Em vez disso, especifique domínios específicos: script-src 'self' https://trusted-cdn.com;

Conclusão: Segurança, Flexibilidade e Desempenho na Nova Versão do FastReport .NET WEB

Assim, a nova versão do FastReport .NET WEB permite que você use relatórios com segurança em aplicativos com uma política CSP rigorosa, minimizando exceções como unsafe-inline. Ao mesmo tempo, o desenvolvedor recebe:

• Segurança – proteção contra ataques XSS.
• Flexibilidade – fácil personalização da aparência e do comportamento.
• Desempenho – devido ao cache de conteúdo estático.

Implemente uma CSP rigorosa em seus projetos sem comprometer a funcionalidade dos relatórios.