Um WAF e rate limiting sem precisar de um provedor de edge separado

Boa parte do que um provedor de edge/WAF dedicado vende é, na prática, só um proxy reverso fazendo bem o seu trabalho: checar a requisição antes dela chegar na aplicação, não depois. A Railyard já roda um proxy web na frente das aplicações de cada servidor — essas são as regras que rodam ali, a maioria configurável direto na aba Settings → Networking da própria aplicação, sem precisar de relação com nenhum provedor separado.

O que já está no ar hoje, sem ressalvas

• Regras de senha e IP. Coloque uma senha num staging ou ferramenta administrativa em um campo só; permita ou bloqueie endereços ou faixas CIDR específicas, com todo o resto recebendo um 403 limpo.
• Redirecionamentos e rewrites — até 100 regras, checadas em ordem, a primeira que casar vale. 301/302/307/308 ou um rewrite dentro da mesma aplicação que preserva a query string. Desativado durante o modo de manutenção, então uma regra de redirecionamento nunca esconde uma indisponibilidade real.
• Headers de resposta e CORS, até 50 regras. Defina um header, ou remova um que a sua aplicação enviou com -Name. Os preflights de CORS são respondidos pelo próprio proxy e nunca chegam até a aplicação — o que também significa que uma aplicação protegida por senha responde corretamente os preflights com 401 em vez de deixar escapar uma resposta de CORS antes.
• Seu próprio certificado SSL. Cole um certificado e chave PEM; a Railyard verifica se a chave corresponde ao certificado, se o certificado é válido agora, e se ele realmente cobre um dos endereços da aplicação — antes de salvar, não depois de algo quebrar. Armazenado criptografado, nunca retornado pela API, e deliberadamente mantido fora do railyard.yml para que uma chave privada nunca acabe indo pro git.
• Páginas de erro e manutenção, servidas com o código de status real (502/503/504) em vez de uma falha genérica em branco.

O que é real mas ainda está sendo lançado — dito com honestidade

Três funcionalidades existem e já são totalmente configuráveis hoje, mas precisam da própria imagem de edge proxy da Railyard num servidor, que ainda está sendo lançada em toda a frota. Até um determinado servidor ter isso, a regra fica salva mas não aplicada, e tanto o card de configurações quanto o log de deploy dizem isso claramente — nada aparenta estar ativo quando não está:

• Web Application Firewall — toda requisição checada contra o OWASP Core Rule Set (SQL injection, XSS, as outras categorias padrão do CRS) antes de chegar na aplicação. Três modos: desligado, detectar (registrado em log, nunca bloqueia — o primeiro passo certo para ver o que teria sido bloqueado antes de ativar a aplicação de fato), e bloquear (aplicado de verdade, retorna 403).
• Rate limiting — requisições por minuto por IP de cliente, configurável pra aplicação inteira e por rota (/login 10, /api/* 120). Passar do limite retorna 429 com Retry-After. Um limite real que vale saber: os contadores vivem na memória de cada servidor, então uma aplicação distribuída em vários servidores tem o limite por servidor, não um total global — e atrás do Cloudflare ou de outro proxy, todo visitante hoje aparece como o IP desse proxy.
• Bloqueio por país — listas de permissão/bloqueio por código de país de duas letras, UNK para endereços sem país conhecido, checado antes dos rate limits, redirecionamentos ou da própria aplicação. Endereços privados e internos sempre passam, independente disso.

Por que a honestidade importa especificamente aqui

Um WAF que não está aplicando nada silenciosamente é pior do que nenhum WAF, porque cria uma falsa confiança — exatamente a coisa que essa categoria de funcionalidade não pode errar. Dizer claramente “salvo mas ainda não aplicado” no próprio produto, não só num changelog, é a proteção real contra isso, e vale a pena dizer aqui também em vez de dar a impressão de que tudo acima está uniformemente no ar.

Referência completa: Edge rules.