sech0us3/waf-checkerFerramenta automatizada de avaliação de WAF que detecta fornecedores de firewall, testa 19 categorias de ataque com payloads de evasão avançados e fornece análise de bypass codificada por cores via CLI, Cloudflare Worker ou Docker.
# Verificador de WAF
[](https://github.com/SecH0us3/waf-checker/releases)
[](https://github.com/SecH0us3/waf-checker/releases)
[](packages/core)
[](packages/cli)
[]()
Este projeto ajuda você a verificar quão bem seu Web Application Firewall (WAF) protege seu produto contra ataques web comuns. Ele pode ser executado como um Cloudflare Worker (com uma interface Web interativa integrada) ou como uma ferramenta CLI autônoma para Node.js.
## 🧪 Cobertura de Testes e Status
Todos os pacotes são minuciosamente testados com suítes automatizadas de testes unitários, de integração, baseados em propriedades (fuzzing com fast-check), de resiliência de rede e de engenharia reversa (100% de conformidade com segurança SSRF, técnicas de evasão de protocolo e formatadores de relatórios):
| Pacote | Cobertura de Linhas | Instruções | Funções | Suíte de Testes |
| :--- | :---: | :---: | :---: | :---: |
| [**`@waf-checker/core`**](https://github.com/sech0us3/waf-checker/blob/main/packages/core) | `93.0%` 🟢 | `92.6%` | `96.4%` | 🟢 282 passando |
| [**`@waf-checker/cli`**](https://github.com/sech0us3/waf-checker/blob/main/packages/cli) | `93.5%` 🟢 | `92.8%` | `96.7%` | 🟢 54 passando |
| [**`@waf-checker/worker`**](https://github.com/sech0us3/waf-checker/blob/main/packages/worker) | `Passando` 🟢 | — | — | 🟢 30 passando |
| **Suíte Total do Monorepo** | **`93.2%`** | **`92.7%`** | **`96.6%`** | **🟢 366 testes passando** |
## Recursos
### Testes Principais
- Insira uma URL de destino, escolha métodos HTTP (GET, POST, etc.) e categorias de ataque.
- Envia requisições com payloads de ataque (em parâmetros, cabeçalhos ou como caminhos de arquivo).
- Resultados no terminal e na web com código de cores: 🟢 403/BLOQUEADO = bloqueado, 🔴 2xx/5xx = possível bypass, 🟠 3xx = redirecionamento.
- Resultados exibidos em uma tabela filtrável com detalhes para cada payload.
### 🕵️ Engenharia Reversa de WAF e Matriz CRS (`--reverse`)
- **Mapeamento do OWASP Core Rule Set (CRS v3/v4)**: Audita IDs de regras ativas versus desativadas (`920xxx`, `921xxx`, `930xxx`, `931xxx`, `932xxx`, `933xxx`, `934xxx`, `941xxx`, `942xxx`, `943xxx`, `944xxx`) com Níveis de Paranoia (PL1-PL4).
- **Detecção de Limite do Corpo de Inspeção**: Sondagem por busca binária (8KB – 128KB, precisão ~1KB) para identificar os limites de truncamento do buffer.
- **Detecção do Modo de Pontuação de Anomalias**: Sonda o modo de pontuação colaborativa versus o modo de bloqueio estrito por regex e identifica os limites de pontuação.
- **Sondagem Segura de Limite de Taxa**: Aumento gradual seguro até 30 req/s com encerramento antecipado imediato ao receber HTTP 429 e extração de `Retry-After`.
### 🛡️ Patching Virtual de WAF e Correção Automática (`--patch` / comando `patch`)
- **Mitigação Instantânea**: Transforma automaticamente os bypasses de WAF detectados (HTTP 200) em regras de firewall prontas para implantação, configurações de proxy reverso e Infraestrutura como Código (Terraform HCL / Cloud CLI).
- **Plataformas Suportadas (11 Dialetos)**:
- **Cloudflare WAF**: Expressões Wirefilter (`http.request.uri.query contains ...` / `matches ...`) e `cloudflare_ruleset` Terraform HCL.
- **AWS WAF v2**: Declarações de Regras JSON nativas (`ByteMatchStatement`, `RegexPatternSet`, `OrStatement`) e `aws_wafv2_rule_group` Terraform HCL.
- **Google Cloud Armor**: Expressões CEL (`request.path.matches(...)`, `request.headers[...]`), comandos CLI `gcloud compute security-policies` e Terraform `google_compute_security_policy`.
- **Azure WAF (Front Door e App Gateway)**: Definições JSON de Regras Personalizadas, comandos CLI `az network front-door waf-policy` e Terraform `azurerm_cdn_frontdoor_firewall_policy`.
- **ModSecurity e OWASP Coraza**: Diretivas `SecRule` compatíveis com OWASP CRS (SecLang) com colapso de tokens `@pm`. Suportado via `--patch modsecurity` ou `--patch coraza`.
- **NGINX**: Blocos de configuração nativos `location ~* \.(ext)$ { return 403; }`, `location ~ /\.(git|svn)` e `map`.
- **HAProxy**: ACLs nativas de alto desempenho (`path_end -i`, `path_beg -i`, `query -m sub -i`, `req.hdr()`) com `http-request deny deny_status 403`.
- **Caddy Server**: Matchers nomeados idiomáticos do Caddyfile (`@waf_patch_*`) com expressões CEL (`expression {http.request.uri.query}.matches(...)`) e `respond 403`.
- **Apache HTTP Server**: Regras `mod_rewrite` (`RewriteCond %{QUERY_STRING}` / `%{REQUEST_URI}` / `%{HTTP_USER_AGENT}` + `RewriteRule ^ - [F,L]`) para `httpd.conf`, `<VirtualHost>` ou `.htaccess`. Suportado via `--patch apache`.
- **Envoy Proxy**: Entradas de rota correspondendo a `:path`/cabeçalhos via `safe_regex` RE2 com `direct_response: 403` (ou encaminhar-e-marcar no modo de simulação) para um virtual_host de route_configuration. Suportado via `--patch envoy`.
- **Kubernetes Ingress (K8s)**: Manifests YAML `kind: Ingress` prontos para produção com anotações `nginx.ingress.kubernetes.io/server-snippet`.
- **Defesa em Duas Camadas**:
- **Hotfix Estrito**: Assinaturas de token exatas com **risco de falso positivo de 0%** para resposta imediata a incidentes de dia zero.
- **Padrão Heurístico**: Expressões regulares generalizadas cobrindo toda a estrutura da classe de vulnerabilidade.
- **Web UI Remediation Studio**: Modal interativo do painel com pré-visualizações ao vivo em todos os fornecedores, cópia para a área de transferência com 1 clique, alternância de formatos e exportação de arquivos.
### Categorias de Ataque (28 no total)
Injeção de SQL, XSS, Injeção de Comandos, Path Traversal, SSRF, Inclusão de Arquivo Local, Arquivos Sensíveis, Redirecionamento Aberto, SSTI, XXE, Injeção NoSQL, Injeção GraphQL, Ataque JWT (Cabeçalho), Ataque JWT (Parâmetro), Prototype Pollution (Corpo JSON), Prototype Pollution (URL/Parâmetro), Injeção LDAP, Injeção XPath, Injeção de Fórmula de Planilha, Log4Shell (JNDI), Injeção CRLF, Poluição de Parâmetros HTTP, User-Agent, Bypass de IP, HTTP Request Smuggling, Web Cache Poisoning, Bypass UTF8/Unicode, Bypass de Limite de Inspeção de WAF (Padding).
### Detecção de WAF
- Detecção automática do tipo de WAF antes dos testes (Cloudflare, AWS WAF, OWASP Coraza, BunkerWeb, ModSecurity, Akamai, Imperva, F5 BIG-IP, etc.).
- Sugere técnicas de bypass específicas com base no WAF detectado.
- Pode alternar automaticamente para payloads avançados específicos do WAF.
### Payloads Avançados e Codificação
- Payloads de Bypass de WAF — codificação dupla, unicode, caixa mista, injeção de comentários, payloads poliglotas.
- Payloads Aprimorados — técnicas modernas de evasão.
- Variações de Codificação — codificação URL, Unicode, Entidade HTML, Hex, Octal, Base64 com combinações automáticas.
- Bypasses específicos de WAF para Cloudflare, AWS WAF, ModSecurity.
### Manipulação do Protocolo HTTP
- HTTP Verb Tampering — testa métodos HTTP incomuns.
- Parameter Pollution — duplica e divide parâmetros entre query/body.
- Content-Type Confusion — tipos de conteúdo alternativos para contornar regras.
- Cabeçalhos de Request Smuggling.
- Variações de Host Header Injection.
- HTTP Method Override via cabeçalhos (`X-HTTP-Method-Override`, etc.).
### Testes em Lote
- Testa múltiplos URLs de uma só vez.
- Concorrência e atraso entre requisições configuráveis.
- Acompanhamento de progresso em tempo real.
### 🔀 Diff de Regressão (`--compare` / `--fail-on-regression`)
- Compara uma varredura com um relatório JSON previamente salvo para revelar **novos bypasses** (anteriormente bloqueados, agora não), payloads **recém-bloqueados** e testes adicionados/removidos.
- Gate de CI (`--fail-on-regression`) que falha apenas em postura de WAF *piorada*, não na lista completa de resultados — ideal para detectar desvios em managed-rulesets.
---
## Estrutura do Projeto
O projeto está estruturado como um monorepo NPM Workspaces:
- [**`packages/core/`**](file:///Users/alex/src/waf-checker/packages/core): A biblioteca central de testes de segurança, definição de payloads, assinaturas de fingerprinting de WAF e codificadores de ofuscação.
- [**`packages/worker/`**](file:///Users/alex/src/waf-checker/packages/worker): Pacote Cloudflare Worker que serve a Web UI estática em HTML/JS e os endpoints da API JSON.
- [**`packages/cli/`**](file:///Users/alex/src/waf-checker/packages/cli): Ferramenta de interface de linha de comando Node.js para executar auditorias diretamente do seu terminal.
---
## Instalação e Compilação
A partir do diretório raiz, instale as dependências e compile todos os workspaces:
```bash
npm install
npm run build
```
## Como Executar
### 1. Versão Web (Cloudflare Worker)
Para executar o servidor de desenvolvimento do Worker localmente (requer Wrangler):
```bash
npm run dev:worker
```
A interface Web estará acessível em `http://localhost:8787` (ou em outra porta, caso a 8787 esteja ocupada).
Para implantar o Worker na Cloudflare:
```bash
npx wrangler deploy --workspace=packages/worker
```
O Worker precisa do plano **Workers Paid**: as páginas de verificação e auditoria são dimensionadas para os seus 10.000 subpedidos por pedido (`[limits] subrequests` em `wrangler.toml`, `WORKER_SUBREQUEST_LIMIT` em `packages/core/src/check.ts`). O plano Free permite apenas 50 subpedidos externos por pedido: uma página de verificação com o teste de contorno de User-Agent (ativado por predefinição na UI) ou com redirecionamentos seguidos ultrapassa esse limite.
### 2. Versão CLI (Node.js)
#### Instalá-la como um comando global `waf-checker` (recomendado)
Após `npm install && npm run build` na raiz do repositório, crie a ligação da CLI para que esta seja executada
a partir de **qualquer diretório** — sem `cd` para o repositório e sem caminhos longos `node .../dist`:
```bash
# Expose `waf-checker` on your PATH from the built workspace
npm link --workspace @waf-checker/cli
# …now, from anywhere:
waf-checker --help
waf-checker check https://example.com
# Uninstall later with:
npm rm -g @waf-checker/cli
```
O pacote publicado inclui seu código, então você também pode instalar uma build empacotada globalmente sem o repositório: `npm pack --workspace @waf-checker/cli` e depois `npm i -g ./waf-checker-cli-*.tgz`.
#### Autocompletar do shell (bash / zsh / fish)
`waf-checker completion <shell>` imprime um script de autocompletar (omita `<shell>` para detectar automaticamente a partir de `$SHELL`):
```bash
# bash
waf-checker completion bash | sudo tee /etc/bash_completion.d/waf-checker
# or, without root: echo 'source <(waf-checker completion bash)' >> ~/.bashrc
# zsh (into a directory on your $fpath)
waf-checker completion zsh > "${fpath[1]}/_waf-checker"
# fish
waf-checker completion fish > ~/.config/fish/completions/waf-checker.fish
```
#### Executando sem uma instalação global
Você sempre pode invocar o entrypoint compilado diretamente:
```bash
# Print general CLI help and usage
node packages/cli/dist/index.js --help
# Print check command help (lists all methods, categories, and WAF vendors)
node packages/cli/dist/index.js check --help
# Discover detectable WAF vendors and payload categories (JSON for automation)
node packages/cli/dist/index.js list-wafs --json
node packages/cli/dist/index.js list-categories --json
```
#### Detecção de WAF
Detecte o fornecedor do WAF por trás de uma URL de destino:
```bash
node packages/cli/dist/index.js detect <url>
```
#### Auditoria de payload de vulnerabilidade
Execute uma auditoria contra uma URL de destino:
```bash
# Default check (GET method, all payload categories)
node packages/cli/dist/index.js check https://example.com
# Custom check with specific methods, categories, and WAF evasion enabled
node packages/cli/dist/index.js check https://example.com -m GET,POST -c "SQL Injection,XSS" --auto-detect-waf --encoding-variations
```
#### Auditorias em Lote
Execute auditorias em lote para uma lista de URLs definidas em um arquivo:
```bash
node packages/cli/dist/index.js batch targets.txt --concurrency 3
```
#### Gerando Relatórios
Salve os resultados da auditoria nos formatos **SARIF**, **JUnit XML**, **HTML**, **Markdown**, **CSV** ou **JSON**:
```bash
# Generate SARIF report for GitHub Code Scanning
node packages/cli/dist/index.js check https://example.com -o results.sarif
# Generate JUnit XML for CI test reporting (GitHub Actions, GitLab CI, Jenkins)
node packages/cli/dist/index.js check https://example.com -o results.xml
# Generate interactive HTML report
node packages/cli/dist/index.js check https://example.com -o report.html
# Generate Markdown summary for CI
node packages/cli/dist/index.js check https://example.com -o summary.md
```
> O formato do relatório é deduzido a partir da extensão do arquivo de saída, ou definido explicitamente com `-f, --format` (`json`, `csv`, `html`, `sarif`, `markdown`, `junit`). Cada payload de ataque torna-se um `<testcase>` JUnit; os bypasses de WAF são reportados como `failure`s e os erros de transporte/servidor como `error`s, para que os runners de CI os exibam diretamente.
#### Integração CI/CD e Limites de Proteção
Falhe pipelines de CI/CD quando a taxa de proteção estiver abaixo do limite exigido ou quando forem detectados bypasses:
```bash
# Fail if WAF protection rate is below 95%
node packages/cli/dist/index.js check https://example.com --threshold 95 -q
# Fail immediately on any detected bypass
node packages/cli/dist/index.js check https://example.com --fail-on-bypass -q
```
#### 🔀 Diff de Regressão (Scan vs Scan)
A postura do WAF varia ao longo do tempo — um fornecedor lança uma atualização de conjunto de regras gerenciadas, uma regra do CRS é desativada, uma mudança de origem altera um veredito. Em vez de triar novamente a lista completa de resultados a cada execução, compare com um relatório JSON salvo anteriormente e condicione o CI apenas ao *agravamento*. Um payload que estava `blocked` no relatório de linha de base e não está mais bloqueado conta como uma regressão; um payload recém-bloqueado conta como uma melhoria. A correspondência é feita por `(category, method, evasion technique, payload)`, e erros de rede / bloqueios do lado da origem são tratados como inconclusivos, para que nunca apareçam como falsas regressões.
```bash
# Save a known-good baseline report
node packages/cli/dist/index.js check https://example.com -f json -o baseline.json -q
# Later: diff the current scan against it and print regressions/improvements
node packages/cli/dist/index.js check https://example.com --compare baseline.json -q
# Fail CI only when a previously-blocked payload is no longer blocked
node packages/cli/dist/index.js check https://example.com --compare baseline.json --fail-on-regression -q
```
#### 🛡️ Virtual Patching e Correção Automática
Gere automaticamente regras de firewall prontas para implantação em todas as 11 plataformas suportadas (`cloudflare`, `aws`, `gcp`, `azure`, `modsecurity`, `nginx`, `haproxy`, `caddy`, `apache`, `envoy`, `k8s`, ou `all`):
```bash
# Generate and save Cloudflare Terraform rules during audit
node packages/cli/dist/index.js check https://example.com --patch cloudflare --patch-output ./cloudflare-patch.tf
# Generate GCP Cloud Armor gcloud commands and Terraform
node packages/cli/dist/index.js check https://example.com --patch gcp --patch-output ./cloud-armor.sh
# Generate Azure WAF rules with simulation (Log) mode
node packages/cli/dist/index.js check https://example.com --patch azure --patch-action simulate --patch-output ./azure-rules.json
# Generate HAProxy ACLs for haproxy.cfg
node packages/cli/dist/index.js check https://example.com --patch haproxy --patch-output ./haproxy-patches.cfg
# Generate Caddyfile named matchers
node packages/cli/dist/index.js check https://example.com --patch caddy --patch-output ./patches.caddyfile
# Generate Apache mod_rewrite rules for .htaccess
node packages/cli/dist/index.js check https://example.com --patch apache --patch-output ./patches.htaccess
# Generate Kubernetes Ingress YAML manifests
node packages/cli/dist/index.js check https://example.com --patch k8s --patch-output ./ingress-patch.yaml
# Generate patches for all vendors from a saved JSON audit report file
node packages/cli/dist/index.js patch audit-report.json --waf all --output ./patches/
```
#### 🐳 Teste de Ambiente Local com Docker e Staging (`--allow-local`)
Por padrão, o `waf-checker` bloqueia estritamente faixas de IP privadas (`127.0.0.1`, `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`) para prevenir Server-Side Request Forgery (SSRF). Ao testar seus próprios contêineres Docker locais ou servidores de staging, use `--allow-local`:
```bash
# Audit a local OWASP ModSecurity Docker container and run reverse engineering
node packages/cli/dist/index.js check http://127.0.0.1:8088/ --allow-local --reverse
# Audit a local Caddy or HAProxy reverse proxy and generate patches
node packages/cli/dist/index.js check http://127.0.0.1:8089/ --allow-local --patch caddy
```
#### 🧪 Suíte E2E Automatizada com Docker ao Vivo (`npm run test:e2e`)
Execute auditorias de integração ponta a ponta contra contêineres Docker ativos (ModSecurity CRS, Caddy, HAProxy, NGINX e Backend) em um único comando:
```bash
npm run test:e2e
```
Consulte o [Guia completo de Testes Locais de WAF e Validação E2E](https://github.com/sech0us3/waf-checker/blob/main/docs/LOCAL_WAF_TESTING.md) para benchmarks completos, diagramas de arquitetura e etapas de reprodução manual.
---
## 🚀 GitHub Action (CI/CD)
Integre testes automatizados de segurança de WAF ao seu fluxo de trabalho do GitHub Actions:
```yaml
name: WAF Security Audit
on:
push:
branches: [ main ]
schedule:
- cron: '0 0 * * 1' # Weekly audit
jobs:
waf-audit:
runs-on: ubuntu-latest
permissions:
security-events: write # Required for SARIF upload
contents: read
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Run WAF Checker
uses: SecH0us3/waf-checker@main
with:
target-url: 'https://staging.example.com'
threshold: '95'
enhanced: 'true'
advanced: 'true'
sarif-output: 'waf-results.sarif'
html-output: 'waf-report.html'
- name: Upload SARIF to GitHub Security Tab
if: always()
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: 'waf-results.sarif'
- name: Upload HTML Report Artifact
if: always()
uses: actions/upload-artifact@v4
with:
name: waf-audit-report
path: waf-report.html
```
### 3. Versão Docker
Você pode executar a CLI usando Docker, seja baixando a imagem pré-construída do GitHub Container Registry ou construindo-a localmente.
#### Usando a Imagem Pré-construída (Recomendado)
A imagem Docker pré-construída está disponível no [GitHub Container Registry](https://github.com/SecH0us3/waf-checker/pkgs/container/waf-checker-cli) em `ghcr.io/sech0us3/waf-checker-cli`.
##### Baixar a imagem
```bash
docker pull ghcr.io/sech0us3/waf-checker-cli:latest
```
##### Exibir ajuda
```bash
docker run --rm ghcr.io/sech0us3/waf-checker-cli:latest --help
```
##### Executar uma verificação
```bash
docker run --rm -it ghcr.io/sech0us3/waf-checker-cli:latest check https://example.com
```
##### Executar auditorias em lote (montando um diretório local)
```bash
docker run --rm -it -v "$(pwd):/data" ghcr.io/sech0us3/waf-checker-cli:latest batch /data/targets.txt --concurrency 3
```
#### Compilando Localmente
##### Compilar a imagem
```bash
docker build -t waf-checker-cli .
```
##### Exibir ajuda
```bash
docker run --rm waf-checker-cli --help
```
##### Executar uma verificação
```bash
docker run --rm -it waf-checker-cli check https://example.com
```
##### Executar auditorias em lote (montando um diretório local)
```bash
docker run --rm -it -v "$(pwd):/data" waf-checker-cli batch /data/targets.txt --concurrency 3
```
## 🔌 API e Integração (para Consumidores Externos e Fuzzers)
O Cloudflare Worker expõe uma API REST pública consumida por scanners e fuzzers (incluindo o [swazz](https://github.com/SecH0us3/swazz)). A especificação completa do OpenAPI 3.1 está disponível em [`docs/openapi.yaml`](https://github.com/sech0us3/waf-checker/blob/main/docs/openapi.yaml).
### Visão Geral dos Endpoints
| Endpoint | Método | Descrição |
|---|---|---|
| `/api/waf-detect` | `GET` | Identifica o fornecedor do WAF, a pontuação de confiança e os bypasses sugeridos. |
| `/api/check` | `GET`, `POST` | Sonda o alvo com payloads de ataque. Suporta paginação e filtragem por categoria. |
| `/api/virtual-patch` | `POST` | Gera regras de remediação para Cloudflare, AWS, ModSec, NGINX, Caddy, HAProxy, Coraza. |
| `/api/reverse-engineer` | `GET`, `POST` | Faz engenharia reversa das regras do OWASP CRS, dos limites de anomalia e dos limites de corpo. |
| `/api/audit` | `GET`, `POST` | **Auditoria unificada**: executa detecção, verificações de segurança e patches virtuais, geralmente em uma única requisição (ver Paginação de Auditoria). |
### Principais Recursos de Integração
- **Envelope de Paginação (`?envelope=1` ou `?envelope=true`)**:
Envolve os resultados em um envelope estruturado com metadados de paginação:
```json
{
"results": [...],
"page": 0,
"pageSize": 50,
"total": 72,
"hasMore": true
}
```
*(Omita `?envelope=1` para receber o array JSON simples padrão por compatibilidade retroativa).*
- **Paginação de Auditoria (`/api/audit`)**:
Uma auditoria retorna tudo em uma única resposta (`hasMore: false`), a menos que seu plano exceda o que o orçamento de subrequisições de uma única requisição do Cloudflare Worker permite (1658 itens). Isso cobre nenhum WAF detectado (513 itens) e todas as variações de bypass de cada WAF até Sophos (1321); um alvo protegido por Qrator (2441 itens) retorna em duas páginas, assim como qualquer auditoria em que você passe um `pageSize` menor. As respostas carregam `page`, `pageSize`, `total`, `hasMore` e `detectedWAF` (`""` se nenhum foi encontrado). Enquanto `hasMore` for verdadeiro, solicite `page=<page + 1>&detectedWAF=<detectedWAF>`; passar `detectedWAF` de volta evita a redetecção (`detection` passa a ser `null`) e mantém os limites de página estáveis. `patches` cobre os resultados dessa resposta; para um único bundle em várias páginas, faça `POST` dos `results` combinados para `/api/virtual-patch`.
- **Confiança Normalizada (`/api/waf-detect`)**:
Fornece `confidencePercent` (0–100) junto com `confidence` bruto e `confidenceThreshold` (`40`).
- **Veredito por Resultado e Flags de Bloqueio**:
Cada `AuditResultItem` inclui:
- `blocked: boolean` — Se o WAF interveio antes de atingir a origem.
- `verdict: 'blocked' | 'passed' | 'exposed'` — Resultado distinto que diferencia entre vazamentos (`exposed`) e lacunas de cobertura (`passed`).
- `error: string | null` — Categoria de erro explícita em queda de rede (por exemplo, `'timeout'`, `'dns'`, `'connection_reset'`).
- **Recusa de Auto-Scan (HTTP 422)**:
Recusa auto-scans acidentais direcionados à infraestrutura do serviço com `{ "error": "self-scan refused", "code": "SELF_SCAN_REFUSED" }`.
---
## Testes
Para executar a suíte de testes de todo o workspace (utilizando Vitest):
```bash
npm test
```
Leia meu blog em [yoursec.substack.com](https://yoursec.substack.com/)