Pular para o conteúdo principal
Acreditamos que a privacidade é um direito, não um privilégio, e está incorporada aos alicerces da nossa empresa. Ao usar a plataforma de desenvolvedores da X e seguir nossa política para desenvolvedores, você desempenha um papel fundamental para garantir que a plataforma sirva à conversa pública na X e proteja nosso compromisso com a privacidade. Queremos reforçar a importância de desenvolver com segurança para proteger tanto seus próprios dados quanto os dados dos usuários dos seus Apps. É sua responsabilidade se proteger contra ameaças e violações de segurança, e temos uma responsabilidade compartilhada de proteger as pessoas que usam a X. Esta página descreve as expectativas sobre como criar aplicativos seguros e manter data e acesso o mais protegidos possível.
Esteja ciente das tecnologias de segurança disponíveis para a X Developer Platform, incluindo authentication, TLS e app permissions, bem como, da perspectiva do usuário da X, para usar aplicativos e sessões de terceiros.

Comunicação de problemas de segurança

Os usuários da X Developer Platform devem notificar a X em até 48 horas após a suspeita inicial de ocorrência de um incidente de segurança, por meio do programa de relato de vulnerabilidades da X.

Melhores práticas de segurança

Tenha-as em mente ao desenvolver na plataforma de desenvolvedores da X e em outros locais na internet.

Segurança desde a concepção

Considere contratar profissionais de segurança para realizar uma análise de modelagem de ameaças e/ou testes de invasão. Uma boa empresa de segurança investigará a fundo para identificar problemas. Leia mais sobre como a X adotou essa mentalidade nesta postagem do nosso blog. Além disso, a X responsabiliza todos os parceiros pelo seguinte:
  • Manter o código em um repositório seguro.
  • Realizar análise de riscos ao longo do ciclo de vida de desenvolvimento de sistemas (SDLC).
  • Garantir que problemas de segurança sejam identificados e mitigados ao longo do SDLC.
  • Garantir a segregação de ambientes ao longo do SDLC.
  • Garantir que todos os defeitos encontrados em testes sejam corrigidos, retestados e encerrados.

Monitore e receba alertas

Se você suspeita de um problema na sua aplicação web, como confirmar? Mantenha logs de qualidade e garanta que seja notificado sobre exceções e erros críticos. Você também pode montar um painel com estatísticas essenciais para identificar rapidamente se algo está saindo do esperado.

Crie um canal de reporte

Facilite que seus usuários entrem em contato para reportar possíveis problemas de segurança que tenham ocorrido com sua App. Se for descoberto um problema que afete usuários e dados da X, também é sua responsabilidade reportar esse problema à X. Tenha um plano/processo de ação pronto para notificar os usuários afetados, caso ocorra um incidente de segurança.

Testes adequados

Garanta que seus testes de ponta a ponta sejam abrangentes e atualizados para incluir falhas esperadas em cenários de segurança, como acesso não autorizado. Adote a perspectiva de um invasor e configure testes de sistema que devem impedir que um atacante obtenha acesso não autorizado a dados da X ou a funcionalidades autorizadas.

Protegendo chaves e tokens de API

Como desenvolvedor na plataforma X, você tem acesso programático tanto aos seus dados quanto aos dados dos seus usuários armazenados pela X, desde que eles tenham autorizado sua App de desenvolvedor. Todas as solicitações à API devem ser autenticadas usando OAuth com a chave e o segredo da sua App de desenvolvedor e, em alguns casos, com os access tokens do usuário que autorizou. É sua responsabilidade manter suas credenciais seguras. Algumas práticas recomendadas incluem:
  • Implementar uma rotação de atualização de senhas/tokens.
  • Sempre criptografar dados confidenciais conforme necessário e evitar descriptografá-los cedo demais no pipeline.
  • Armazenar os access tokens dos seus usuários em um repositório criptografado.
  • Regenerar ou invalidar chaves e tokens se você acreditar que foram comprometidos.
Para mais discussões sobre depuração e desenvolvimento com OAuth para a X, visite a categoria de segurança do fórum da comunidade.

Validação de entrada

