As páginas web modernas não são construídas exclusivamente a partir do JavaScript próprio de uma organização. Páginas de pagamento, ferramentas de análise, widgets de chat, sistemas de teste A/B, tags de publicidade e SDKs de pagamento podem carregar múltiplos scripts de terceiros. Se qualquer um desses scripts for comprometido, o código malicioso em execução no navegador do usuário pode contornar completamente os controles clássicos de nível de requisição de um WAAP.
Em fluxos de pagamento especificamente, o risco do lado do cliente não é mais apenas uma questão de melhores práticas. O PCI DSS 4.0 v4.0.1 tornou mais visível o controle, inventário e integridade dos scripts em execução nas páginas de pagamento. As organizações devem ser capazes de demonstrar quais fontes têm permissão para executar em quais páginas.
Pedir às equipes de aplicação que adicionem manualmente cabeçalhos CSP, HSTS, proteção de frame e política de referrer a cada página não é sustentável. As alterações de código são difíceis em aplicações legadas; nas modernas, diferentes equipes de serviço podem não aplicar o mesmo padrão de segurança de forma consistente. O resultado são cabeçalhos de segurança presentes em algumas páginas e ausentes em outras.
A abordagem correta é aplicar cabeçalhos de segurança do navegador centralmente, de forma independente do código da aplicação e a partir de uma posição baseada em política. O ADC deve reescrever cabeçalhos de resposta para padronizar CSP, HSTS, proteção contra clickjacking, prevenção de MIME sniffing, controle de referrer e limpeza de fingerprint.
O TR7 Client-Side Script Protection fornece esse modelo: aplica cabeçalhos de segurança fundamentais para risco do lado do cliente no nível do vService e vincula a segurança do navegador à política central do WAAP.
O TR7 implementa a proteção de scripts do lado do cliente por meio de reescrita de cabeçalhos de resposta, perfil CSP, limpeza de fingerprint e visibilidade de conformidade.
O TR7 aplica cabeçalhos de segurança durante a fase de resposta HTTP usando comportamento set-header ou add-header. Os controles de segurança do navegador podem ser ativados sem alterar o código da aplicação ou a estrutura de certificados.
O cabeçalho Content-Security-Policy comunica o modelo de origem permitida ao navegador. O TR7 fornece atualmente proteção CSP base por meio de uma abordagem fixa `default-src 'self';`.
Cabeçalhos como Server, X-Powered-By, X-AspNet-Version e X-AspNetMvc-Version podem ser removidos das respostas. Isso torna mais difícil para atacantes construir um inventário de tecnologia e associar CVEs.
vServices com uma regra securityHeaders ativa podem ser apresentados como evidência em relatórios de conformidade. Isso fortalece a trilha de auditoria para segurança de páginas de pagamento e processos de controle do lado do cliente.
A Proteção de Script do Lado do Cliente aplica 8 cabeçalhos de segurança prontos sob uma única regra securityHeaders.
O TR7 pode adicionar o cabeçalho Content-Security-Policy por meio da regra securityHeaders. O comportamento atual produz uma política de segurança base com `default-src 'self';`. Essa política visa um padrão do navegador que aceita apenas recursos da mesma origem. Requisitos de CSP mais complexos devem ser abordados por meio de configuração de cabeçalho personalizado ou alterações no lado da aplicação.
O cabeçalho Strict-Transport-Security pode ser aplicado em conexões TLS. Ele instrui o navegador a exigir HTTPS para o domínio relevante. Opções como includeSubDomains e preload fornecem comportamento de segurança mais rigoroso. O HSTS é aplicado apenas no contexto TLS para evitar que política incorreta seja emitida para hosts somente HTTP.
O cabeçalho X-Frame-Options pode ser aplicado com o valor SAMEORIGIN. Isso restringe a página de ser carregada dentro de um iframe em uma origem diferente. Ajuda a reduzir o risco de clickjacking especialmente em páginas de login, pagamento, painel administrativo e transações sensíveis. Fornece proteção base de baixo custo contra ataques de redirecionamento de interface do usuário.
O cabeçalho X-Content-Type-Options pode ser adicionado com o valor nosniff. Isso ajuda a impedir que o navegador adivinhe um tipo de conteúdo e execute conteúdo em um formato inesperado. O controle é especialmente valioso para fluxos de upload de arquivos, conteúdo estático e aplicações legadas que retornam tipos de conteúdo incorretos. O risco do lado do cliente por confusão de MIME é reduzido.
O cabeçalho Referrer-Policy pode ser aplicado com um padrão no-referrer-when-downgrade. Isso limita o vazamento de referrer em cenários como transições de HTTPS para HTTP. O comportamento do referrer é importante em URLs que carregam parâmetros de cidadão, cliente ou sessão. As organizações podem limitar centralmente a quantidade de informações de URL de origem que o navegador carrega para sites externos.
O cabeçalho Permission-Policy pode ser usado para restringir o acesso a recursos do navegador, como microfone, câmera, geolocalização e APIs similares. O TR7 aplica esse cabeçalho sob a regra securityHeaders para reduzir a superfície desnecessária de permissões do navegador. Em telas de portal, pagamento e administrativas, especialmente, isso impede que as páginas acessem APIs inesperadas. A segurança do lado do cliente não se limita apenas à origem do script.
Embora o cabeçalho X-XSS-Protection tenha efeito limitado nos navegadores modernos, ele pode ser usado para compatibilidade com clientes mais antigos. O comportamento `1; mode=block` ativa um filtro XSS básico em alguns navegadores legados. Esse cabeçalho não é uma garantia de segurança por si só e deve ser considerado junto com os controles CSP e WAAP. Fornece uma camada adicional de baixo custo para organizações com base de usuários legados.
O TR7 pode remover cabeçalhos como Server, X-Powered-By, X-AspNet-Version e X-AspNetMvc-Version. Esses cabeçalhos podem sugerir o servidor de aplicação, framework ou versão de runtime em uso. Os atacantes podem usar essas informações para correspondência de CVE e tentativas de exploit direcionadas. A limpeza de fingerprint é uma etapa prática de hardening que reduz a superfície de ataque visível.
securityHeaders pode ser vinculado como tipo de regra a condições específicas de vService, domínio ou caminho. Uma página de pagamento pode rodar com um conjunto mais restrito, um portal interno com um diferente, e uma aplicação legada com uma combinação mais permissiva. Isso evita que uma única política global de cabeçalhos quebre aplicações. Os operadores aplicam cabeçalhos de segurança de acordo com o contexto do serviço.
O TR7 implementa o escopo atual de proteção de scripts do lado do cliente na camada de cabeçalho de resposta. Nenhum agente JavaScript adicional, SDK de cliente ou proxy reverso separado é necessário. Essa abordagem fornece baixa latência e ampla compatibilidade. A capacidade atual real é a padronização de cabeçalhos de segurança; nenhuma alegação é feita sobre detecção de skimmer em tempo de execução ou injeção automática de SRI.
vServices com uma regra securityHeaders ativa podem ser apresentados em relatórios de conformidade. Isso facilita compartilhar com auditores exatamente onde os cabeçalhos de segurança de páginas de pagamento são aplicados. Suporta a produção de evidências técnicas para expectativas de segurança do lado do cliente sob o PCI DSS 4.0 v4.0.1 seção 6.4.3. Os relatórios tornam visível não apenas que uma política de cabeçalhos está configurada, mas em quais serviços ela está ativa.
Quando páginas HTML personalizadas são retornadas — como para proteção de bots ou bloqueio de acesso — os cabeçalhos de segurança podem ser mantidos no mesmo caminho de resposta. Isso evita que páginas de erro ou desafio retornem com cabeçalhos de segurança mais fracos do que a aplicação principal. Cada resposta apresentada ao usuário se aproxima do mesmo padrão base de segurança do navegador. A consistência é especialmente importante nos fluxos de login e verificação de bots.
A proteção de scripts do lado do cliente opera por meio de ordenação de cabeçalhos de resposta, condição HSTS, comportamento CSP fixo, tipo de regra securityHeaders e limpeza de fingerprint.
O TR7 pode substituir alguns cabeçalhos com set-header e adicionar outros com add-header. Essa distinção determina como os cabeçalhos de aplicação existentes se comportam. Antes de ir para produção, vale testar se os próprios cabeçalhos da aplicação entram em conflito com os adicionados pelo TR7.
O HSTS deve ser aplicado apenas em conexões TLS. O TR7 associa esse cabeçalho à condição ssl_fc para evitar que hosts somente HTTP recebam um cabeçalho HSTS indevido. Uma política HSTS incorreta pode causar problemas de acesso em alguns domínios, portanto deve ser usada com cuidado.
Quando o CSP é habilitado no comportamento atual do securityHeaders, o cabeçalho `default-src 'self';` é produzido como valor fixo. Não há editor de diretiva personalizada adicional dentro das capacidades ativas desta página. Para requisitos de CSP mais detalhados, uma regra de cabeçalho WAAP personalizada ou configuração no lado da aplicação deve ser planejada.
securityHeaders não funciona como uma regra de pontuação de assinatura WAAP. É tratado como uma regra de hardening de cabeçalho de resposta que é sempre aplicada. Como resultado, não está vinculado a uma pontuação de ataque ou resultado de limiar.
Os cabeçalhos Server, X-Powered-By, X-AspNet-Version e X-AspNetMvc-Version podem ser removidos. Remover esses cabeçalhos não altera o comportamento da aplicação; apenas reduz a visibilidade de informações de tecnologia externamente. Em aplicações legadas, essa etapa simples pode reduzir significativamente o vazamento de informações.
As políticas de CSP e frame podem afetar alguns componentes da aplicação. Páginas que usam scripts inline ou carregam conteúdo de fontes externas especialmente devem ser validadas primeiro em um ambiente de teste. A abordagem baseada em regras do TR7 torna simples testar uma política restrita em um caminho ou domínio limitado antes de implementá-la amplamente.
Equipes de e-commerce podem habilitar CSP, HSTS e limpeza de fingerprint do servidor no nível do vService em páginas de checkout. Essa configuração produz evidências técnicas reportáveis para controles de segurança do lado do cliente do PCI DSS 4.0 v4.0.1.
Portais bancários podem usar X-Frame-Options SAMEORIGIN e Permission-Policy para restringir incorporação de iframe não autorizada e acesso desnecessário à API do navegador. A superfície de ataque do lado do cliente em páginas de login e transações é reduzida.
Aplicações de setor público podem aplicar Referrer-Policy em páginas que carregam informações de URL sensíveis. Isso reduz o risco de fragmentos de URL vinculados a sessões de cidadãos ou contexto de transação serem carregados para sites externos.
Em aplicações .NET antigas ou similares, os cabeçalhos Server, X-Powered-By e de versão de framework podem vazar externamente. O TR7 remove esses cabeçalhos, tornando mais difícil para os atacantes construir um inventário de tecnologia.
Provedores de SaaS podem aplicar diferentes combinações de securityHeaders para cada vService de tenant. Tenants B2B podem rodar uma política mais permissiva onde os requisitos de conformidade permitem; os fluxos B2C podem usar um conjunto de cabeçalhos mais restrito.
CSP, HSTS, proteção contra clickjacking e limpeza de fingerprint do servidor — a partir de uma única política, sem tocar no código da aplicação. Deixe-nos mostrar uma configuração ao vivo nos seus próprios serviços.