As configurações de CORS estão adequadas para APIs?

Entender e configurar corretamente o CORS (Cross-Origin Resource Sharing) é fundamental para garantir que sua API funcione adequadamente em ambientes web modernos, permitindo ou bloqueando solicitações de diferentes origens conforme necessário para sua aplicação.

A configuração inadequada do CORS pode resultar em problemas de segurança graves ou impedir que clientes legítimos acessem sua API, tornando-se um dos aspectos mais críticos no desenvolvimento de APIs web atuais.

O que é CORS e por que é importante para suas APIs

CORS (Cross-Origin Resource Sharing) é um mecanismo de segurança implementado pelos navegadores que controla como recursos web em uma página podem ser solicitados de outro domínio. Esta política de segurança foi desenvolvida para proteger os usuários contra ataques maliciosos.

Quando seu frontend tenta acessar uma API hospedada em um domínio diferente, o navegador verifica se o servidor da API permite explicitamente solicitações daquela origem. Sem a configuração adequada de CORS, o navegador bloqueará essas solicitações, resultando no famoso erro: “Access to fetch at ‘URL’ from origin ‘ORIGIN’ has been blocked by CORS policy”.

A implementação correta do CORS é crucial porque:

• Protege seus usuários contra ataques de cross-site scripting (XSS)
• Permite que aplicações legítimas acessem sua API
• Proporciona controle granular sobre quais domínios, métodos e cabeçalhos são permitidos

Como verificar se suas configurações CORS estão corretas

Para determinar se suas configurações de CORS estão adequadas, você precisa avaliar vários aspectos técnicos e realizar testes específicos:

1. Inspecione os cabeçalhos de resposta da sua API

Usando as ferramentas de desenvolvedor do navegador (F12), verifique os cabeçalhos de resposta da sua API. Os principais cabeçalhos CORS a observar são:

• Access-Control-Allow-Origin: Define quais origens podem acessar o recurso
• Access-Control-Allow-Methods: Especifica os métodos HTTP permitidos (GET, POST, etc.)
• Access-Control-Allow-Headers: Lista os cabeçalhos que podem ser usados na requisição
• Access-Control-Allow-Credentials: Indica se a requisição pode incluir credenciais
• Access-Control-Max-Age: Especifica por quanto tempo os resultados da preflight podem ser armazenados em cache

2. Teste com diferentes origens

Crie um ambiente de teste simples em um domínio diferente e tente acessar sua API. Você pode usar uma página HTML básica com JavaScript para fazer requisições fetch() ou XMLHttpRequest para sua API.

Jake Archibald, desenvolvedor advogado do Google Chrome, explica: “O CORS é frequentemente mal compreendido. Ele não é uma forma de proteger seu servidor – é uma forma de proteger os usuários de sites maliciosos que tentam explorar a confiança que o navegador tem em seu site.”

Configurações recomendadas para diferentes cenários

Para APIs públicas

Se sua API deve ser acessível de qualquer origem:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization

No entanto, esta abordagem permissiva não é recomendada para APIs que exigem autenticação, pois o cabeçalho Access-Control-Allow-Origin: * não permite o envio de credenciais.

Para APIs com autenticação

Se sua API requer autenticação e precisa aceitar credenciais:

Access-Control-Allow-Origin: https://seu-dominio-confiavel.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true

Observe que quando Access-Control-Allow-Credentials é true, Access-Control-Allow-Origin não pode ser * e deve especificar uma origem.

Para APIs com múltiplos domínios confiáveis

Se você precisa permitir múltiplos domínios específicos, sua API deve verificar o cabeçalho Origin da requisição e responder dinamicamente:

// Pseudocódigo para o servidor
if (origensPermitidas.includes(requestOrigin)) {
response.setHeader(‘Access-Control-Allow-Origin’, requestOrigin);
response.setHeader(‘Access-Control-Allow-Methods’, ‘GET, POST, PUT, DELETE, OPTIONS’);
response.setHeader(‘Access-Control-Allow-Headers’, ‘Content-Type, Authorization’);
response.setHeader(‘Access-Control-Allow-Credentials’, ‘true’);
}

Implementação em diferentes tecnologias

Node.js com Express

Utilizando o pacote cors:

const express = require(‘express’);
const cors = require(‘cors’);
const app = express();

// Configuração básica permitindo qualquer origem
app.use(cors());