Não presuma que seus usuários fornecerão dados válidos e confiáveis. Faça a sanitização de todos os dados enviados pelos seus usuários que possam ser usados em solicitações para a X API. Defina uma allowlist com os tipos de entrada aceitáveis para sua aplicação e descarte tudo o que não estiver nessa allowlist.

Comunicação criptografada

A X exige que todas as solicitações à API sejam feitas por meio de TLS. A comunicação com seus próprios servidores também deve ser criptografada sempre que possível.

Informações de depuração expostas

Certifique-se de não expor dados sensíveis da X ou credenciais por meio de telas/logs de depuração. Alguns frameworks web permitem acessar facilmente informações de depuração se seu aplicativo não estiver configurado corretamente. Para desenvolvedores de desktop e dispositivos móveis, é fácil, por engano, distribuir uma compilação com flags ou símbolos de depuração habilitados. Inclua verificações de compilação para essas configurações no seu processo de implantação/compilação. Além disso, ao compartilhar stack traces ou crash dumps para fins de relatório, garanta que os dados privados de usuários da X sejam redigidos.

Entrada sem filtro, saída sem escape

Uma forma fácil de lembrar a validação de entrada é FIEO: Filtrar a Entrada, Escapar a Saída. Filtre tudo o que vier de fora da sua aplicação, incluindo dados da X API, dados de cookies, entradas de formulários fornecidas por usuários, parâmetros de URL, dados de bancos de dados etc. Escape toda a saída gerada pela sua aplicação, incluindo SQL enviado ao servidor de banco de dados, HTML enviado aos navegadores dos usuários, saída JSON enviada a outros sistemas e comandos enviados a shells.

Cross-site scripting (XSS)

Ataques de XSS são, por praticamente todas as métricas, a forma mais comum de problema de segurança na web. Se um invasor conseguir injetar seu próprio código JavaScript na sua aplicação, ele poderá causar danos. Qualquer ponto em que você armazene e exiba dados não confiáveis fornecidos por usuários precisa ser verificado, higienizado e ter HTML escapado. Fazer isso corretamente é difícil, porque agentes mal-intencionados têm muitas maneiras de executar ataques de XSS. Sua linguagem ou framework de desenvolvimento web provavelmente oferece um mecanismo popular e bem testado para se defender de cross-site scripting; utilize-o.

Injeção de SQL

Se sua aplicação utiliza um banco de dados, você precisa estar ciente da injeção de SQL. Qualquer ponto em que você aceita entrada do usuário é um alvo potencial para que um invasor consiga sair do campo de entrada e acessar seu banco de dados. Use bibliotecas de banco de dados que protejam contra injeção de SQL de forma sistemática. Se você fugir dessa abordagem e escrever SQL manualmente, crie testes rigorosos para garantir que não está se expondo a esse tipo de ataque. As duas principais abordagens para se defender contra injeção de SQL são aplicar escape antes de construir a instrução SQL e usar parâmetros (entrada parametrizada) para criar instruções. A segunda é recomendada, pois é menos propensa a erro do programador.

Falsificação de solicitação entre sites (CSRF)

Você tem certeza de que as solicitações para sua aplicação estão vindo de sua própria aplicação? Ataques de CSRF exploram essa incerteza ao forçar usuários autenticados do seu site a abrirem, sem perceber, URLs que executam ações. No caso de uma App de desenvolvedor, isso pode significar que invasores estão usando sua App para forçar usuários a publicar Tweets indesejados ou seguir contas de spam. A maneira mais completa de lidar com CSRF é incluir um token aleatório em cada formulário e armazená‑lo em um local confiável; se um formulário não tiver o token correto, lance um erro. Frameworks web modernos têm maneiras sistemáticas de tratar isso e podem até fazer isso por padrão, se você tiver sorte. Uma medida preventiva simples (embora não seja a única que você deve adotar) é exigir que quaisquer ações que criem, modifiquem ou excluam dados utilizem uma solicitação POST.

Ausência de limite de taxa

Use CAPTCHAs, quando apropriado, para desacelerar possíveis spammers e invasores.
Se você descobriu um problema de segurança que afeta diretamente o X, temos um programa de recompensas por vulnerabilidades.
I