Lista Branca de IP para Chaves de API

Pássaro

19 de ago. de 2015

Email

1 min read

Lista Branca de IP para Chaves de API

Principais Conclusões

    • As chaves da API são credenciais poderosas — se comprometidas, atacantes podem enviar e-mail, roubar dados ou se passar pela sua marca.

    • Forçar uma chave hexadecimal de 40 caracteres é essencialmente impossível; as ameaças reais vêm da exposição (ataques MITM, repositórios de código inseguros, credenciais vazadas).

    • Sempre use HTTPS e valide certificados SSL para evitar a interceptação das suas chaves da API.

    • A lista de permissões de IP adiciona uma camada crítica de proteção, restringindo o uso de uma chave a IPs ou intervalos de IP específicos.

    • Mesmo que um atacante roube sua chave da API, ele não pode usá-la a menos que esteja se conectando a partir de um IP aprovado.

    • O suporte a CIDR facilita a autorização de redes inteiras sem listar cada servidor.

    • Evite embutir chaves da API no código — use variáveis de ambiente ou soluções seguras de gerenciamento de segredos.

    • Crie várias chaves da API de escopo estreito, em vez de uma única chave

Destaques de Perguntas e Respostas

  • O que é a lista branca de IP?

    É um recurso de segurança que restringe o uso da chave da API a endereços IP ou faixas de IP específicas.

  • Por que o SparkPost/Bird usa chaves de API para autenticação?

    As chaves da API são simples, amplamente adotadas e funcionam de forma limpa com APIs REST e SMTP.

  • O que acontece se alguém roubar minha chave de API?

    Eles poderiam enviar e-mails em seu nome, baixar listas de destinatários, modificar modelos ou enviar phishing/spam que prejudica sua marca.

  • As chaves da API podem ser decifradas por força bruta?

    Praticamente impossível. Uma string hexadecima de 40 caracteres tem ~1,46e48 combinações — forçar por tentativa levaria mais tempo do que a idade do universo.

  • Então, como os atacantes normalmente obtêm chaves de API?

    Ataques de man-in-the-middle (se o SSL não for verificado), chaves expostas em repositórios públicos do GitHub ou logs vazando chaves acidentalmente.

  • Como a autorização de endereços IP ajuda?

    Mesmo que um atacante roube sua chave, ela não funcionará a menos que eles estejam se conectando de um IP aprovado.

  • Posso adicionar redes inteiras à lista de permissões?

    Sim, através da notação CIDR — ideal para servidores com balanceamento de carga, VPNs ou faixas de escritório estáticas.

  • A lista branca se aplica tanto ao REST quanto ao SMTP?

    Sim, o IP da solicitação recebida deve corresponder à sua lista de permissões.

  • Quantos IPs ou faixas posso adicionar à lista de permissões?

    Quantos você precisar — múltiplos IPs individuais ou blocos.

  • Eu devo usar uma chave de API para tudo?

    Não. Crie chaves separadas para diferentes sistemas, equipes ou fornecedores. Isso melhora a segurança e facilita a rotação ou revogação de chaves.

  • Onde devo armazenar as chaves da API?

    Use variáveis de ambiente — nunca codifique chaves em arquivos fonte ou repositórios públicos.

  • Quais são as melhores práticas de segurança adicionais?

    Sempre ative a 2FA em sua conta SparkPost/Bird e crie chaves dedicadas para terceiros com permissões mínimas e suas próprias listas de permissões.

Existem muitas maneiras de construir autenticação em um produto com API-first como o SparkPost, e a que escolhemos cedo foi o uso de chaves de API. Injetar sua chave de API como um cabeçalho de Autorização bruto ou via Autenticação Básica HTTP padrão torna muito fácil usar nossas APIs. Chaves de API como essa são um padrão comum para webservices, mas quão seguro é esse sistema?

Existem muitas maneiras de construir autenticação em um produto com API-first como o SparkPost, e a que escolhemos cedo foi o uso de chaves de API. Injetar sua chave de API como um cabeçalho de Autorização bruto ou via Autenticação Básica HTTP padrão torna muito fácil usar nossas APIs. Chaves de API como essa são um padrão comum para webservices, mas quão seguro é esse sistema?

Existem muitas maneiras de construir autenticação em um produto com API-first como o SparkPost, e a que escolhemos cedo foi o uso de chaves de API. Injetar sua chave de API como um cabeçalho de Autorização bruto ou via Autenticação Básica HTTP padrão torna muito fácil usar nossas APIs. Chaves de API como essa são um padrão comum para webservices, mas quão seguro é esse sistema?

