Protegendo APIs da Esquerda para a Direita (e em td no meio do caminho) [Tradução +/- Comentada]

Em 8 de Fevereiro, recebi em uma newsletter (das muitas que assino) o blogpost Securing APIs From Left to Right (and Everywhere in Between). Como entusiasta da segurança de APIs, resolvi dar uma chance chance e passar o olho no artigo. Apesar de estar cético a princípio, o conteúdo era tão bom que até twittei sobre.

Depois de ler todo o artigo com calma, e ver outros feedbacks também, pensei que seria uma pena um material tão bom não alcançar DEVs brazucas pela barreira linguística. Por isso, resolvi escrever uma +/- tradução do artigo original, que estou chamando aqui de Tradução +/- Comentada. Vou deixar meus comentários entre /* ... */. Mantive termos em inglês onde achei que fazia sentido e fiz algumas mudanças onde achei que fazia sentido (disclaimer: a chance de erros de tradução no texto não é zero 🤷‍♂️). Então, segue o texto ⬇️

Texto traduzido

Grandes vazamentos de dados estão em ascensão e APIs estão cada vez mais sendo usadas nesse processo. As razões para isso são basicamente duas:

1. APIs são a primeira linha de frente para acessar uma aplicação (e seus dados);
2. cada vez mais aplicações são acessíveis através da cloud e APIs.

Desde funcionalidades não críticas, como streaming de música e redes sociais, até dados extremamente críticos, como contas bancárias e de saúde, estão acessíveis 24 horas por dia, 7 dias por semana, por meio de APIs.

Por que hackear APIs é tão atraente? Entre outras coisas, permite:

• Vazar dados pessoais de usuários
• Roubar ativos, realizar extorsões, etc
• Causar instabilidade e indisponiblidade

De tempos em tempos, a Open Worldwide Application Security Project (OWASP) apresenta seu Top 10 com os principais riscos de segurança a APIs e aplicações Web no geral. Daremos uma olhada rápida na lista atual, com exemplos de violações de dados causadas por cada tipo de risco.

OWASP Top 10 API Security Risks (2023)

API1:2023 – Broken Object Level Authorization (BOLA)

Em um ataque BOLA, IDs de objetos de dados da aplicação vazam em respostas de API e são usados para obter acesso não autorizado a dados confidenciais /* eu, particularmente, acho que essa descrição pode levar a mal entendidos. Os IDs não vazam, eles foram planejados para serem usados pelo cliente. O problema real é a aplicação não validar se aquele usuário tem permissão pra realizar requisições com aquele ID */.

O maior vazamento na API do Twitter foi causada por um ataque BOLA, onde uma API que poderia ser usada para localizar usuários acabou vazando PII (Personally Identifiable Information).

API2:2023 – Broken Authentication

Em broken authentication, um invasor compromete métodos de autenticação fracos e obtém acesso não autorizado a uma aplicação (e aos dados dela). Muitos vazamentos de segurança são causadas por falhas na autenticação. /* sim, eu também acho esse item bem vago 🤣*/.

API3:2023 – Broken Object Property Level Authorization

Esse item é semelhante ao BOLA, onde um atacante consegue obter acesso não autorizado aos dados. /* acho que valeria falar mais sobre o item 🤷‍♂️ */.

API4:2023 – Unrestricted Resource Consumption

Nesse cenário, o atacante consegue explorar o acesso irrestrito a uma aplicação e seus recursos. Esse tipo de ataque pode causar instabilidade nas aplicações e até mesmo indisponibilidade. Se grandes quantidades de recursos forem consumidas sem restrições, o resultado pode ser muito caro (por exemplo, recursos de nuvem pagos: CPU, memória, etc).

Um exemplo disso seria um ataque de negação de serviço (ou DoS), em que uma aplicação fica tão sobrecarregada com tráfego que não consegue mais funcionar normalmente.

API5:2023 – Broken Function Level Authorization (BFLA)

Com o BFLA, é permitido o acesso não autorizado às funcionalidades do aplicativo. Isto inclui problemas de autorização entre microsserviços.

Uma seguradora foi vítima de um ataque BFLA devido aos dados dos clientes estarem disponíveis ao público através de uma “parte protegida” do aplicativo.

/* um outro exemplo desse cara é um usuário comum ser capaz de usar uma API de admin */

API6:2023 – Unrestricted Access to Sensitive Business Flows

Esta ameaça envolve vulnerabilidades usadas para explorar de forma automatizada transações de aplicações, como vendas de ingressos ou comentários em tópicos. Por exemplo, “bots” podem ser usados para sobrecarregar um aplicativo e contornar a segurança.

