English | 中文版 | Français | 한국어 | Nederlands | Indonesia | ไทย | Русский | Українська
Lista das mais importantes medidas de segurança para o desenvolvimento, teste e publicação da sua API.
- Não use
Basic Auth
. Use padrões de autenticação (exemplo: JWT, OAuth). - Não reinvente a roda nos quesitos
Autenticação
,geração de tokens
earmazenamento de senhas
. Use os padrões recomendados para cada caso. - Use
Max Retry
e os recursos de jail no Login. - Use criptografia em todos os dados confidenciais.
- Use uma chave de segurança aleatória e complicada (
JWT Secret
) para tornar ataques de força bruta menos eficientes. - Não utilize o algoritmo de criptografia informado no cabeçalho do payload. Force o uso de um algoritmo específico no back-end (
HS256
ouRS256
). - Defina o tempo de vida do token (
TTL
,RTTL
) o menor possível. - Não armazene informações sensíveis no JWT, pois elas podem ser facilmente decodificadas.
- Sempre valide o
redirect_uri
no seu servidor através de uma lista de URLs conhecidas (previamente cadastradas). - Tente sempre retornar códigos de negociação, não o token de acesso (não permita
response_type=token
). - Utilze o parâmetro
state
com um hash aleatório para previnir CSRF no processo de autenticação OAuth. - Defina escopo de dados, e valide o parâmetro
scope
para cada aplicação.
- Limite a quantidade de requisições (Throttling) para evitar ataques DDoS e de força bruta.
- Use HTTPS no seu servidor para evitar ataques MITM (Man In The Middle Attack).
- Use cabeçalho
HSTS
com SSL para evitar ataques SSL Strip.
- Utilize o método HTTP apropriado para cada operação,
GET (obter)
,POST (criar)
,PUT (trocar/atualizar)
eDELETE (apagar)
. - Valide o tipo de conteúdo informado no cabeçalho
Accept
da requisição (Content Negotiation) para permitir apenas os formatos suportados pela sua API (ex.application/xml
,application/json
... etc), respondendo com o status406 Not Acceptable
se ele não for suportado. - Valide o tipo de conteúdo do conteúdo da requisição informado no cabeçalho
Content-Type
da requisição para permitir apenas os formatos suportados pela sua API (ex.application/x-www-form-urlencoded
,multipart/form-data, application/json
... etc). - Valide o conteúdo da requisição para evitar as vulnerabilidades mais comuns (ex.
XSS
,SQL-Injection
,Remote Code Execution
... etc). - Não utilize nenhuma informação sensível (credenciais, senhas, tokens de autenticação) na URL. Use o cabeçalho
Authorization
da requisição. - Use um serviço gateway de API para habilitar o armazenamento em cache, limite de taxa, prender de spike e implanta os recursos da API dinamicamente.
- Verifique continuamente os endpoints protegidos por autenticação para evitar falhas na proteção de acesso aos dados.
- Não utilize a identificação do próprio usuário. Use
/me/orders
no lugar de/user/654321/orders
. - Não utilize ID's incrementais. Use UUID.
- Se você estiver processando arquivos XML, verifique que entity parsing não está ativada para evitar ataques de XML externo (XXE - XML external entity attack).
- Se você estiver processando arquivos XML, verifique que entity expansion não está ativada para evitar Billion Laughs/XML bomb através de ataques exponenciais de expansão de XML.
- Use CDN para uploads de arquivos.
- Se você estiver trabalhando com uma grande quantidade de dados, use workers e queues (fila de processos) para retornar uma resposta rapidamente e evitar o bloqueio de requisições HTTP.
- Não se esqueça de desativar o modo de depuração (DEBUG mode OFF).
- Envie o cabeçalho
X-Content-Type-Options: nosniff
. - Envie o cabeçalho
X-Frame-Options: deny
. - Envie o cabeçalho
Content-Security-Policy: default-src 'none'
. - Remova os cabeçalhos de identificação dos softwares do servidor -
X-Powered-By
,Server
,X-AspNet-Version
. - Envie um cabeçalho
Content-Type
na sua resposta com o valor apropriado (ex. se você retorna um JSON, então envie umContent-Type: application/json
). - Não retorne dados sensíveis como senhas, credenciais e tokens de autenticação.
- Utilize o código de resposta apropriado para cada operação. Ex.
200 OK
(respondido com sucesso),201 Created
(novo recurso criado),400 Bad Request
(requisição inválida),401 Unauthorized
(não autenticado),405 Method Not Allowed
(método HTTP não permitido) ... etc.
- Auditoria de seu projeto e implementação com cobertura de testes de unidade/integração.
- Use um processo de revisão de código e ignore a auto-aprovação.
- Certifique-se de que todos os componentes de seus serviços sejam escaneados estaticamente pelo software AV antes de empurrar para a produção, incluindo bibliotecas de fornecedores e outras dependências.
- Desenhar uma solução de reversão para implantações.
Sinta-se livre para contribuir, fazendo um fork deste repositório, fazendo algumas alterações e enviando um PR. Dúvidas, envie um e-mail para [email protected]
.