CVE-2025-29927 e CVE-2025-66478…. e como reverse proxies com waf ajudam a mitigar o problema.

Higgs

Olá a todos!

Neste post a meio da semana vou falar sobre dois CVEs que deviam fazer soar todos os alarmes se têm aplicações Next.js em produção: CVE-2025-29927 e CVE-2025-66478.
E não, não estou a exagerar. Estamos a falar de vulnerabilidades críticas com scores CVSS de 9.1 e 10.0 respetivamente. Para contexto, um CVSS 10.0 é o máximo possível – é basicamente o sistema a dizer “isto está completamente fubar”.

Mas sejamos assertivos: não vim aqui só para vos assustar com números.
Vim falar de algo que devia ser óbvio mas que continua a ser ignorado por demasiadas equipas – a importância de ter reverse proxies com WAF/ModSecurity como primeira linha de defesa, especialmente quando patches não estão disponíveis ou quando a janela para aplicá-los é demasiado curta.
Acham que estou a exagerar? Procurem no reddit pela quantidade de pessoas a chorar com o XMRig instalado a socapa em containers e NodeJS abertos para o mundo, ou vejam este post.

O Que Diabos São Estas Vulnerabilidades?

Vamos começar pelo básico, porque estas vulnerabilidades são tecnicamente fascinantes e assustadoramente simples de explorar ao mesmo tempo.

CVE-2025-66478: Remote Code Execution em Next.js (CVSS 10.0)

Esta vulnerabilidade origina-se no protocolo React Server Components (RSC), mais especificamente no CVE-2025-55182 que é o bug upstream no React. O Next.js, ao usar este protocolo, herda o problema e amplifica-o através do App Router.
O problema é simples mas devastador: o protocolo RSC permite que inputs não confiáveis influenciem a execução server-side. Basicamente, o deserializador do React não valida adequadamente os dados que recebe, permitindo que um atacante envie payloads maliciosos que manipulam o prototype chain do JavaScript.

Sim, leram bem – prototype pollution que leva a Remote Code Execution. Em 2025. Num dos frameworks mais usados do mundo.

A exploração é tão elegante quanto assustadora. Um atacante envia um request POST com um header especial Next-Action e um payload multipart que contém JSON malicioso. O payload abusa do facto de o React usar dois pontos (:) para delimitar propriedades de objetos durante a deserialização. Algo como:

{"then":"$1:__proto__:constructor:constructor"}

Este payload navega pelo prototype chain até chegar ao constructor de Function, que permite execução de código JavaScript arbitrário no contexto do servidor. E pronto – Remote Code Execution completo.
As versões afetadas incluem praticamente todos os projetos Next.js modernos que usam o App Router: Next.js 15.0.0 a 15.5.6, Next.js 14.0.0 a 14.2.30, e várias outras versões anteriores. Se estão a usar React Server Components com App Router, estão vulneráveis. Ponto final.

CVE-2025-29927: Authorization Bypass em Next.js Middleware (CVSS 9.1)

Esta vulnerabilidade é diferente mas igualmente perigosa. O Next.js usa middleware para processar requests antes de chegarem à lógica principal da aplicação. É aqui que normalmente implementamos autenticação, autorização, rate limiting, e outras verificações de segurança.
O problema? O Next.js usa um header interno chamado x-middleware-subrequest para prevenir loops infinitos durante processamento de requests. Este header era suposto ser apenas para uso interno do framework.
Mas aqui está o plot twist: não há validação que impeça um atacante externo de enviar este header. E quando o Next.js vê este header, assume que é um request interno e… salta completamente a execução do middleware.
Deixem isto assentar por um momento. Todo o vosso sistema de autenticação e autorização? Bypassed. As vossas verificações de segurança? Ignoradas. Rate limiting? Keh isso?

A exploração é ridiculamente simples:

curl -H "x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware" \
     https://vulnerable-app.com/admin/secret-endpoint

Cinco repetições do valor middleware (ou src/middleware em versões mais recentes) são suficientes para atingir o MAX_RECURSION_DEPTH e forçar o Next.js a saltar o middleware completamente. Boom – acesso não autorizado a rotas protegidas.

Afeta Next.js versões 11.1.4 a 13.5.8, 14.0.0 a 14.2.24, e 15.0.0 a 15.2.2. E só é explorável se usarem middleware para segurança – o que, convenhamos, é praticamente toda a gente que leva segurança a sério em Next.js.

A Janela de Exposição