Os riscos

Quando se utiliza qualquer webservice, se um atacante obtiver sua chave de API, ele pode agir em seu nome e fazer coisas como (no nosso caso):

  • enviar e-mail gratuitamente através da sua conta

  • baixar sua lista de destinatários e enviá-los para spammers (caso não sejam spammers eles mesmos)

  • editar seus templates para injetar links de phishing

  • enviar spam ou phishing em seu nome

Qualquer um desses resultados pode ser muito prejudicial para sua reputação e para o seu negócio, e no caso de phishing pode causar danos diretos aos seus usuários finais.  É por isso que é extremamente importante garantir que ninguém consiga descobrir sua chave de API.

Quando se utiliza qualquer webservice, se um atacante obtiver sua chave de API, ele pode agir em seu nome e fazer coisas como (no nosso caso):

  • enviar e-mail gratuitamente através da sua conta

  • baixar sua lista de destinatários e enviá-los para spammers (caso não sejam spammers eles mesmos)

  • editar seus templates para injetar links de phishing

  • enviar spam ou phishing em seu nome

Qualquer um desses resultados pode ser muito prejudicial para sua reputação e para o seu negócio, e no caso de phishing pode causar danos diretos aos seus usuários finais.  É por isso que é extremamente importante garantir que ninguém consiga descobrir sua chave de API.

Quando se utiliza qualquer webservice, se um atacante obtiver sua chave de API, ele pode agir em seu nome e fazer coisas como (no nosso caso):

  • enviar e-mail gratuitamente através da sua conta

  • baixar sua lista de destinatários e enviá-los para spammers (caso não sejam spammers eles mesmos)

  • editar seus templates para injetar links de phishing

  • enviar spam ou phishing em seu nome

Qualquer um desses resultados pode ser muito prejudicial para sua reputação e para o seu negócio, e no caso de phishing pode causar danos diretos aos seus usuários finais.  É por isso que é extremamente importante garantir que ninguém consiga descobrir sua chave de API.

As odds

Será que eu ouvi bruteforce? Nossas chaves de API são strings hexadecimais geradas aleatoriamente com 40 caracteres. Isso resulta em um total de 1.4615e+48 chaves de API. Se todos os 3 bilhões de computadores e smartphones no mundo estivessem tentando 100 chaves de API por segundo, assumindo que nossos servidores permitissem isso, passar por todas as chaves de API possíveis levaria mais de 150.000.000.000.000.000.000.000.000.000 anos. Portanto, forçar a chave de API simplesmente não faz sentido.

Então, como alguém pode encontrar sua chave de API? Como a chave é passada como um cabeçalho, ela pode ser lida com ataques man-in-the-middle, então você deve sempre se certificar de que seu cliente está verificando os certificados SSL ao se conectar às nossas APIs (esta é uma das principais razões pelas quais exigimos https para conexões API). Além disso, se você for descuidado com o uso de repositórios de código públicos como o GitHub, sua chave de API pode facilmente acabar exposta na internet. Este não é um problema acadêmico: existem bots conhecidos rastejando o GitHub para encontrar chaves de API, e houve ataques bem-sucedidos através desse vetor.

Será que eu ouvi bruteforce? Nossas chaves de API são strings hexadecimais geradas aleatoriamente com 40 caracteres. Isso resulta em um total de 1.4615e+48 chaves de API. Se todos os 3 bilhões de computadores e smartphones no mundo estivessem tentando 100 chaves de API por segundo, assumindo que nossos servidores permitissem isso, passar por todas as chaves de API possíveis levaria mais de 150.000.000.000.000.000.000.000.000.000 anos. Portanto, forçar a chave de API simplesmente não faz sentido.

Então, como alguém pode encontrar sua chave de API? Como a chave é passada como um cabeçalho, ela pode ser lida com ataques man-in-the-middle, então você deve sempre se certificar de que seu cliente está verificando os certificados SSL ao se conectar às nossas APIs (esta é uma das principais razões pelas quais exigimos https para conexões API). Além disso, se você for descuidado com o uso de repositórios de código públicos como o GitHub, sua chave de API pode facilmente acabar exposta na internet. Este não é um problema acadêmico: existem bots conhecidos rastejando o GitHub para encontrar chaves de API, e houve ataques bem-sucedidos através desse vetor.

