Lista do casamento
Na festa fechada, só entra quem está na lista. Tentar listar “todas as pessoas indesejadas do mundo” (blocklist) é absurdo: a lista cresce e o próximo desconhecido passa. Allowlist é curta e explícita.
Negar o resto
O erro clássico é Access-Control-Allow-Origin: * ou ecoar o Origin do request.
Allowlist de IP falha atrás de NAT corporativo e com clientes móveis — escolha a dimensão certa (origem web ≠ IP).
Rate limiting corta por volume; allowlist corta por identidade de origem. Os dois se complementam no login e na borda.
Em SSRF, allowlist de hosts/esquemas que o servidor pode buscar é tão crítica quanto auth na API pública.
Como isso aparece na prática
CORS do SPA
Cenário
API aceitava qualquer Origin e o cookie de sessão vazava para um site malicioso via XHR.
Como o padrão entra
Allowlist das origens do produto; credenciais só nessas.
Trade-off: Preview deploys (URL dinâmica) precisam de padrão controlado ou auth sem cookie cross-site.
Webhook do parceiro
Cenário
Qualquer um podia POST no endpoint de webhook se descobrisse a URL.
Como o padrão entra
Allowlist de IPs do parceiro + assinatura HMAC (defesa em profundidade).
Trade-off: Parceiro mudou de IP sem avisar — monitoramento e canal de atualização da lista.
Onde isto dá errado
Refletir Origin
Allow-Origin: <o que veio no request>é allowlist falsa. Compare com um Set fixo.Prefixo aberto em redirect
https://exemplo.compermitindohttps://exemplo.com.evil.com— compare string exata ou parse de URL rigoroso.Achar que allowlist = auth
IP na lista não prova o usuário. Continua precisando de autenticação e autorização.
Origens e redirects fechados
// Allowlist: so o que esta na lista passa. Blocklist: tudo passa,
// exceto o que esta na lista — e a lista nunca esta completa.
const ORIGENS_OK = new Set([
"https://app.exemplo.com",
"https://admin.exemplo.com",
]);
function corsAllowlist(origin: string | undefined): string | null {
if (origin && ORIGENS_OK.has(origin)) return origin;
return null; // nao refletir Origin arbitrario
}
// IP allowlist na borda (admin, webhooks de parceiro conhecido).
const IPS_ADMIN = new Set(["203.0.113.10", "198.51.100.7"]);
function soIpsConhecidos(ip: string): boolean {
return IPS_ADMIN.has(ip);
}
// Redirect URI no OAuth: allowlist EXATA — nunca prefixo aberto.
function redirectPermitido(uri: string, cadastrados: string[]) {
return cadastrados.includes(uri);
}Quando usar × quando evitar
Use quando
2- CORS, OAuth redirect, admin por rede, SSRF egress.
- Webhooks com origem de rede conhecida.
Evite quando
2- API pública global como único controle.
- Blocklist como estratégia principal.
Testar o que ficou
3 armadilhas de Allowlist viram perguntas, com o nome do padrão escondido, misturadas com padrões parecidos.
Onde isto aparece de verdade
Você já usa isto, talvez sem saber o nome.
CORS Access-Control-Allow-OriginSó origens cadastradas — refletir qualquer Origin é open redirect de CORS.redirect_uri do OAuthO IdP só devolve o code para URIs exatamente registradas no client.IP allowlist de admin / VPCPainéis e bancos só aceitam tráfego de redes conhecidas.
O padrão em uma linha
Sem nome de domínio, sem cerimônia. Só a ideia.
// Default deny: só o que está na lista.
if (!ORIGENS_OK.has(origin)) return res.status(403).end();O que ele cobra
Nenhum salto a mais entre a chamada e o efeito.
- Manter a lista atualizada (novos frontends, VPNs, parceiros)
- NAT e IPs dinâmicos quebram allowlist de IP cedo demais
Não vale se: o público é a internet inteira autenticada — allowlist de IP não escala; use auth e rate limit.
Costuma ser confundido com
Onde isto aparece
Continue por aqui
- Rate limitingCapacidade é finita, e demanda não pede licença. Limitar a taxa é escolher conscientemente quem é recusado quando a demanda passa do que se aguenta — em vez de deixar a sobrecarga escolher, degradando o serviço para todo mundo ao mesmo tempo.
- OAuth 2.0OAuth 2.0 é delegação de acesso: um cliente obtém autorização para agir em nome do usuário sem ver a senha dele. O fluxo moderno é Authorization Code com PKCE; o implícito morreu. OIDC acrescenta identidade (id_token) em cima. Inventar “OAuth caseiro” com senha no body de um SPA costuma ser pior que sessão clássica bem feita.
- API GatewayNum sistema de muitos serviços, um ponto único de entrada por onde tudo passa: o API Gateway roteia cada requisição ao serviço certo e concentra o que é transversal — autenticação, rate limiting, CORS, log — para os serviços não repetirem isso cada um. O cliente conhece só o gateway, e a topologia interna pode mudar por trás. O risco é o gateway virar gargalo, ponto único de falha, ou um monólito de fronteira inchado de regra.
- AutenticaçãoAutenticação responde *quem você é*: prova de identidade antes de qualquer permissão. Na web, o desenho padrão é sessão no servidor com cookie httpOnly, Secure e SameSite — o token opaco mora fora do alcance do JavaScript da página. Confundir autenticação com autorização, ou guardar a prova de identidade no localStorage, é o caminho mais curto para vazamento e abuso.