As APIs estão por toda parte. Com o “boom” das estratégias digitais em mobilidade, cloud computing, mídias sociais e os dispositivos inteligentes da Internet das Coisas, muitas empresas estão desenhando e expondo REST APIs – desde jovens startups até grandes empresas.

E temos que considerar que 2014 foi o ano em que o assunto “segurança” esteve nos holofotes – desde a Sony Pictures e a Jennifer Lawrence (que nada tem a ver com APIs) até casos como o da Tesla Motors, Snapchat e Bitly, em que vulnerabilidades nas APIs os levaram para os destaques dos portais de tecnologia e segurança da informação.

Mas como, então, sua empresa que já expõe ou pretende expor APIs pode se preparar para evitar que dados sigilosos de usuários possam cair em mãos erradas? É o que o restante deste texto aborda.

Antes de qualquer coisa, é importante determinar o nível de criticidade e o risco ao qual sua API está exposta. Por exemplo, se os aplicativos que consomem sua API forem apenas apps internos, ou seja, desenvolvidos por sua própria empresa, o nível de risco é bem mais baixo do que quando a API possui centenas de apps externos desenvolvidos por outras empresas ou pela comunidade. Outros elementos que também devem ser considerados são: os dados que a API manipula são relacionados ao usuário e são informações sensíveis? A API permite operações que afetam os dados de forma severa (como remoção em bulk etc.)?

Dependendo da sua resposta a esses questionamentos, você poderá saber com mais precisão o risco de se negligenciar questões de segurança. Sugerimos que faça uma classificação de criticidade para embasar suas decisões de design.

Bom, mas partindo do pressuposto que sua API requer a adição de certo nível de segurança, agrupamos os 5 principais atributos, bem como as ameaças, vulnerabilidades e dicas de como mitigar os principais riscos.

1. Autenticação e autorização

Primeira e principal preocupação relacionada à exposição de APIs. Sempre! Você é realmente quem diz ser? Você tem acesso a esse recurso? Estas são perguntas fundamentais. Evitar ataques de força bruta e roubo de credenciais são ameaças relacionadas à autenticação e autorização de APIs.

As alternativas de mitigação desses riscos vão desde uma simples autenticação Basic HTTP a padrões mais modernos e seguros, como OAuth2 e OpenID Connect.

OAuth2 está se firmando como principal forma de autorizar acesso a determinado recurso, especialmente quando o acesso deve ser concedido pelo próprio usuário. Gigantes digitais como Facebook, Google, Twitter, LinkedIn o adotaram.

Você já deve ter se deparado com uma tela de um dos serviços acima solicitando que você dê permissão para um determinado aplicativo. Pois é, trata-se de um OAuth2, onde o Facebook é o Authorization Server e o TripAdvisor é o Client Application. Nessa situação, eu, como dono dos dados (Resource Owner), estou concedendo acesso a um determinado escopo de informações para o Client Application que, a partir daquele momento, pode buscar informações em meu nome.

Importante destacar que essa pode não ser a melhor alternativa para a sua API, mas certamente é um padrão que vale a pena ser estudado/considerado.

Vale destacar também que, independentemente de qual seja o mecanismo de autenticação/autorização que você escolheu, valem as máximas de nunca salvar tokens em plain-text, não enviar senhas por e-mail e tomar cuidado com forward/redirect de requisições em redes desconhecidas.

2. Privacidade

Ataques como Man-in-the-middle e Network Eavesdropping podem revelar dados sensíveis dos seus usuários. Então, é importante atentar para algumas contramedidas que diminuam o risco de exposição desse tipo de informação.

Destaca-se a importância do uso do SSL/TLS e, em algumas situações, é até recomendável que você use um mecanismo adicional de criptografia. Além disso, arquivos de log são fontes preciosas de informações que não deveriam estar lá, então, sempre faça o mascaramento de informações sensíveis, como números de cartão de crédito, informações de saúde etc.

3. Disponibilidade

As APIs estão acessíveis? O desempenho está satisfatório? Ataques distribuídos de negação de serviço (DDoS) estão entre os mais comuns. Então, como desenvolver as estruturas básicas para resistir bravamente?

A recomendação básica é instrumentalizar a monitoração do tráfego nas APIs, preferencialmente com alertas capazes de identificar comportamento malicioso.

Um recurso bastante útil em soluções de gerenciamento de APIs é a capacidade de limitar o uso dos apps por meio de controles de rate limiting (ou throttling).

4. Auditoria

E se um dos seus clientes alegar que ele não fez aquele conjunto de invocações à sua API e, portanto, não irá pagar o valor correspondente? Esse fenômeno é chamado de repudiação. Como evitá-lo?

Logs detalhados são a melhor alternativa. A capacidade de evidenciar o resumo das chamadas recebidas, bem como mostrar os detalhes dessas chamadas, é uma resposta bastante eficiente para a não-repudiação.

Alguns cuidados especiais devem envolver o fato de que arquivos de logs podem crescer (e muito!), e que esses arquivos nem sempre são fáceis de inspecionar/buscar. Uma alternativa interessante é deixar essa tarefa para ferramentas de API management.

5. Integridade

As APIs são como um canal de comunicação entre o mundo externo e seu backend. Permitir que recursos críticos sejam apagados requer sempre cautela. Alguns tipos de ataques como injeção de SQL, XML e JSON podem causar sérios danos.

A principal recomendação aqui é a busca pela redução da superfície de ataque, ou seja, nunca exponha recursos e operações que não precisem ser expostos. Parece óbvio, mas muitas empresas aplicam técnicas de geração automática de APIs a partir dos serviços e dados do backend. Essas técnicas, além de gerarem APIs com design deselegante e de difícil entendimento, por vezes podem abrir brechas indesejáveis.

Sim, realmente são muitos pontos a levar em consideração quando o assunto é segurança de APIs. Além de tudo isso, nunca é demais lembrar que o ser humano ainda é o elo mais fraco nessa corrente.

***

Texto publicado originalmente na Revista iMasters.