Aqui está a verdad: entre a divulgação de uma vulnerabilidade e a aplicação do patch existe uma janela temporal onde estamos completamente expostos.
Os patches para estas vulnerabilidades foram lançados. O CVE-2025-66478 foi resolvido nas versões 15.5.7+, 16.0.7+, e várias outras versões patch específicas. O CVE-2025-29927 foi corrigido nas versões 14.2.25, 15.2.3 e posteriores.

Mas aqui está o problema: quantas empresas conseguem fazer deploy de uma nova versão do Next.js em produção no espaço de horas após a divulgação de um CVE? Na teoria, devia ser simples – npm install next@latest, testes, deploy. Na prática?

  • Tens múltiplos ambientes (dev, staging, production) que precisam de ser atualizados
  • Tens dependências que podem não ser compatíveis com a nova versão
  • Tens código legacy que ficar tits up com mudanças no framework
  • Tens processos de aprovação e change management que demoram dias ou semanas
  • Tens janelas de manutenção limitadas onde podes fazer deploy

Mesmo equipas bem oleadas e com processos ágeis demoram dias a fazer este tipo de atualizações de forma segura. Equipas menos maduras? Semanas. Algumas empresas? Meses.
E durante todo este tempo, estão vulneráveis. Completamente expostos. Com exploits publicamente disponíveis no GitHub e atacantes a fazer scanning ativo. O Akamai Security Intelligence Group já reportou tentativas de exploração ativa para o CVE-2025-29927. A AWS Security publicou alertas sobre grupos de threat actors chineses a explorar rapidamente estas vulnerabilidades.

Esta janela de exposição é o verdadeiro problema. E é aqui que reverse proxies com WAF entram como salvadores.

Enter Apache Reverse Proxy com ModSecurity: A Primeira Linha de Defesa

Deixem-me ser claro: ter um reverse proxy com WAF não substitui fazer patches. Mas dá-vos tempo para fazer patches de forma controlada e segura, em vez de em modo de pânico às 3 da manhã.

A arquitetura é simples mas poderosa:

Internet → Apache Reverse Proxy com ModSecurity → Next.js Application

O Apache age como um guardião entre a internet selvagem e a vossa aplicação vulnerável. E com o ModSecurity configurado, conseguem bloquear tentativas de exploração antes sequer de chegarem ao Next.js.

Implementação Prática: Proteção Contra CVE-2025-29927

Vamos começar pelo mais simples – bloquear o CVE-2025-29927. Esta vulnerabilidade é trivial de mitigar ao nível do reverse proxy porque a exploração depende de um header HTTP específico.

Configuração Apache básica:

<VirtualHost *:443>
    ServerName your-nextjs-app.com
    
    # SSL Configuration
    SSLEngine on
    SSLCertificateFile /path/to/cert.pem
    SSLCertificateKeyFile /path/to/key.pem
    
    # ModSecurity Core Rules
    SecRuleEngine On
    
    # Block CVE-2025-29927: Strip x-middleware-subrequest header
    RequestHeader unset x-middleware-subrequest
    
    # Alternative: Block requests with this header entirely
    # SecRule REQUEST_HEADERS:x-middleware-subrequest "@rx ." \
    #     "id:1000001,phase:1,deny,status:403,\
    #      msg:'CVE-2025-29927 Exploitation Attempt Blocked'"
    
    # Reverse Proxy Configuration
    ProxyPreserveHost On
    ProxyPass / http://localhost:3000/
    ProxyPassReverse / http://localhost:3000/
    
    # Security Headers
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-XSS-Protection "1; mode=block"
    
    ErrorLog ${APACHE_LOG_DIR}/nextjs-error.log
    CustomLog ${APACHE_LOG_DIR}/nextjs-access.log combined
</VirtualHost>

Esta configuração faz duas coisas críticas:

  • Remove completamente o header x-middleware-subrequest de todos os requests. Se o header não chega ao Next.js, a vulnerabilidade não pode ser explorada.
  • Alternativamente (comentado), bloqueia diretamente qualquer request que contenha este header, retornando um 403 Forbidden.

Pessoalmente, prefiro a primeira abordagem porque é mais silenciosa e não alerta atacantes de que sabemos o que estão a tentar fazer. Mas ambas são eficazes.

Implementação Avançada: Proteção Contra CVE-2025-66478

O CVE-2025-66478 é mais complexo porque a exploração envolve payloads JSON em requests POST multipart. Não é tão simples como bloquear um header.

Mas ainda podemos mitigar significativamente o risco com ModSecurity:

