Segurança para o código que escreves com o Cursor

"Segurança no Cursor" quer dizer duas coisas diferentes, e convém separá-las. A primeira é proteger a tua própria configuração do Cursor: o que sai da tua máquina, o que o agente pode executar sem te perguntar e em que servidores e ficheiros de regras confias. A segunda é proteger o código que o Cursor escreve por ti, que é o que acaba publicado e exposto à internet. Este guia cobre as duas, com um bloco de regras pronto a colar no teu projeto e um prompt de revisão para antes de cada publicação.

Parte 1: proteger a tua configuração do Cursor

O que sai da tua máquina

O Cursor envia para os seus servidores, e para os do fornecedor do modelo, o contexto de que precisa para responder: o ficheiro aberto, o que indexa do projeto e o que tu colas no chat. Ativa o modo de privacidade nas definições se não quiseres que esse código seja guardado nem usado para treino; em equipas, impõe-no a partir do plano. E lembra-te de que tudo o que colares no chat viaja: não coles dumps da base de dados nem ficheiros de credenciais "para ele perceber".

Exclui os segredos da indexação

O Cursor indexa o projeto para dar contexto ao modelo. Um .env, um service-account.json ou uma pasta de certificados não deviam fazer parte desse índice. Cria um ficheiro .cursorignore na raiz com os padrões a excluir; segue a sintaxe do .gitignore:

.env
.env.*
*.pem
*.key
**/service-account*.json
secrets/

Se algo sensível já estava indexado, apaga-o do índice nas definições e, se era uma chave real, roda-a.

Execução automática de comandos

O agente do Cursor pode executar comandos de terminal por conta própria se o permitires. É prático e é perigoso: um prompt mal interpretado, ou um texto malicioso que o agente lê de um ficheiro ou de uma página web, pode acabar num rm -rf, num git push --force ou num curl | sh. Mantém a confirmação manual para comandos que apagam, publicam ou instalam, usa a lista de permitidos só para coisas inofensivas (testes, lint, build) e nunca dês ao agente credenciais de produção no ambiente.

Servidores MCP de terceiros

Os servidores MCP alargam o que o agente consegue fazer: ler a tua base de dados, chamar APIs, controlar o browser. Cada um é código que corre com as tuas permissões e cujas descrições de ferramentas o modelo lê como instruções. Instala só servidores de fontes que conheças, revê o que pedem, prefere os que funcionam com credenciais só de leitura e vigia as alterações de configuração: um servidor que muda a sua definição depois de o teres aprovado é um sinal de alarme.

Ficheiros de regras de repositórios alheios

Os ficheiros de regras (.cursor/rules, .cursorrules) são instruções que o modelo obedece em cada pedido. Se clonares um repositório, um template ou um exemplo da internet, pode trazer regras que não vês à primeira vista, até com caracteres invisíveis que escondem instruções para introduzir código malicioso. Abre e lê os ficheiros de regras de qualquer projeto que não tenhas escrito tu antes de deixares o agente trabalhar nele.

Mantém o Cursor atualizado

Como qualquer editor com um agente lá dentro, o Cursor já teve falhas de segurança próprias, várias relacionadas com a confiança em espaços de trabalho e com MCP. Atualiza quando sair uma versão nova e não abras projetos de origem duvidosa com a execução automática ativa.

Parte 2: as falhas que o Cursor mete no teu código

O modelo otimiza para que o código funcione, não para que seja seguro. Estes são os padrões que mais se repetem em apps escritas com o Cursor e como os detetar:

• Segredos hardcoded. Para pôr um exemplo a arrancar depressa, a chave acaba no código ou numa variável pública. Procura sk_live, service_role, AKIA e -----BEGIN no teu bundle. Mais em os segredos que a tua app deixa fugir no browser.
• CORS aberto e autenticação desativada "para funcionar". Perante um erro, a sugestão típica é refletir qualquer origem ou saltar a verificação de sessão. Funciona no momento e deixa a porta aberta em produção.
• Endpoints que confiam no cliente. Rotas que aceitam o user_id, o papel ou o preço a partir do corpo do pedido sem o verificar no servidor.
• Sem headers de segurança. O código gerado quase nunca acrescenta CSP, HSTS ou X-Frame-Options; confirma com o verificador de headers.
• Dependências antigas. O modelo propõe as versões que conhece, não as últimas. Corre npm audit antes de publicar.

Um bloco de regras de segurança para o teu projeto

A coisa mais rentável que podes fazer é dizer ao modelo, de uma vez por todas, o que não deve fazer. Cola isto em .cursor/rules/security.mdc (ou em .cursorrules) com a regra marcada para se aplicar sempre. Está em inglês porque é a língua em que o modelo obedece melhor:

# Security rules (always apply)
- Never hardcode API keys, tokens or passwords. Read them from
  environment variables on the server only.
- Never put secrets in variables prefixed NEXT_PUBLIC_, VITE_ or NUXT_PUBLIC_.
- Never disable authentication, authorization or Row Level Security
  to make something work. Fix the policy instead and explain why.
- CORS: allow only an explicit list of origins. Never reflect the
  request origin together with credentials.
- Validate input and authorize every API route on the server, even if
  the UI hides the action.
- Set security headers: CSP, HSTS, X-Frame-Options,
  X-Content-Type-Options, Referrer-Policy.
- Session cookies must be Secure, HttpOnly and SameSite=Lax.
- Add a dependency only when necessary, pinned to a maintained version.
- If a request conflicts with these rules, stop and explain the
  security trade-off before writing code.

Um prompt de revisão antes de publicar

Antes de cada publicação, abre um chat novo com todo o projeto em contexto e pede-lhe: "Revê este projeto como auditor de segurança antes da publicação. Lista cada segredo que chegue ao código do cliente, cada rota de API sem verificação de sessão ou permissões, cada regra de CORS ou RLS relaxada, os headers de segurança em falta e as cookies sem Secure, HttpOnly ou SameSite. Para cada resultado indica ficheiro, linha e a correção. Não mudes código ainda." Depois corrige os resultados um a um e volta a pedir a revisão.

Confirma o resultado por fora

O modelo revê o código que vê; o que importa é o que um atacante vê. Quando publicares, corre o Scanaris sobre o URL público: deteta segredos no JavaScript, CORS permissivo, headers e cookies mal configurados, ficheiros sensíveis acessíveis e versões com vulnerabilidades conhecidas, e devolve-te um prompt para colar no Cursor por cada resultado. Se o deixares em monitorização, avisa-te quando uma sessão de vibe coding voltar a abrir algo que já estava fechado. Para o mapa completo, lê o guia de segurança para apps criadas com IA e a checklist de lançamento.

Perguntas frequentes

É seguro usar o Cursor com código da empresa?

Com o modo de privacidade ativo, os segredos excluídos da indexação e sem colar dados reais no chat, o risco é comparável ao de qualquer ferramenta na nuvem. Confirma as políticas da tua empresa e, se for preciso, usa o plano de equipa para impor a configuração.

O código que o Cursor escreve é menos seguro do que o escrito à mão?

Não necessariamente, mas falha em sítios previsíveis: segredos, permissões que estorvam e configuração que ninguém pediu. Com regras claras e uma revisão antes de publicar, o resultado costuma ser melhor do que a média.

O que faço se o agente já executou algo que não devia?

Roda qualquer credencial a que tivesse acesso, revê o histórico do git e do terminal para ver o que tocou, e restringe a execução automática antes de continuares.