Isso aconteceu com a confusão de ingressos para o show de Taylor Swift em novembro de 2022. Scalper Bots (/* bots usados pra fazer compras, reservas, etc */) foram usados para comprar ingressos de lançamento limitado para fãs verificados, que foram então vendidos com um lucro enorme.

API7:2023 – Server Side Request Forgery (SSRF)

Também conhecido como “URL spoofing”, envolve um servidor usando uma URL como input para um recurso remoto sem validar a URL fornecida, o que pode permitir que atacantes contornem uma VPN ou firewall e potencialmente obtenham acesso a dados confidenciais. O atacante usa o servidor para fazer a requisição parecer legítima.

A grande violação de dados da Capital One em 2019 foi um ataque SSRF e resultou no roubo de PII para 100 milhões de titulares de cartão de crédito. Mais recentemente, uma ação coletiva foi movida.

API8:2023 – Security Misconfiguration

Qualquer configuração de segurança fraca ou mal feita em uma aplicação aumenta a superfície de ataque.

Em maio de 2023, a Toyota revelou uma violação de big data devido a configurações de nuvem insuficientes.
/* O ápice do genérico, mas a descrição desse item sempre é assim msmo kkk */

API9:2023 – Improper Inventory Management

O gerenciamento inadequado de inventário de API inclui:

1. APIs não documentadas (shadow API);
2. APIs deprecadas (zumbis)
3. APIs não aprovadas pela empresa (rogue) */ confesso que não conhecia esse termo */.

Shadows e Zombie APIs são riscos porque podem não ter uma validação de segurança apropriada/suficiente. Uma rogue API pode significar a mesma coisa que uma shadow API, mas também pode ser o resultado da injeção de código malicioso abrindo um backdoor em um aplicativo.

API10:2023 – Unsafe Consumption of APIs

Uma segurança fraca em APIs de terceiros usadas por uma aplicação pode resultar no acesso malicioso aos dados.

Um exemplo dessa ameaça é um bucket AWS S3 inseguro com acesso a dados, o que parece ser responsável por muitos vazamentos recentes de dados. Mesmo que a aplicação que hospeda os dados seja muito segura, os dados ainda poderão ser acessíveis por meio de APIs do S3. /* ok, não sei se esse exemplo foi mt bom kk */

O Pipeline das API

Ouvimos falar de “pipelines” e “shift left” o tempo todo no desenvolvimento de software. Mas o que são esses conceitos no contexto das APIs?

O pipeline de APIs abrange todo o ciclo de vida da API, desde o desenvolvimento inicial (“à esquerda”) até a implantação na produção (“à direita”), ilustrado abaixo.

Desenvolvimento/Coding

As APIs nascem na etapa de desenvolvimento, idealmente, primeiro é criada uma especificação OpenAPI (OAS) para formalizar a API, especificar parâmetros, identificar possíveis inputs, códigos de retorno, etc.

Muitos desenvolvedores usam IDEs para organizar o ambiente, como VSCode (código aberto), PyCharm (comunidade e pago) ou GoLand (pago). Dependendo da IDE, pode haver extensões para ajudar na escrita das especificações OAS. Por exemplo, o VSCode tem várias extensões de linter de especificações OAS que podem sinalizar estaticamente problemas com as especificações, como Spectral (código aberto) e Postman (gratuito e pago). A extensão Spectral ainda possui um conjunto de regras OWASP Top 10 API Security Risks. Panoptica (avaliação gratuita e pago) pode executar diferentes linters de especificações OAS na linha de comando. /* Panoptica é um produto novo da Cisco, esse post é quase uma propaganda sobre ele */

Os assistentes de IA estão na moda agora e podem ser usados para desenvolver o código cliente/servidor da API. Assistentes de IA populares incluem GitHub Copilot (pago) e outros.

Nem todos os problemas de segurança da API podem ser detectados estaticamente. Muitos problemas só podem ser detectados em um ambiente dinâmico, onde as chamadas de API estão realmente sendo atendidas.

Após a conclusão do código da API, ele estará pronto para teste de unidade.

Teste de Unidade

Após a conclusão da etapa de desenvolvimento, o código da API passa por testes de unidade, onde são feitas chamadas “mockadas” para a API, com o objetivo de verificar se as APIs estão se comportando corretamente. Um ambiente de teste de unidade ainda é estático porque, embora possam ser feitas chamadas para funções de cliente e servidor, o aplicativo não está sendo executado como um todo.