# ModSecurity Rules for CVE-2025-66478 Protection

# Detect malicious RSC payloads with prototype pollution attempts
SecRule REQUEST_HEADERS:Next-Action "@rx ." \
    "id:1000002,phase:2,block,status:403,\
     chain,\
     msg:'Potential CVE-2025-66478 RCE Attempt'"
    SecRule REQUEST_BODY "@rx (__proto__|constructor\\.constructor)" \
        "t:lowercase,t:removeWhitespace"

# Block suspicious multipart requests to Next.js endpoints
SecRule REQUEST_HEADERS:Content-Type "@rx multipart/form-data" \
    "id:1000003,phase:2,pass,\
     chain,\
     setvar:'tx.multipart_request=1'"
    SecRule REQUEST_HEADERS:Next-Action "@rx ." \
        "chain"
        SecRule REQUEST_BODY "@rx (then|__proto__|constructor)" \
            "t:lowercase,block,status:403,\
             msg:'Blocked RSC Exploit Payload'"

# Rate limiting for Next-Action headers
SecAction "id:1000004,phase:1,nolog,pass,\
    initcol:ip=%{REMOTE_ADDR},\
    setvar:ip.next_action_counter=+1,\
    expirevar:ip.next_action_counter=60"

SecRule IP:NEXT_ACTION_COUNTER "@gt 10" \
    "id:1000005,phase:1,deny,status:429,\
     msg:'Rate limit exceeded for Next-Action requests'"

Esta configuração mais avançada:

  1. Detecta a presença do header Next-Action combinada com payloads suspeitos no body
  2. Procura por padrões conhecidos de prototype pollution (__proto__, constructor.constructor)
  3. Implementa rate limiting específico para requests com header Next-Action
  4. Bloqueia requests que combinam múltiplos indicadores de tentativa de exploração

É importante notar que estas regras podem ter falsos positivos se a vossa aplicação legitimamente usa algumas destas construções. Por isso, a recomendação é:

  1. Deploy inicial em modo pass (log only)
  2. Monitorizar logs durante 24-48 horas
  3. Ajustar regras baseado em padrões legítimos observados
  4. Mudar para modo block após validação

O Poder do Defense in Depth

Aqui está a beleza desta abordagem: estamos a implementar security em camadas. Mesmo se um atacante conseguir bypasser uma regra, outras regras ainda os podem apanhar.

Camada 1: Rate limiting por IP. Se alguém está a fazer scanning ou tentativas de exploração, vai rapidamente atingir os limites e ser bloqueado.
Camada 2: Header validation. Requests com headers suspeitos são bloqueados ou stripped.
Camada 3: Payload inspection. Mesmo que headers passem, payloads maliciosos conhecidos são bloqueados.
Camada 4: Behavioral analysis. Padrões de requests anormais podem ser detectados e bloqueados.

E finalmente, a aplicação Next.js em si, idealmente já patchada, mas agora com múltiplas camadas de proteção à frente.

ModSecurity Core Rule Set (CRS): O Vosso Melhor Amigo

Uma das coisas mais poderosas sobre o ModSecurity é o OWASP Core Rule Set (CRS). É um conjunto massivo de regras que protege contra praticamente todos os tipos de ataques web conhecidos: SQLi, XSS, RCE, LFI, RFI, e muito mais.

Instalar o CRS é trivial:

# Debian/Ubuntu
apt-get install modsecurity-crs

# Manual installation
cd /usr/share/modsecurity-crs/
git clone https://github.com/coreruleset/coreruleset.git

Configuração básica no Apache:

# In your Apache config or .htaccess

# Enable ModSecurity
SecRuleEngine On

