O que é uma API REST?
Uma API REST é uma API que segue restrições arquiteturais específicas associadas a aplicações baseadas na web, incluindo comunicação sem estado (stateless) e dados armazenáveis em cache. APIs REST permitem que aplicações de navegador, apps móveis e outros clientes de API se comuniquem com um servidor. A seguir, apresentamos as 10 principais diretrizes de segurança para APIs REST, baseadas em experiências de clientes e problemas destacados no mais recente relatório State of API Security da Salt Security. Conforme o tempo e os recursos permitirem, considere adotar o conjunto completo de práticas recomendadas de segurança para APIs descrito no guia de Práticas Recomendadas de Segurança para APIs da Salt. Você também pode utilizar o checklist de segurança para APIs correspondente para acompanhar o trabalho relacionado.
Diferente de outros tipos de API, REST é um estilo, e não um padrão rígido. APIs REST podem ser projetadas de várias maneiras, o que impacta como a funcionalidade é invocada ou como os dados são transmitidos em uma requisição. O esquema da API REST resultante e a estrutura da URL do endpoint podem variar muito de uma organização para outra. APIs REST são implementadas, operadas ou utilizadas por diversos papéis dentro de uma organização, incluindo desenvolvimento, equipes de produto, operações, segurança de aplicações e operações de segurança. APIs REST são um dos tipos mais comuns de serviços web em uso atualmente. É imperativo projetar APIs REST corretamente, levando em conta a segurança, o desempenho e a facilidade de uso para os consumidores da API.
As 10 Principais Diretrizes de Segurança para APIs REST
1. Ao gerar documentação de API REST, opte por formatos legíveis por máquina e definições de esquema em vez de documentação tradicional ou diagramas visuais.
Para APIs REST, esses formatos legíveis por máquina geralmente incluem Swagger ou OAS. Dependendo do design da sua API REST e das ferramentas de desenvolvimento ou publicação, outros formatos como RAML ou REST API Blueprint podem estar presentes. A documentação tradicional pode ser útil para revisões por um público menos técnico, mas essas formas de documentação não são facilmente mantidas. Os formatos de definição de esquema de API REST são projetados para a geração rápida de documentação como parte do design e simulação (mocking) da API, sendo também reutilizáveis para testes, integração, publicação e operações.
2. Descubra APIs REST em ambientes que não sejam de produção, não apenas em ambientes de produção.
É fundamental que você monitore ambientes inferiores, incluindo QA, UAT, staging, SIT e pré-produção, além dos seus ambientes de produção. Os atacantes sabem que ambientes que não são de produção geralmente possuem controles de segurança mais relaxados ou inexistentes, embora as APIs REST nesses ambientes ainda possam permitir acesso a conjuntos semelhantes de funcionalidades e dados. As organizações frequentemente configuram ambientes inferiores com endurecimento (hardening) mínimo para promover o desenvolvimento e a integração rápidos, visando metas de produção e cronogramas de lançamento. Ambientes inferiores também podem estar expostos à Internet, o que eleva ainda mais o risco de segurança.
3. Inclua as dependências das suas APIs REST.
Vá além das APIs REST desenvolvidas internamente e inclua também APIs REST de softwares de código aberto, pacotes de aplicações adquiridos e serviços SaaS de terceiros. As preocupações com a segurança de APIs REST não começam e terminam apenas com as APIs que você construiu. Atestados de risco de fornecedores e cláusulas contratuais são úteis principalmente como medidas reativas que oferecem recurso legal, mas oferecem garantia mínima na camada tecnológica. As organizações são inerentemente limitadas pelas opções de configuração que estão sob seu controle em serviços de terceiros. No entanto, essa limitação não isenta a organização do risco de segurança. Lacunas significativas frequentemente existem entre o design percebido de uma aplicação e suas APIs REST em comparação com o sistema entregue e integrado. A combinação de APIs construídas, integradas e adquiridas define a cadeia de suprimentos digital na qual todas as organizações operam. Da mesma forma, você também deve considerar outros tipos de API, como gRPC, GraphQL e SOAP.
4. Analise o código da API REST automaticamente sempre que possível.
Analise o código automaticamente com ferramentas de análise estática, como verificadores de qualidade de código e testes estáticos de segurança de aplicações (SAST), no momento do commit do código em sistemas de controle de versão como git e/ou em pipelines de build de CI/CD. Se você estiver revisando o código manualmente, o processo rapidamente encontrará um gargalo devido à taxa de mudança que a maioria das organizações observa em seu código e APIs REST. Digitalize a base de código integrada como parte do build no CI/CD para obter a verificação mais precisa, mas algumas organizações também optam por verificar partes do código à medida que são enviadas para o controle de versão para maior agilidade. Um verificador de qualidade de código é a ferramenta menos especializada, mas costuma ser abundante nas organizações, já que muitas ferramentas de design e desenvolvimento incluem recursos nativos de verificação de qualidade. O SAST pode ser entregue por meio de linters específicos de linguagem ou de uma solução de verificação de nível comercial. Independentemente da ferramenta escolhida, prepare-se para um grande número de descobertas de possíveis fraquezas e falsos positivos, especialmente se uma base de código nunca tiver sido verificada. Analisadores estáticos notoriamente precisam de ajustes para serem usados de forma eficaz. Por design, a análise estática não será capaz de cobrir falhas de lógica de negócios, o que requer análise de comportamento em tempo de execução.
5. Utilize mediação em APIs REST para aplicar o controle de acesso.
Gateways de API são frequentemente implementados para fornecer visibilidade e controle sobre chamadas de API REST para troca de dados ou funcionalidades. Gateways de API são mecanismos de mediação fundamentais que oferecem gerenciamento de tráfego, autenticação e autorização. As funções de gerenciamento de tráfego correspondem a controles de segurança de rede bem conhecidos, como limites de taxa ou listas de permissão e bloqueio de endereços IP. Gateways de API também são o local ideal para aplicar autenticação e autorização para APIs REST, como OpenID Connect (OIDC) e OAuth2, respectivamente. Normalmente, gateways de API são combinados com sistemas externos de gerenciamento de identidade e acesso (IAM) para compartilhar a carga de armazenar todos os tipos de identidades de usuários ou máquinas, autenticar identidades, autorizar identidades e manter trilhas de auditoria de todas as atividades. O consumo de suas APIs REST por máquinas (como em casos de uso de automação ou integração com parceiros) pode ser tão dominante quanto o consumo tradicional por usuários finais por meio de aplicativos baseados em navegador e aplicativos móveis.
6. Use transporte criptografado para proteger os dados que suas APIs REST transmitem.
O TLS deve ser habilitado para quaisquer endpoints de API REST para proteger os dados em trânsito. Busque o TLS 1.2 no mínimo e, idealmente, habilite o TLS 1.3 se outros elementos arquiteturais o suportarem. Todas as versões do SSL devem ser desabilitadas devido ao número de vulnerabilidades no protocolo ou conjuntos de cifras relacionados. Componentes de infraestrutura legados às vezes permanecem dentro de organizações ou fornecedores, exigindo que o SSL ou versões mais antigas do TLS sejam mantidos. Algumas ferramentas de inspeção de tráfego também podem não suportar protocolos de criptografia mais recentes, o que coloca as organizações em uma situação difícil quando desejam manter a visibilidade sobre o tráfego de sua rede. Infelizmente, suportar protocolos e conjuntos de cifras mais antigos expõe a organização a uma série de ataques criptográficos e de downgrade que podem resultar na visualização de dados criptografados por partes não autorizadas. Aplique políticas de criptografia por meio de suas camadas de mediação de API REST sempre que possível e garanta que protocolos e conjuntos de cifras legados permaneçam desabilitados. Se necessário, refatore ou reestruture a infraestrutura de suporte de suas APIs REST, optando por pontos de terminação TLS que permitam manter a visibilidade do tráfego enquanto mitigam o risco de segurança de ataques a protocolos de criptografia.
7. Evite enviar dados em excesso para clientes de API REST.
Clientes de API REST ou código front-end geralmente assumem a forma de JavaScript executado em um navegador da web ou binários de aplicativos em um dispositivo móvel. APIs REST de back-end às vezes são projetadas para fornecer uma grande quantidade de dados em respostas a chamadas de API REST de clientes de API, e torna-se dever do código do cliente front-end filtrar o que deve ser visível com base nos objetivos da experiência do usuário (UX) ou níveis de permissão. Esse padrão de design vai contra as melhores práticas de segurança de API REST, uma vez que esses dados ficam totalmente visíveis ao observar as solicitações e respostas da API REST. Os invasores geralmente fazem engenharia reversa do código front-end e interceptam o tráfego da API REST diretamente para ver quais dados estão sendo realmente transmitidos. O problema é classificado como um dos 10 principais riscos de segurança de API REST da OWASP como API3:2019 Exposição Excessiva de Dados, por ser tão comum. Não envie dados em excesso, especialmente dados confidenciais ou privados, para clientes front-end e sempre presuma que eles estão comprometidos. Filtre os dados adequadamente no back-end e envie apenas os dados necessários para aquele consumidor de API REST específico.
8. Autentique e autorize continuamente os consumidores de API REST.
O controle de acesso sempre envolveu autenticação e autorização. A autenticação (AuthN) envolve identificar o solicitante de uma determinada função ou recurso e desafiar essa entidade a fornecer material de autenticação ou credenciais. A autorização (AuthZ) envolve verificar se essa entidade autenticada realmente tem permissões para exercer uma função ou ler, gravar, atualizar ou excluir dados. Tradicionalmente, ambos eram tratados no início de uma sessão. No mundo da web e, por extensão, nas APIs REST, as sessões são sem estado (stateless). Os ambientes operacionais de back-ends e front-ends não são garantidos e geralmente são efêmeros. Cada vez mais, os ambientes também estão propensos a problemas de integridade ou comprometimento, daí o surgimento de arquiteturas de confiança zero (zero trust). Como resultado, você deve verificar continuamente se uma identidade de usuário ou máquina deve ter acesso a um determinado recurso e sempre presumir que a sessão autenticada pode estar comprometida. Essa abordagem requer a análise de comportamentos de uma determinada sessão para um consumidor de API REST e, potencialmente, o encerramento dessa sessão, exigindo autenticação de etapa adicional ou bloqueando o acesso conforme apropriado.
9. Explore a análise de comportamento e a detecção de anomalias.
À medida que as organizações adotam APIs REST, elas rapidamente percebem a necessidade de análise de dados e comportamento orientada por máquina para entender o consumo normal de API REST e identificar invasores que abusam das APIs REST. Os algoritmos devem ser informados por metadados de API REST, bem como pela coleta de tráfego de API REST, aprender continuamente e tomar decisões dinamicamente com base na lógica de negócios exclusiva da organização. A detecção e proteção orientadas por máquina também devem ser incorporadas a uma plataforma maior de serviços e integração, para que uma ação de mitigação apropriada, como definir um limite de taxa dinâmico para um solicitante abusivo, possa ser implementada temporariamente na entrada de rede apropriada da arquitetura geral. Mesmo organizações maduras com recursos de desenvolvimento e ciência de dados rapidamente encontram barreiras ao tentar desenvolver tal detecção e integração. Você inevitavelmente precisará explorar ferramentas de segurança de API REST para preencher essa lacuna.
10. Crie manuais de resposta a incidentes centrados em API para APIs REST.
Certifique-se de documentar os processos de perícia digital e resposta a incidentes (DFIR) sobre como responder aos padrões de ataque de API REST inevitáveis. Se você já amadureceu sua estratégia de SecOps para incluir o uso de orquestração, automação e resposta de segurança (SOAR), automatize também alguns dos itens de fluxo de trabalho como parte da resposta a incidentes. Desligar uma API REST que é alvo de atividade maliciosa raramente é uma decisão de negócios prudente, sem mencionar que reduz sua capacidade de obter inteligência adicional sobre um invasor e suas técnicas. Em vez de bloquear o tráfego totalmente, você provavelmente desejará empregar mais precisão, como limitar apenas o chamador suspeito da API REST, desafiá-lo com fatores de autenticação adicionais ou monitorar seu comportamento mais intensamente. Crie manuais de resposta a incidentes para padrões comuns de ataque de API REST, incluindo DoS na camada de aplicação, força bruta, preenchimento de credenciais (credential stuffing), enumeração e scraping.
Resumo das Melhores Práticas de Segurança de API REST
Este conjunto de melhores práticas de segurança de API é adaptado especificamente para tipos de API REST e para os conjuntos mais comuns de problemas de segurança que as organizações enfrentam. Comece escolhendo algumas áreas de melhores práticas com as quais você está mais familiarizado como ponto de partida. Expanda sua estratégia de segurança de API ao longo do tempo para cobrir todas as melhores práticas e evitar lacunas na postura de segurança de API da sua organização. Considere adotar o conjunto completo de melhores práticas de segurança de API descrito no guia de Melhores Práticas de Segurança de API da Salt como parte de uma abordagem abrangente para cobrir todos os tipos de APIs. Você também pode usar a lista de verificação correspondente para acompanhar o trabalho associado.
Se você estiver interessado em ver a Plataforma de Proteção de API da Salt Security em ação, entre em contato conosco para uma demonstração personalizada hoje!