Será que eu ouvi bruteforce? Nossas chaves de API são strings hexadecimais geradas aleatoriamente com 40 caracteres. Isso resulta em um total de 1.4615e+48 chaves de API. Se todos os 3 bilhões de computadores e smartphones no mundo estivessem tentando 100 chaves de API por segundo, assumindo que nossos servidores permitissem isso, passar por todas as chaves de API possíveis levaria mais de 150.000.000.000.000.000.000.000.000.000 anos. Portanto, forçar a chave de API simplesmente não faz sentido.

Então, como alguém pode encontrar sua chave de API? Como a chave é passada como um cabeçalho, ela pode ser lida com ataques man-in-the-middle, então você deve sempre se certificar de que seu cliente está verificando os certificados SSL ao se conectar às nossas APIs (esta é uma das principais razões pelas quais exigimos https para conexões API). Além disso, se você for descuidado com o uso de repositórios de código públicos como o GitHub, sua chave de API pode facilmente acabar exposta na internet. Este não é um problema acadêmico: existem bots conhecidos rastejando o GitHub para encontrar chaves de API, e houve ataques bem-sucedidos através desse vetor.

A lista branca de IPs para o resgate

Quando você cria uma chave de API, agora pode especificar uma lista de IPs que estão autorizados a usar essa chave. Você pode especificar vários IPs, assim como blocos de IP, usando a notação CIDR, para que você não precise listar seus servidores individualmente. Quando a chave da API é utilizada, para APIs REST ou SMTP, nós corresponderemos o IP de conexão com essa lista para permitir ou negar acesso.

Com este recurso, mesmo que sua chave de API seja encontrada ou roubada, apenas seus servidores poderão usá-la.

Ameaças Comuns de Chaves de API e Mitigações

Ameaça

Descrição

Mitigação Recomendado

Exposição da chave em repositórios de código públicos

Chaves de API comprometidas no GitHub podem ser coletadas por bots

Mantenha chaves em variáveis de ambiente; gire chaves vazadas imediatamente

Intercepção man-in-the-middle

Chave de API lida durante conexões inseguras

Imponha sempre HTTPS e valide certificados SSL

Chave de API roubada usada a partir da infraestrutura do atacante

O atacante pode enviar e-mails, roubar dados ou modificar templates

Use a lista de permissões de IP para restringir quais IPs podem usar a chave

Chaves de API “canivete suíço” com permissões excessivas

Uma única chave concede privilégios demais se comprometida

Crie várias chaves de escopo restrito com concessões limitadas

Integrações de terceiros mal utilizando uma chave compartilhada

Parceiros externos podem acidentalmente expor ou fazer mau uso da sua chave

Gere chaves dedicadas para cada parceiro com IPs e permissões restritas

Dado os riscos e a facilidade de configurá-lo, recomendamos fortemente que todos os nossos clientes usem este recurso.

Quando você cria uma chave de API, agora pode especificar uma lista de IPs que estão autorizados a usar essa chave. Você pode especificar vários IPs, assim como blocos de IP, usando a notação CIDR, para que você não precise listar seus servidores individualmente. Quando a chave da API é utilizada, para APIs REST ou SMTP, nós corresponderemos o IP de conexão com essa lista para permitir ou negar acesso.

Com este recurso, mesmo que sua chave de API seja encontrada ou roubada, apenas seus servidores poderão usá-la.

Ameaças Comuns de Chaves de API e Mitigações

Ameaça

Descrição

Mitigação Recomendado

Exposição da chave em repositórios de código públicos

Chaves de API comprometidas no GitHub podem ser coletadas por bots

Mantenha chaves em variáveis de ambiente; gire chaves vazadas imediatamente

Intercepção man-in-the-middle

Chave de API lida durante conexões inseguras

Imponha sempre HTTPS e valide certificados SSL

Chave de API roubada usada a partir da infraestrutura do atacante

O atacante pode enviar e-mails, roubar dados ou modificar templates

Use a lista de permissões de IP para restringir quais IPs podem usar a chave

Chaves de API “canivete suíço” com permissões excessivas

Uma única chave concede privilégios demais se comprometida

Crie várias chaves de escopo restrito com concessões limitadas

Integrações de terceiros mal utilizando uma chave compartilhada

Parceiros externos podem acidentalmente expor ou fazer mau uso da sua chave

Gere chaves dedicadas para cada parceiro com IPs e permissões restritas

Dado os riscos e a facilidade de configurá-lo, recomendamos fortemente que todos os nossos clientes usem este recurso.