# Include OWASP CRS
IncludeOptional /usr/share/modsecurity-crs/coreruleset/crs-setup.conf
IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/*.conf

# Set paranoia level (1-4, higher = more strict)
SecAction "id:900000,phase:1,nolog,pass,\
    t:none,\
    setvar:tx.paranoia_level=2"

# Set anomaly scoring threshold
SecAction "id:900110,phase:1,nolog,pass,\
    t:none,\
    setvar:tx.inbound_anomaly_score_threshold=5,\
    setvar:tx.outbound_anomaly_score_threshold=4"

O CRS usa um sistema de “anomaly scoring”. Cada request suspeito adiciona pontos. Se os pontos ultrapassam um threshold, o request é bloqueado. Isto reduz drasticamente falsos positivos comparado com regras de bloqueio direto.
Paranoia Level 2 é geralmente um bom compromisso entre segurança e usabilidade. Level 1 é muito permissivo. Level 3-4 são para ambientes de alta segurança mas vão gerar mais falsos positivos.

Nota: para quem já tem OWASP instalado aqui vão as regras drop-in:

99-CVE-2025-29927.conf

SecRule REQUEST_HEADERS_NAMES \
"@rx (?i)^x-middleware-subrequest" \
"id:1008,\
phase:2,\
block,\
msg:'CVE-2025-29927 Next.js middleware bypass attempt',\
logdata:'Matched Data: %{MATCHED_VAR} found within %{MATCHED_VAR_NAME}',\
tag:'paranoia-level/2',\
severity:'CRITICAL',\
setvar:'tx.rce_score=+%{tx.critical_anomaly_score}',\
setvar:'tx.anomaly_score_pl2=+%{tx.critical_anomaly_score}'"

99-CVE-2025-29927.conf

SecRule REQUEST_HEADERS_NAMES \
"@rx (?i)^x-middleware-subrequest" \
"id:1008,\
phase:2,\
block,\
msg:'CVE-2025-29927 Next.js middleware bypass attempt',\
logdata:'Matched Data: %{MATCHED_VAR} found within %{MATCHED_VAR_NAME}',\
tag:'paranoia-level/2',\
severity:'CRITICAL',\
setvar:'tx.rce_score=+%{tx.critical_anomaly_score}',\
setvar:'tx.anomaly_score_pl2=+%{tx.critical_anomaly_score}'"
[root@lxcvpar40 crs.custom]# cat 99-CVE-2025-55182.conf
# File: /etc/crs.custom/99-CVE-2025-55182.conf

# Block requests with prototype pollution patterns in POST bodies
SecRule REQUEST_METHOD "@streq POST" \
"id:2001,\
phase:2,\
chain,\
msg:'CVE-2025-55182 React2Shell prototype pollution attempt',\
severity:'CRITICAL',\
logdata:'Matched Data: %{MATCHED_VAR}',\
setvar:'tx.rce_score=+%{tx.critical_anomaly_score}'"

SecRule REQUEST_BODY "@rx (?:__proto__|constructor.*constructor|resolved_model)" \
"t:none,t:urlDecodeUni,t:jsDecode,\
block"

# Additional rule for RSC-specific patterns
SecRule REQUEST_HEADERS:next-action "!@rx ^$" \
"id:2002,\
phase:2,\
chain,\
msg:'CVE-2025-55182 React Server Component RCE attempt',\
severity:'CRITICAL',\
logdata:'RSC exploit pattern detected: %{MATCHED_VAR}'"

SecRule REQUEST_BODY "@rx \$@|child_process|exec\(|spawn\(" \
"t:none,t:urlDecodeUni,t:jsDecode,\
block"

Casos Reais:

Deixem-me partilhar um caso real (anonimizado, obviamente) onde esta arquitetura salvou uma empresa de um desastre.

Uma  fintech tinha uma aplicação Next.js em produção com autenticação e autorização implementadas em middleware. Quando o CVE-2025-29927 foi divulgado numa sexta-feira às 16h, entraram em pânico. Tinham transações financeiras sensíveis, dados de clientes, tudo protegido por esse middleware.

O problema? A nova versão do Next.js tinha breaking changes que quebravam parte do código deles. Estimavam precisar de 3-4 dias para fazer o upgrade de forma segura, incluindo testes completos.
Mas tinham Apache com ModSecurity à frente. Em 15 minutos, adicionaram a regra para strip o header x-middleware-subrequest. Deploy feito. Vulnerabilidade mitigada.
Durante o fim de semana, fizeram o upgrade do Next.js de forma controlada, com testes adequados. Na segunda-feira de manhã, tinham a aplicação patchada e puderam remover a regra temporária do ModSecurity.

Sem o reverse proxy? Teriam tido duas opções: fazer um upgrade apressado e arriscado na sexta à noite, ou desligar a aplicação durante o fim de semana. Nenhuma opção aceitável para uma fintech.

Isto é o valor real de defense in depth: opções. Tempo. Controlo.

Performance:

Sei o que estão a pensar: “Isto tudo soa bem, mas quanto overhead adiciona ao tempo de resposta?”

A resposta honesta? Depende. Mas provavelmente menos do que pensam.
ModSecurity em modo de inspection básico adiciona tipicamente 5-15ms de latência por request. Com regras complexas e corpo de request grande, pode chegar a 20-30ms.
Para uma aplicação Next.js típica que já demora centenas de milissegundos a gerar páginas, isto é noise. Completamente imperceptível para utilizadores finais.

Mas há truques para minimizar o impacto:

  1. Use buffering inteligente: Configure o ModSecurity para só inspecionar requests que realmente precisam de inspeção. Ficheiros estáticos? Skip. APIs públicas de leitura? Skip. POST requests para endpoints sensíveis? Full inspection.
  2. Tune as regras: Nem todas as regras do CRS são necessárias para todas as aplicações. Desativa regras que não se aplicam ao vosso caso de uso.
  3. Use caching agressivo: Requests que já passaram por validação podem ser cachados (com TTLs curtos). Isto reduz inspeções redundantes.
  4. Scale horizontally: Se o ModSecurity se tornar um bottleneck, adiciona mais instâncias do reverse proxy. É trivial escalar horizontalmente comparado com escalar a aplicação Next.js em si.

Na prática, em dezenas de implementações que fiz ou aconselhei, nunca vi o ModSecurity ser o bottleneck de performance. Normalmente, a aplicação em si é o limitador.

Monitoring e Alerting: Saber o Que Está a Acontecer

Uma regra de WAF que bloqueia silenciosamente não serve de nada se não sabem que está a bloquear. Monitoring e alerting são cruciais.

O ModSecurity tem logging no minimo verbose e só por si excelente. Cada request bloqueado gera logs detalhados:

[Fri Dec 13 14:23:45.123456 2025] [security2:error] [pid 12345] 
[client 203.0.113.42:54321] ModSecurity: Access denied with code 403 
(phase 2). Pattern match "x-middleware-subrequest" at REQUEST_HEADERS. 
[file "/etc/apache2/modsecurity.d/custom-rules.conf"] [line "42"] 
[id "1000001"] [msg "CVE-2025-29927 Exploitation Attempt Blocked"] 
[hostname "your-app.com"] [uri "/admin/users"] [unique_id "AbCdEf123"]

Estes logs podem ser ingeridos por qualquer SIEM ou sistema de logging. ELK stack, Splunk, Graylog, o que quer que usem.

Configuração básica com Fail2Ban para banning automático de IPs maliciosos:

# /etc/fail2ban/filter.d/modsecurity.conf
[Definition]
failregex = ModSecurity: Access denied.*\[client <HOST>\]
ignoreregex =

# /etc/fail2ban/jail.local
[modsecurity]
enabled = true
port = http,https
filter = modsecurity
logpath = /var/log/apache2/*error.log
maxretry = 5
bantime = 3600
findtime = 600

Esta configuração automaticamente bane IPs que tentam explorar vulnerabilidades 5 vezes em 10 minutos, por 1 hora. Ajustem os valores conforme necessário.
Para alerting em tempo real, integrem com o vosso sistema de monitoring existente. Prometheus pode fazer scrape de métricas do Apache. Grafana pode visualizar. AlertManager pode enviar notificações.
Exemplo de query Prometheus para alertar sobre tentativas de exploração:

rate(apache_errors_total{msg=~".*CVE-2025.*"}[5m]) > 10

Isto alerta se há mais de 10 tentativas de exploração por minuto. Indica scanning ativo ou um ataque coordenado.

O Custo da Inação: Porque Isto Importa

Alguns de vocês podem estar a pensar: “Isto parece trabalho. Vale mesmo a pena?”
Deixem-me colocar de outra forma: qual é o custo de não fazer isto?
Um único data breach pode custar milhões em multas, remediação, e danos reputacionais. O GDPR pode multar até 4% do revenue anual global. PCI-DSS pode revogar a capacidade de processar pagamentos. E isso é só o lado financeiro direto.

Há também o custo indireto:

  • Perda de confiança de clientes
  • Churn aumentado
  • Dificuldade em adquirir novos clientes
  • Escrutínio regulatório aumentado
  • Prémios de seguro cyber mais altos
  • Tempo de engenharia gasto em incident response

Comparado com isto, implementar um reverse proxy com ModSecurity é trivial. Estamos a falar de talvez um dia de trabalho para setup inicial, mais manutenção mínima depois disso.
E não esqueçam: estas vulnerabilidades não são teóricas. Há PoCs públicos. Há scanning ativo. Há grupos de threat actors a explorar ativamente. A pergunta não é “se” vão ser atacados, mas “quando”.

Lições Aprendidas e Melhores Práticas

Depois de anos a implementar e gerir WAFs em produção, aqui estão as lições mais importantes:

1. Deploy em staging primeiro, sempre. Nunca experimentem regras novas diretamente em produção. Testem em staging, monitorizem, ajustem.

2. Comecem em modo log-only. Novas regras devem começar em modo pass (log only). Só depois de validação muda para block.

3. Mantenham regras versionadas em Git. Configuration as Code não é apenas para aplicações. As vossas regras de segurança devem estar versionadas e reviewable.

4. Monitorizem falsos positivos ativamente. Um WAF que bloqueia tráfego legítimo é tão mau quanto não ter WAF. Monitorizem e ajustem.

5. Documentem exceções. Quando tiverem que whitelist algo, documentem porquê. Daqui a 6 meses não vão lembrar-se.

6. Mantenham o CRS atualizado. O OWASP CRS é atualizado regularmente com proteções para novas vulnerabilidades. Façam update regular.

7. Testem as vossas defesas. Periodicamente, tentem explorar as vossas próprias aplicações. Pentesting não é só para grandes empresas.

8. Tenham um plano de rollback rápido. Se uma regra nova causar problemas, precisam de conseguir fazer rollback em segundos, não horas.

O Futuro: Zero Trust e Defense in Depth

Este tipo de arquitetura com reverse proxies e WAFs encaixa perfeitamente numa filosofia de Zero Trust.
Zero Trust não é confiar em nada por default. Nem na rede. Nem na aplicação. Nem no utilizador. Tudo tem que ser validado, sempre.
O reverse proxy com WAF é uma implementação prática de Zero Trust ao nível de aplicação. Cada request é validado. Cada payload é inspecionado. Nada passa sem scrutínio.
E à medida que as ameaças evoluem, esta arquitetura pode evoluir também. Novas vulnerabilidades descobertas? Adicionem novas regras. Novos padrões de ataque? Ajustem o detection. A aplicação em si pode ficar parada enquanto a camada de proteção se adapta.

Isto é defense in depth no seu melhor. Múltiplas camadas, cada uma independente mas complementar. Se uma camada falhar, outras ainda protegem.

Ferramentas Alternativas e Complementares

Embora este post foque em Apache + ModSecurity, há outras opções excelentes:

Nginx + ModSecurity: Nginx como reverse proxy com módulo ModSecurity. Performance ligeiramente melhor que Apache em alguns cenários.
Cloudflare WAF: Se estão em Cloudflare, o WAF deles já tem regras para estas vulnerabilidades. Mas implica enviar todo o tráfego pelo Cloudflare.
AWS WAF / Azure WAF: Se estão em cloud pública, os WAFs nativos são opções sólidas. Integração fácil mas vendor lock-in.
Traefik: Reverse proxy moderno com suporte para ModSecurity via plugins. Ótimo para ambientes Kubernetes.
Envoy Proxy: Usado em service meshes como Istio. Pode integrar com ext_authz para validação customizada.

A escolha depende do vosso stack existente e preferências arquiteturais. O importante é ter algo. Qualquer coisa é melhor que nada.

Pensamentos Finais

Estas vulnerabilidades em Next.js não são as últimas. Vão haver mais CVEs críticos. Vão haver mais zero-days. Vão haver mais situações onde precisam de mitigação urgente enquanto patches não estão disponíveis.
A questão não é “se” mas “quando”. E quando acontecer, vão agradecer ter implementado defesas em profundidade. Vão agradecer ter um reverse proxy com WAF que vos dá tempo para reagir de forma controlada.
Implementar Apache com ModSecurity é sexy. Não é a tecnologia mais nova e brilhante. Mas é muito eficaz. É testado em batalha. É open source. E funciona.
Para quem está no mundo de desenvolvimento web, especialmente se usam Next.js, React Server Components, ou qualquer framework moderno com server-side rendering, recomendo vivamente que considerem esta arquitetura. O custo é mínimo. O benefício é imenso. O risco de não fazer? Potencialmente catastrófico.

Como sempre, se tiverem dúvidas, experiências para partilhar, ou quiserem discutir implementações específicas, já sabem onde me encontrar. Estas discussões técnicas sobre segurança são sempre enriquecedoras.
E lembrem-se: segurança não é um produto que se compra. É um processo que se implementa. E esse processo inclui ter múltiplas camadas de defesa, especialmente quando a primeira linha (a aplicação em si) pode ter vulnerabilidades.

Até ao próximo post, mantenham-se seguros.

Abraço,
Nuno

Related Posts