# Como Evitar Falhas de Configuração que Podem Expor Dados de CPF > Conheça as falhas de configuração mais comuns que podem expor dados de CPF em APIs e aprenda a preveni-las com checklist e exemplos práticos. **Publicado:** 07/05/2024 **Autor:** Redação CPFHub.io **URL:** https://cpfhub.io/blog/falhas-configuracao-expor-dados-cpf --- Para evitar que falhas de configuração exponham dados de CPF, implemente headers de segurança em todas as respostas (Content-Security-Policy, HSTS, X-Frame-Options), desative o modo debug em produção, restrinja CORS a domínios específicos e garanta que nenhuma credencial esteja no código-fonte. Essas medidas cobrem as causas de vazamento mais comuns identificadas pela [OWASP](https://owasp.org) antes mesmo de qualquer ataque sofisticado. ## Introdução Falhas de configuração (security misconfigurations) são consistentemente listadas entre as principais vulnerabilidades pela OWASP. No contexto de APIs de CPF, uma configuração incorreta pode transformar um serviço seguro em uma porta aberta para vazamento de dados pessoais. Servidores com modo debug ativado em produção, headers de segurança ausentes, permissões excessivas e endpoints expostos são exemplos de problemas que poderiam ser evitados com práticas adequadas. --- ## As falhas mais frequentes Estas são as configurações incorretas que mais frequentemente expõem dados de CPF em aplicações web e APIs: | Falha | Risco | Ocorrência | |-------|-------|------------| | Debug mode ativo em produção | Stack traces expõem estrutura interna e dados | Muito comum | | CORS permissivo (Access-Control-Allow-Origin: *) | Qualquer site pode consumir sua API | Comum | | Headers de segurança ausentes | Vulnerável a XSS, clickjacking e MIME sniffing | Muito comum | | Credenciais padrão não alteradas | Acesso administrativo trivial | Comum | | Endpoints de admin expostos | Atacantes acessam painéis de gerenciamento | Frequente | | Logs verbosos em produção | Dados de CPF aparecem em logs acessíveis | Muito comum | | Listagem de diretório habilitada | Arquivos sensíveis acessíveis via navegador | Ocasional | --- ## Configuração segura de headers HTTP Headers de segurança são a primeira linha de defesa e frequentemente ignorados. Configure-os em todas as respostas da sua aplicação: ```javascript const express = require("express"); const helmet = require("helmet"); const cors = require("cors"); const app = express(); // Helmet configura múltiplos headers de segurança app.use(helmet()); // CORS restritivo - apenas origens autorizadas app.use(cors({ origin: [ "https://meusite.com.br", "https://admin.meusite.com.br" ], methods: ["GET"], allowedHeaders: ["Content-Type", "x-api-key"], credentials: false, maxAge: 86400 })); // Headers adicionais para proteção de dados app.use((req, res, next) => { res.setHeader("Cache-Control", "no-store, no-cache"); res.setHeader("Pragma", "no-cache"); res.setHeader("X-Content-Type-Options", "nosniff"); res.setHeader("X-Frame-Options", "DENY"); res.setHeader( "Content-Security-Policy", "default-src 'self'" ); res.setHeader( "Strict-Transport-Security", "max-age=31536000; includeSubDomains" ); next(); }); // Proxy seguro para API de CPF app.get("/api/validar-cpf/:cpf", async (req, res) => { const response = await fetch( `https://api.cpfhub.io/cpf/${req.params.cpf}`, { headers: { "x-api-key": process.env.CPFHUB_API_KEY } } ); const data = await response.json(); // Retorna apenas o necessário ao frontend res.json({ valido: data.success }); }); ``` O header `Cache-Control: no-store` é especialmente importante para respostas que contenham dados de CPF, evitando que navegadores ou proxies armazenem informações sensíveis. --- ## Desabilitando modo debug em produção O modo debug é uma das falhas mais perigosas porque expõe variáveis de ambiente, stack traces e estrutura interna da aplicação: - **Django** -- certifique-se de que `DEBUG = False` e `ALLOWED_HOSTS` esteja configurado em produção - **Flask** -- nunca use `app.run(debug=True)` em produção, utilize Gunicorn ou uWSGI - **Express.js** -- não use `app.set('env', 'development')` e desabilite o error handler detalhado - **Spring Boot** -- configure `management.endpoints.web.exposure.exclude=*` para ocultar actuators - **Laravel** -- defina `APP_DEBUG=false` e `APP_ENV=production` no arquivo `.env` Automatize a verificação dessas configurações no pipeline de CI/CD para que builds com modo debug não cheguem à produção. --- ## Checklist de configuração segura Utilize esta lista de verificação antes de colocar qualquer integração com API de CPF em produção: - **Variáveis de ambiente** -- todas as credenciais estão em variáveis de ambiente ou cofres de segredos, nunca no código-fonte - **TLS obrigatório** -- todas as comunicações com a API utilizam HTTPS com TLS 1.2 ou superior - **CORS restritivo** -- apenas domínios autorizados podem fazer requisições à sua API - **Rate limiting** -- limites de requisição configurados para prevenir abusos - **Headers de segurança** -- todos os headers recomendados pela OWASP estão presentes nas respostas - **Modo debug desativado** -- confirmado que nenhum framework está em modo debug em produção - **Logs sanitizados** -- dados de CPF não aparecem em texto aberto nos logs - **Endpoints administrativos protegidos** -- painéis de admin acessíveis apenas via VPN ou com MFA - **Permissões de arquivo** -- arquivos de configuração com permissões restritas no sistema operacional ```bash # Verificação rápida de configurações em servidor Linux # Permissões de arquivo de configuração chmod 600 /app/.env chown app-user:app-group /app/.env # Verificar se TLS está habilitado curl -sI https://meusite.com.br/api/health | grep -i "strict-transport" # Verificar se debug está desativado curl -s https://meusite.com.br/api/endpoint-inexistente \ | python3 -c "import sys,json; d=json.load(sys.stdin); \ print('ALERTA: Debug ativo!' if 'traceback' in str(d) else 'OK')" ``` --- ## Automação de verificação de segurança Incorpore verificações automatizadas no pipeline para detectar misconfigurations antes do deploy: - **SAST (Static Application Security Testing)** -- ferramentas como Semgrep e SonarQube analisam o código em busca de configurações inseguras - **DAST (Dynamic Application Security Testing)** -- ferramentas como OWASP ZAP e Nuclei testam a aplicação em execução - **Infrastructure as Code scanning** -- Checkov e tfsec verificam configurações de infraestrutura em Terraform e CloudFormation - **Secret scanning** -- GitLeaks e TruffleHog detectam credenciais commitadas no repositório - **Container scanning** -- Trivy e Grype verificam vulnerabilidades em imagens Docker --- ## Perguntas frequentes ### Quais são os headers de segurança obrigatórios para uma API que trabalha com dados de CPF? Os essenciais são: `Strict-Transport-Security` (forçar HTTPS), `Content-Security-Policy` (limitar origens de recursos), `X-Content-Type-Options: nosniff` (prevenir MIME sniffing), `X-Frame-Options: DENY` (prevenir clickjacking) e `Cache-Control: no-store` (impedir que dados de CPF fiquem em cache). O Helmet.js para Node.js e bibliotecas equivalentes em outras linguagens configuram todos de uma vez. ### Por que o modo debug é tão perigoso em ambientes de produção com dados de CPF? O modo debug expõe stack traces com caminhos de arquivo, variáveis de ambiente e estrutura do banco de dados — em alguns casos, até dados das requisições, incluindo CPFs consultados. Essas informações aparecem em respostas HTTP visíveis ao cliente e podem ser suficientes para mapear a infraestrutura e extrair dados pessoais sem qualquer ataque elaborado. ### CORS permissivo realmente representa risco para dados de CPF? Sim. Com `Access-Control-Allow-Origin: *`, qualquer site pode fazer requisições à sua API de validação de CPF a partir do navegador de um usuário autenticado, usando as credenciais dele. Isso abre caminho para ataques CSRF onde sites maliciosos consultam CPFs em nome do usuário logado. Restrinja CORS a domínios específicos da sua aplicação. ### Como garantir que API keys de CPF não sejam expostas no código-fonte? Use variáveis de ambiente e cofres de segredos (AWS Secrets Manager, HashiCorp Vault, GitHub Secrets). Nunca comite a API key em repositórios Git — mesmo privados. Configure ferramentas de secret scanning como GitLeaks ou TruffleHog no pipeline de CI/CD para detectar e bloquear commits com credenciais expostas antes que cheguem ao repositório. ### Leia também - [Diferença entre validação de CPF e consulta de CPF: quando usar cada uma](https://cpfhub.io/blog/diferenca-entre-validacao-de-cpf-e-consulta-de-cpf-quando-usar-cada-uma) - [API de CPF grátis para desenvolvedores: como começar em 5 minutos](https://cpfhub.io/blog/api-cpf-gratis-desenvolvedores-comecar-5-minutos) - [Onboarding digital em fintechs: como validar CPF em menos de 30 segundos](https://cpfhub.io/blog/onboarding-digital-em-fintechs-como-validar-cpf-em-menos-de-30-segundos) - [KYC no Brasil: quais setores são obrigados a validar CPF por lei](https://cpfhub.io/blog/kyc-no-brasil-quais-setores-sao-obrigados-a-validar-cpf-por-lei) --- ## Conclusão Falhas de configuração são vulnerabilidades silenciosas que podem expor dados de CPF sem que um único ataque sofisticado seja necessário. A prevenção começa com headers de segurança adequados, modo debug desativado e CORS restritivo, e se estende a automações no pipeline de CI/CD que impeçam configurações inseguras de chegarem à produção. Ao integrar com a API do [cpfhub.io](https://www.cpfhub.io/), inclua no seu checklist de produção a verificação dos headers de segurança — é um dos controles de maior impacto com menor esforço de implementação.