Existem muitas ferramentas para gerar automaticamente código mockado de API e executar servidores de API e chamadas mockadas, incluindo WireMock (código aberto), Mockoon (código aberto), Microcks (código aberto), Postman (gratuito e pago), RestAssured (código aberto) e SoapUI (código aberto).

Depois que os testes de unidade forem escritos e aprovados, o código da API estará pronto para o CI/CD.

Continuous Integration/Continuous Delivery (CI/CD)

No CI/CD, o código é enviado para revisão de código, a imagem é buildada e alguns gating testes são executados automaticamente. Os gating testes incluem testes estáticos, como testes de unidade e linters de especificações OAS, e testes dinâmicos, como testes funcionais de ponta a ponta, onde o código é realmente instalado e a funcionalidade básica pode ser testada de forma automatizada.

Se todos os testes do CI/CD passarem, o código estará pronto para ser mergeado no repositório e testado em staging.

Staging

Um ambiente de staging é semelhante a um ambiente de produção real, mas é isolado para testes internos. Em staging, a aplicação é instalada e um time de garantia de qualidade pode checar as funcionalidades.

Testes de disponibilidade e desempenho também podem ser executados em staging. O teste de disponibilidade envolve a verificação de que não existem pontos únicos de falha em sua aplicação. Os testes de desempenho verificam se o sistema funciona em escala, o que inclui um alto volume de tráfego de API.

As ferramentas para desempenho de API e testes de carga incluem Locust (código aberto), SoapUI e Postman.

Outro tipo de ferramenta útil durante os testes em staging é o fuzzer. Um fuzzer passa dados incorretos/malformados para endpoints da API e tenta afetar negativamente a aplicação (por exemplo, fazer com que ela pare de responder, falhe, vaze dados, etc.). Exemplos de ferramentas de teste fuzz são RESTler (código aberto) e Panoptica.

Deploy Greenfield

A primeira vez que uma aplicação é implantada em produção é chamada de “implantação greenfield”. No greenfield, como não há artefatos anteriores, não há preocupações com versões anteriores ou atualizações.

Em um ambiente de produção, você pode verificar dinamicamente o tráfego da API em tempo real em busca de riscos de segurança para proteger sua aplicação. A plataforma Panoptica CNAPP tem um conjunto completo de funcionalidades de segurança de API que pode realizar esses testes.

Deploy Brownfield

O deploy brownfield é quando a aplicação é atualizada em um ambiente de produção existente. Com o brownfield, coisas como compatibilidade com versões anteriores da API e controle de versão entram em jogo. Por exemplo, os clientes da API poderiam continuar a usar uma versão anterior da especificação OAS depois que a aplicação fosse atualizada com uma nova. Várias versões de API deveriam ser suportadas.

Um deploy canário (Canary Deploy) é uma implantação brownfield em que diferentes versões da aplicação são executadas simultaneamente para reduzir o risco que uma nova versão traz. Um deploy canário recebe apenas uma parte do tráfego da API. Aqui, novamente, a compatibilidade com versões anteriores e o controle de versão da API são considerações importantes.

Evite problemas comuns de segurança de API em todo o pipeline

BOLA

Vulnerabilidades BOLA foram as vulnerabilidade mais comuns em APIs em 2023, de acordo com a OWASP. Estando incluídas nos itens API1:2023 (Broken Object Level Authorization) e API3:2023 (Broken Object Property Level Authorization) do Top 10.

Conforme mencionado anteriormente, em um ataque BOLA, um usuário final é capaz de acessar dados aos quais não tem autorização para acessar, geralmente porque os metadados vazam nas respostas da API do aplicativo /* eu, particularmente, fortemente discordo dessa atribuição de causa aos metadados vazados nas respostas. O motivo real é a ausência da autorização e sempre vai ser 🤷‍♂️ */.

Como os dados, especialmente PII, são um dos principais alvos de vazamentos, qualquer acesso não autorizado é um enorme problema de segurança.

Como vulnerabilidades BOLA podem ser evitadas no pipeline da APIs?

• Durante o desenvolvimento, certifique-se de ter um modelo de autorização forte na aplicação que não permita acesso a dados sem autorização e certifique-se de que nenhum dado vaze nas respostas da API;
• No desenvolvimento e CI/CD, use linters de especificações de OAS para sinalizar possíveis problemas de autorização;
• Durante testes de unidade e CI/CD, faça chamadas mockadas simulando tentativas de acesso sem autorização;
• No CI/CD e staging, execute um fuzzer nos endpoints da API que enviará inputs malformados e sinalizará qualquer acesso inesperado aos dados;
• Em staging e produção, execute ferramentas dinâmicas de segurança de APIs para inspecionar o tráfego de API e indicar possíveis problemas de BOLA. Panoptica possui recursos de detecção BOLA.