Quando você cria uma chave de API, agora pode especificar uma lista de IPs que estão autorizados a usar essa chave. Você pode especificar vários IPs, assim como blocos de IP, usando a notação CIDR, para que você não precise listar seus servidores individualmente. Quando a chave da API é utilizada, para APIs REST ou SMTP, nós corresponderemos o IP de conexão com essa lista para permitir ou negar acesso.

Com este recurso, mesmo que sua chave de API seja encontrada ou roubada, apenas seus servidores poderão usá-la.

Ameaças Comuns de Chaves de API e Mitigações

Ameaça

Descrição

Mitigação Recomendado

Exposição da chave em repositórios de código públicos

Chaves de API comprometidas no GitHub podem ser coletadas por bots

Mantenha chaves em variáveis de ambiente; gire chaves vazadas imediatamente

Intercepção man-in-the-middle

Chave de API lida durante conexões inseguras

Imponha sempre HTTPS e valide certificados SSL

Chave de API roubada usada a partir da infraestrutura do atacante

O atacante pode enviar e-mails, roubar dados ou modificar templates

Use a lista de permissões de IP para restringir quais IPs podem usar a chave

Chaves de API “canivete suíço” com permissões excessivas

Uma única chave concede privilégios demais se comprometida

Crie várias chaves de escopo restrito com concessões limitadas

Integrações de terceiros mal utilizando uma chave compartilhada

Parceiros externos podem acidentalmente expor ou fazer mau uso da sua chave

Gere chaves dedicadas para cada parceiro com IPs e permissões restritas

Dado os riscos e a facilidade de configurá-lo, recomendamos fortemente que todos os nossos clientes usem este recurso.

Últimas palavras

Algumas recomendações pessoais sobre segurança:

  • Não mantenha suas chaves de API no código. Há muitos benefícios em mantê-las como variáveis de ambiente, como faz o Heroku

  • Você pode criar uma quantidade ilimitada de chaves de API, e é melhor para a segurança dividir as responsabilidades entre várias chaves de API, em vez de usar apenas uma chave "ferramenta suíça". Isso também permitiria que você tivesse listas de IPs permitidos diferentes para cada chave, proporcionando uma separação de responsabilidades ainda melhor

  • Se você trabalhar com terceiros, não compartilhe sua chave de API, mas crie uma nova para eles, com apenas os privilégios necessários, e vinculada aos IPs deles

  • Como as chaves de API só podem ser criadas pela interface do usuário, habilitar a autenticação de 2 fatores na sua conta SparkPost é imprescindível e leva apenas 2 minutos

Algumas recomendações pessoais sobre segurança:

  • Não mantenha suas chaves de API no código. Há muitos benefícios em mantê-las como variáveis de ambiente, como faz o Heroku

  • Você pode criar uma quantidade ilimitada de chaves de API, e é melhor para a segurança dividir as responsabilidades entre várias chaves de API, em vez de usar apenas uma chave "ferramenta suíça". Isso também permitiria que você tivesse listas de IPs permitidos diferentes para cada chave, proporcionando uma separação de responsabilidades ainda melhor

  • Se você trabalhar com terceiros, não compartilhe sua chave de API, mas crie uma nova para eles, com apenas os privilégios necessários, e vinculada aos IPs deles

  • Como as chaves de API só podem ser criadas pela interface do usuário, habilitar a autenticação de 2 fatores na sua conta SparkPost é imprescindível e leva apenas 2 minutos

Algumas recomendações pessoais sobre segurança:

  • Não mantenha suas chaves de API no código. Há muitos benefícios em mantê-las como variáveis de ambiente, como faz o Heroku

  • Você pode criar uma quantidade ilimitada de chaves de API, e é melhor para a segurança dividir as responsabilidades entre várias chaves de API, em vez de usar apenas uma chave "ferramenta suíça". Isso também permitiria que você tivesse listas de IPs permitidos diferentes para cada chave, proporcionando uma separação de responsabilidades ainda melhor

  • Se você trabalhar com terceiros, não compartilhe sua chave de API, mas crie uma nova para eles, com apenas os privilégios necessários, e vinculada aos IPs deles

  • Como as chaves de API só podem ser criadas pela interface do usuário, habilitar a autenticação de 2 fatores na sua conta SparkPost é imprescindível e leva apenas 2 minutos

Outras notícias

Leia mais desta categoria

A person is standing at a desk while typing on a laptop.

A plataforma completa nativa de IA que escalará com o seu negócio.

© 2025 Pássaro

A person is standing at a desk while typing on a laptop.

A plataforma completa nativa de IA que escalará com o seu negócio.

© 2025 Pássaro