// Ou configuração mais restritiva
const corsOptions = {
origin: ‘https://seu-site.com’,
methods: [‘GET’, ‘POST’, ‘PUT’, ‘DELETE’],
allowedHeaders: [‘Content-Type’, ‘Authorization’],
credentials: true
};

app.use(cors(corsOptions));

ASP.NET Core

No arquivo Startup.cs:

public void ConfigureServices(IServiceCollection services)
{
services.AddCors(options =>
{
options.AddPolicy(“MinhaPoliticaCors”,
builder => builder
.WithOrigins(“https://seu-site.com”)
.AllowAnyMethod()
.AllowAnyHeader()
.AllowCredentials());
});
}

public void Configure(IApplicationBuilder app)
{
app.UseCors(“MinhaPoliticaCors”);
// Outras configurações…
}

Python com Flask

Utilizando Flask-CORS:

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app, resources={r”/api/*”: {“origins”: “https://seu-site.com”, “methods”: [“GET”, “POST”, “PUT”, “DELETE”], “allow_headers”: [“Content-Type”, “Authorization”], “supports_credentials”: True}})

Erros comuns e como resolvê-los

1. Erro: “No ‘Access-Control-Allow-Origin’ header is present”

Este erro ocorre quando o servidor não inclui o cabeçalho Access-Control-Allow-Origin na resposta.

Solução: Configure seu servidor para incluir o cabeçalho Access-Control-Allow-Origin com o valor apropriado.

2. Erro: “Request header field X is not allowed”

Este erro ocorre quando a requisição inclui um cabeçalho que não está listado no Access-Control-Allow-Headers.

Solução: Adicione o cabeçalho necessário à lista Access-Control-Allow-Headers.

Segundo Troy Hunt, especialista em segurança web: “CORS não é um mecanismo de segurança para proteger sua API – é uma forma de relaxar a política de mesma origem. Se você está contando com CORS para proteger sua API, está fazendo isso errado.”

3. Erro: “Method X is not allowed”

Este erro ocorre quando a requisição usa um método HTTP que não está listado no Access-Control-Allow-Methods.

Solução: Adicione o método necessário à lista Access-Control-Allow-Methods.

Melhores práticas de segurança para CORS

Implementar CORS corretamente não é apenas sobre fazer sua API funcionar – é também sobre segurança:

• Seja específico com origens: Evite usar * quando possível. Liste apenas os domínios que realmente precisam acessar sua API.
• Limite métodos e cabeçalhos: Permita apenas os métodos HTTP e cabeçalhos que sua aplicação realmente precisa.
• Tenha cuidado com credenciais: Se você permitir credenciais com Access-Control-Allow-Credentials: true, certifique-se de que sua autenticação seja robusta.
• Considere a expiração de preflight: Use Access-Control-Max-Age para reduzir o número de requisições OPTIONS, mas não defina valores muito altos que dificultariam alterações nas políticas.
• Implemente validação adicional: CORS é apenas uma camada de proteção. Implemente também validação de token, rate limiting e outras medidas de segurança.

Ferramentas para testar suas configurações CORS

Para garantir que suas configurações estejam corretas, utilize estas ferramentas:

• CORS Test – Uma ferramenta online para testar configurações CORS
• test-cors.org – Permite testar diferentes tipos de requisições CORS
• Ferramentas de desenvolvedor do navegador – Use o Console e a aba Network para inspecionar erros e cabeçalhos
• ReqBin – Um cliente HTTP online para testar APIs

Lembre-se que a configuração ideal de CORS depende do seu caso de uso específico. Uma API pública terá requisitos diferentes de uma API interna ou de uma que lida com dados sensíveis.

Verificação final

Para verificar se suas configurações CORS estão adequadas, faça esta checklist:

• Suas configurações permitem acesso apenas das origens necessárias?
• Os métodos HTTP necessários estão permitidos?
• Os cabeçalhos necessários estão permitidos?
• Se sua API usa autenticação, o Access-Control-Allow-Credentials está configurado corretamente?
• Você testou sua API de diferentes origens para confirmar que as configurações funcionam como esperado?

Com estas verificações e ajustes, você garantirá que sua API seja acessível para clientes legítimos enquanto mantém um nível adequado de segurança.

Quais domínios específicos você precisa que acessem sua API, e você já testou se as requisições desses domínios estão funcionando corretamente?