BFLAs

Vulnerabilidades BFLA ocorrem quando funcionalidades da aplicação são utilizadas sem a devida validação de autorização, seja por um usuário final chamando a API ou entre microsserviços. BOLA (acima) trata de acesso a dados, BFLA trata de acesso a funcionalidades. Obter acesso não autorizado a uma funcionalidade pode levar a violações de dados. No OWASP Top 10, BFLAs são descritos no item API5:2023 (Broken Function Level Authorization).

Como os BFLAs podem ser evitados em todo o pipeline da API?

• Durante o desenvolvimento, certifique-se de ter um modelo de autorização forte para o acesso das funcionalidades da aplicação, tanto pra usuários finais, quanto para microsserviços;
• Nos teste unitários e CI/CD, execute chamadas mockadas simulando tentativas de acesso a funcionalidades sem autorização necessária;
• Em staging e em produção, execute ferramentas dinâmicas de segurança de API para inspecionar o tráfego da API e sinalizar possíveis problemas de BFLA. A Panoptica tem a capacidade de aprender o modelo de autorização BFLA e então detectar possíveis violações no tráfego em tempo real.

Autenticação Fraca

A autenticação fraca em uma aplicação torna mais fácil o comprometimento por um invasor, podendo permitir o acesso a contas e dados de usuários. Autenticação fraca (ou quebrada) está incluída no Top 10 da OWASP nos itens API2:2023 (Broken Authentication) e API8:2023 (Security Misconfiguration).

Uma forma de autenticação fraca é a basic auth, que basicamente é o login por nome de usuário e senha, principalmente quando a própria senha é “fraca”, em outras palavras, senhas curtas, senhas muito comuns (por exemplo, que podem ser encontradas em uma pesquisa no dicionário) ou senhas reutilizadas em contas.

A autenticação fraca também pode ser devida à segurança fraca do endpoint da API, por exemplo, usando HTTP em vez de HTTPs.

Os problemas de criptografia se enquadram nesta categoria também. Ter endpoints sem criptografia ou com criptografia fraca pode abrir espaço para ataques na sua aplicação. Se não houver criptografia, todo o tráfego da API estará “em texto plano”, o que significa que pode ser usado e lido facilmente. A criptografia fraca pode envolver chaves de criptografia mais curtas que podem ser facilmente comprometidas.

Como a autenticação fraca pode ser evitada no pipeline da API?

• Desenvolva endpoints seguros com criptografia forte habilitada (por exemplo, exigindo HTTPS);
• Quando usar basic auth, exija senhas fortes e autenticação multifator (MFA);
• No desenvolvimento e CI/CD, use linters de especificações OAS (particularmente com o conjunto de regras OWASP Top 10) para sinalizar problemas de endpoint inseguros;
• Em testes de unidade e CI/CD, use chamadas mockadas a API simulando autenticação fraca e tente obter acesso a aplicação;
• Em staging e produção, execute ferramentas dinâmicas de segurança de API para sinalizar autenticação fraca no tráfego de API em tempo real. Panoptica pode detectar muitas formas de autenticação fraca.

Shadow APIs

As Shadow APIs são aquelas que não estão documentadas em nenhuma especificação OAS. Posam como um risco à segurança que você talvez nem saiba que possui. O item API9:2023 do OWASP Top 10 (Improper Inventory Management) trata também de shadow APIs.

À medida que sua aplicação evolui e cresce, é improvável que a segurança das shadow APIs também evolua. Elas podem ser até totalmente esquecidas, expondo uma brecha de segurança contínua ou um backdoor no seu sistema.

Como as Shadow APIs podem ser evitadas no pipeline da API?

• Durante o desenvolvimento, faça um inventário de todas as APIs e documente cada uma delas em uma especificação OAS; /* aproveite e lembre de manter as suas especificações atualizadas e armazenadas corretamente*/.
• Em staging e em produção, execute ferramentas dinâmicas de segurança de API que possam detectar shadow APIs no tráfego em tempo real e reconstruir uma especificação OAS para que sejam documentadas adequadamente. Panoptica tem esses recursos.

APIs Zumbis

APIs Zumbis são APIs obsoletas na especificação OAS, mas que ainda estão ativas na aplicação, respondendo. Elas ocorrem em ambientes de produção brownfield e canário, onde diversas versões de API podem estar em uso. Esse problema também é descrito no item API9:2023 do OWASP Top 10 (Improper Inventory Management).

Assim como as shadow APIs, é improvável que as APIs zumbis evoluam com a aplicação e possam receber menos revisão do ponto de vista de segurança, deixando assim um backdoor em seu sistema.

Como as APIs zumbis podem ser evitadas no pipeline da API?

• Remova o suporte para APIs zumbis (obsoletas) o mais rápido possível;
• Em staging e produção, execute ferramentas de segurança de API dinâmicas que possam detectar APIs zumbis no tráfego em tempo real, como o Panoptica.

Autenticação de terceiros fraca

Mesmo que o acesso aos dados do seu aplicativo seja realmente seguro, a autenticação fraca de terceiros ainda pode expor seus dados a ameaças. O acesso de terceiros aos seus dados inclui bancos de dados, buckets S3, etc. A autenticação fraca de terceiros está incluída no item API8:2023 (Security Misconfiguration) e API10:2023 (Unsafe Consumption of APIs) do OWASP Top 10.

Como evitar a autenticação fraca de terceiros no pipeline da API?

• Durante o desenvolvimento, mantenha um inventário de todas as APIs e serviços de terceiros que estão sendo usados pelo seu aplicativo;
• Verifique se o acesso de terceiros é seguro;
• Em CI/CD e staging, use uma ferramenta para avaliar a segurança de chamadas de API de terceiros. O Panoptica CLI possui essa funcionalidade.
• Em staging e produção, use scanners de segurança na nuvem para detectar autenticação fraca de terceiros. Exemplos de ferramentas de verificação de segurança em nuvem são AWS Config (serviço pago), Azure Automation and Control (gratuito e pago), GCP Cloud Asset Inventory (gratuito) e CloudQuery (código aberto e pago).

Consumo de recursos

O consumo irrestrito de recursos é tratado no item API4:2023 do OWASP Top 10. Se um aplicativo for inundado com muitas chamadas de API em um curto período de tempo, isso poderá ter consequências negativas. Por exemplo, recursos de aplicativos como CPU, RAM e armazenamento podem ser rapidamente consumidos ou esgotados, levando a custos operacionais potencialmente mais elevados, tempo de resposta mais lento ou até mesmo falhas e interrupções de aplicativos.

Como evitar o consumo irrestrito de recursos no pipeline da API?

• Durante o desenvolvimento, adicione limitação de taxa ao processamento da API (rate-limit), incluindo uma taxa máxima de solicitações de API e um timeout razoável;
• Em staging, use testes de desempenho que excedam a taxa permitida de solicitações de API e verifiquem se o aplicativo ainda está funcionando conforme o esperado;
• Em staging e produção, use um API gateway na frente da alicação para aplicar throttle e rate-limit nas solicitações recebidas. Alguns API gateways populares são AWS API Gateway (gratuito e pago), GCP API Gateway (gratuito e pago), Kong (código aberto e pago), Tyk (código aberto) e Azure API Management (gratuito e pago). Note que a aplicação ainda precisa de sua própria funcionalidade de rate-limit ao usar um API gateway. /* esse detalhe é importante mesmo */

O item API6:2023 (Unrestricted Access to Sensitive Business Flows) da OWASP está relacionado ao consumo irrestrito de recursos, mas implica que automação, bots mal-intencionados ou IA estão envolvidos no abuso da API, agravando o consumo de recursos.

URL Spoofing

Com um ataque de URL spoofing, uma URL inválida ou maliciosa é passada em uma requisição da API e o servidor faz proxy da URL sem validá-la. A URL suspeita pode ser um site falso ou um webhook, o que poderia permitir o acesso a dados confidenciais e PII. Este tipo de vulnerabilidade é abordado no item API7:2023 (Server Side Request Forgery) da OWASP.

Como o URL spoofing pode ser evitada no pipeline da API? A defesa contra esse tipo de ataque pode ser complexa. Um bom material para começar é o próprio **Cheat Sheet da OWASP,** mas de forma geral, as medidas de prevenção incluem:

• Durante o desenvolvimento, execute validações nas URLs fornecidas, incluindo o endereço IP e o nome de domínio;
• Crie uma lista de URLs permitids (allow list), se possível, e valide a URL fornecida com a lista;
• Em testes de unidade e CI/CD, execute chamadas mockadas a API simulando a passagem de URLs inválidas para a API.

Injeção de Dados

A injeção de dados pode permitir que atacantes passem dados, configurações ou programas maliciosos para uma aplicação por meio de APIs. Isso pode permitir o acesso indevido a dados (por exemplo, BOLA) ou tornar um sistema instável.

Como a injeção de dados pode ser evitada no pipeline da API?

• Durante o desenvolvimento, inclua verificação estrita de tipo (ou seja, verifique o tipo correto de dados em uma solicitação, não permita tipos de dados inesperados) e validação de entrada no processamento da API;
• Estabeleça um limite máximo para o tamanho e a quantidade de dados que podem ser inseridos em uma solicitação. Por exemplo, tenha um tamanho máximo para uma entrada de string;
• No desenvolvimento e CI/CD, use linters de especificações da OAS para detectar problemas com a entrada de dados;
• Em testes de unidade e CI/CD, execute chamadas mockadas a API simulando tentativas de injeção de dados inválidos;
• Em CI/CD e staging, execute um fuzzer nos endpoints da API que envia dados inválidos ou malformados para a API. A CLI do Panoptica inclui recursos de fuzzing;
• Em staging e produção, execute ferramentas dinâmicas de segurança de API que possam comparar o tráfego da API com as especificações da OAS e sinalizar discrepâncias de dados (incluindo desvios de especificações). A plataforma Panoptica CNAPP possui esta funcionalidade.

Injeção de Código

*/ ao longo do texto, fiz algumas críticas relacionadas a como BOLA foi discutido. Porém, do meu ponto de vista, essa seção é a que mais precisa ser revisada. Tradicionalmente, injeção de código está relacionada a uma entrada de dados maliciosa contendo dados+códigos de tal forma que a aplicação executa o código enviado. Exemplos mais genéricos são XSS e Buffer Overflow. Na minha opinião, o que a autora descreve aqui está mais relacionada a riscos de supply chain, dependence confusion, etc. Apesar disso, vou manter a tradução do texto original */

A injeção de código é quando código indesejável é adicionado a uma aplicação. Como plug-insde IDE e copilotos de IA são cada vez mais usados para gerar código de cliente e servidor de API, existe o risco de que código “ruim” possa ser injetado na sua aplicação. Isto pode ter efeitos colaterais indesejados ou até mesmo maliciosos. Por exemplo, uma API não autorizada (malicioso) pode ser injetada em seu aplicativo, criando acesso backdoor. APIs não autorizadas se enquadram no problema API9:2023 da OWASP (Improper Inventory Management).

Como a injeção de código pode ser evitada no pipeline da API?

• Durante o desenvolvimento, é importante verificar qualquer código gerado com revisões completas do código;
• Em CI/CD, staging e produção, as varreduras de imagens podem procurar quaisquer vulnerabilidades e exposições comuns (CVEs) no aplicativo. Panoptica pode verificar problemas em imagens de contêiner Kubernetes e imagens de máquinas virtuais;
• Em staging e produção, execute ferramentas dinâmicas de segurança de API para verificar qualquer API não autorizada. Panoptica tem esse recurso.

Conclusão

Dos 10 principais riscos de segurança de API do OWASP Top 10, passando pelo pipeline de API e até problemas comuns de segurança de API e como evitá-los, cobrimos muito terreno, com muitas sugestões de ferramentas ao longo do caminho.

Desejamos a você e aos seus aplicativos o melhor em segurança de API!

Conclusão Real

O texto traduzido terminou na última seção. Esse parágrafo foi escrito por mim msmo 🤣. Nenhum texto é perfeito. Apesar de haver algumas oportunidades de melhoria no texto, como a autora contou na sua conclusão, muito terreno foi coberto, desde coisas mais básicas como o OWASP Top 10 e CI/CD, até algumas das práticas mais avançadas na segurança de APIs, como testes com Fuzzers e análise dinâmica em produção.

Uma coisa que gostei foi o formato de sugestões de como evitar cada vulnerabilidade, na fase de desenvolvimento, CI/CD, staging e produção. Vou tentar incorporar esse modelo nos meus textos futuros.

Evidentemente, tanto conteúdo precisaria de um livro pra descrever tudo em profundidade. Mas esse texto funciona bem como um ponto de partida e um guia básico. Vou tentar escrever mais traduções como essa de textos que eu achar interessantes e construtivos.

Não esqueçam de conferir o material original blogpost Securing APIs From Left to Right (and Everywhere in Between).