Normas de Desenvolvimento de Sistemas Seguros / Secure System Development

Se o ambiente de execução possuir uma proibição global de ativos (proibindo ataque/varredura de determinados ativos próprios), a configuração global tem precedência; esta skill não a substitui. Para modelos gerais, consulte references/internal-policy.example.md (a versão publicada não contém nenhum endereço interno real).

Modo de Uso

Antes de escrever o código, leia a "Lista Vermelha"; após escrever, verifique-a. Durante o design e a revisão, leia a "Fase Um". Ao envolver módulos específicos, abra o arquivo correspondente em references/ conforme o ponteiro. Antes do envio, execute a "Revisão Pré-Lançamento". Após o lançamento, consulte "Tempo de Execução e 0day".

Se uma tarefa envolver apenas uma parte (por exemplo, escrever apenas um endpoint de login, projetar apenas uma tabela de pedidos), leia apenas o capítulo e a referência correspondentes; não memorize tudo.

Autoverificação Executável (Recomendado Executar Primeiro)

python scripts/scan_redlines.py <diretório_alvo> --format text            # Leitura humana
python scripts/scan_redlines.py <diretório_alvo> --format sarif --fail-on high   # Bloqueio CI
python scripts/scan_redlines.py <diretório_alvo> --code-only              # Pular docs, apenas código

Biblioteca padrão Python pura, sem necessidade de instalação de dependências. Cobre 18 categorias de regras, incluindo: concatenação SQL, innerHTML/eval, curingas CORS e reflexão, fallback global para a página inicial, chaves codificadas, armazenamento de senhas com MD5, injeção de comandos, desabilitação de verificação de certificados, chaves de depuração, campos confidenciais em logs, caminhos de upload não validados, etc. Os resultados apontarão para a referência correspondente.

Tratamento de falsos positivos: adicione o comentário redline: ignore (ignora a linha inteira) ou redline: ignore SQL001 (ignora apenas a regra especificada) no final da linha. Não desative uma regra inteira para eliminar alertas — anote o motivo e explique na revisão.

Dois modelos: assets/threat-model-template.md (modelagem de ameaças na fase de design), assets/review-checklist.md (checklist pré-lançamento por tipo de projeto).

Determine Primeiro o Tipo de Projeto (Decide Quais Regras se Aplicam)

Cenário	Forma Típica	Regras de Segurança	Requisitos de Integridade	Indexação (SEO)
Site Público	Site corporativo, página de destino, blog, documentação, frontend de loja	Conjunto completo	Baixo (conteúdo público)	Obrigatório: 404 real, sitemap, canonical, dados estruturados
Produto Pós-login	SaaS, ferramentas, comunidade de usuários	Conjunto completo + sistema de conta completo	Médio (operações sensíveis assinadas)	Submeter apenas páginas públicas (marketing/central de ajuda); páginas privadas com noindex
Painel Administrativo	admin, painel operacional, sistema de atendimento/revisão	Conjunto completo + entrada independente + MFA + log de auditoria	Alto (todas as operações de escrita assinadas + auditoria)	Proibida indexação: site inteiro com noindex + autenticação obrigatória
Sistema Interno/Pessoal	Plataforma interna, ferramentas pessoais, painel de scripts, NAS doméstico	Autenticação + exposição mínima + rate limiting + atualizações rápidas	Médio (dependendo da superfície de exposição)	Proibida indexação; não colocar em caminhos padrão na internet pública, não depender de "obscuridade" como segurança
API Pura	REST / GraphQL / Chamadas entre serviços	Autenticação + validação de entrada + rate limiting + gerenciamento de versão	Conforme o negócio (pagamento/financeiro deve ser alto)	Não aplicável (não gera páginas)

A única questão para determinar é: Esta URL deve aparecer nos mecanismos de busca?

Sim → Executar como site público, todas as regras de SEO se aplicam.
Não → Executar "Proibida indexação": X-Robots-Tag: noindex em todo o site, proibir rastreamento em robots, autenticação obrigatória. Não aplique otimizações de SEO (sitemap, canonical, dados estruturados) a painéis administrativos ou sistemas internos — é um desperdício e expõe a superfície de ataque.
Independentemente do cenário, "caminhos inexistentes retornam 404 real" deve ser seguido — isso é correção HTTP, não SEO.

Cinco Princípios Fundamentais

Toda entrada é não confiável: URL, query, body, header, cookie, arquivo enviado, Webhook, fila de mensagens, valores de retorno de API de terceiros, até dados históricos corrompidos no banco de dados.
Padrão negar (fail closed): Em caso de erro de autenticação/validação/parse, negar, não permitir; caminhos de exceção não devem levar a ramificações que "pulem a validação".
Menor privilégio: Contas de banco de dados com permissões separadas por função (leitura/escrita separadas, sem DDL), IAM da nuvem/armazenamento de objetos autorizado por prefixo, processos não root, sistema de arquivos somente leitura em contêineres.
Defesa em profundidade: Se uma camada falhar, a próxima ainda está presente. Validação no frontend é para experiência, validação no servidor é segurança; WAF é uma rede de segurança, não um substituto.
Limitar o raio da explosão: 0days não podem ser eliminados por boas práticas de código, mas sim minimizando danos com isolamento, limitação de privilégios, lista branca de saída e canal rápido de patches.

Lista Vermelha (Obrigatório, Verificar Item por Item)

Autenticação e Sessão

Senhas com hash Argon2id/bcrypt(cost≥12)/scrypt; proibir MD5/SHA1/criptografia reversível
Falhas de login com rate limiting bidimensional (conta + IP), atraso progressivo, CAPTCHA/bloqueio temporário se necessário
Texto de resposta e tempo de execução consistentes para login/registro/recuperação de senha; não revelar se a conta existe
Após login bem-sucedido, rotacionar o ID da sessão (prevenir fixação de sessão); cookie com HttpOnly + Secure + SameSite
JWT com lista branca de algoritmos fixos no servidor; rejeitar alg:none e confusão de algoritmos; curta duração + rotação de refresh + capacidade de revogação
Autenticação ≠ Autorização: cada endpoint deve verificar explicitamente se o usuário atual pode operar no objeto (prevenir IDOR/elevação de privilégio)

Injeção e Saída

Todas as consultas SQL com consultas parametrizadas/vinculação ORM; proibir concatenação de strings; nomes de tabela/campos de ordenação com mapeamento de lista branca
Proibir concatenar entrada do usuário em shell/comando; usar funções execFile com array de parâmetros
Saída codificada conforme o contexto; dangerouslySetInnerHTML/v-html/innerHTML devem passar por sanitizador como DOMPurify
Rich text, Markdown, parâmetros de URL devem ser sempre de lista branca; não confiar em nenhuma filtragem no frontend
Requisições de saída (SSRF) com lista branca; proibir seguir redirecionamentos arbitrários; bloquear endereços de intranet/metadados (169.254.169.254, 127.0.0.1, 10/8, 172.16/12, 192.168/16, ::1, file://, gopher://)
Caminhos de arquivo validar prefixo após path.resolve; rejeitar ..; uploads com nome aleatório, detecção de tipo, armazenamento isolado, sem permissão de execução

Dados e Concorrência

Operações de escrita críticas idempotentes (índice único / chave de idempotência); pedidos, pagamentos, callbacks devem ser idempotentes
Campos de estoque, saldo, contagem com atualização condicional UPDATE ... WHERE saldo >= ?; proibir consultar primeiro e depois alterar
Transações curtas; dentro de transações, proibir chamadas de rede, envio de mensagens, renderização de templates
Novas consultas devem ter EXPLAIN; proibir paginação com OFFSET grande, SELECT *, consultas N+1
Valores monetários em centavos (inteiros) ou DECIMAL; proibir float/double

Assíncrono e Estabilidade

Todas as chamadas externas (HTTP/DB/Redis/MQ) com timeout explícito; proibir espera infinita
Retry apenas para operações idempotentes; com backoff exponencial + jitter + limite de tentativas
Consumo de mensagens idempotente (tabela de dedup message_id); falhas vão para fila de mensagens mortas com alerta
Alterações de estado crítico: persistir no banco antes de enviar mensagem (Outbox/transação de mensagem); proibir escrita dupla

Lógica de Negócio e Condições de Corrida (Mais Frequentemente Esquecido)

Preços, valores, descontos, níveis de permissão sempre calculados no servidor; valores enviados pelo cliente são apenas para exibição
Cupons/códigos de troca/códigos de convite vinculados ao usuário e à contagem; consumir atomicamente (atualização condicional ou restrição única)
Máquina de estados com validação explícita: transições ilegais rejeitadas diretamente (ex.: pending ignorar callback de pagamento e ir direto para paid)
Endpoints financeiros/de callback validar assinatura + timestamp + chave de idempotência; prevenir replay e falsificação
Limitação de compra/rate limiting combinando "usuário + dispositivo + IP"; não apenas uma das dimensões
Endpoints de exportação, lote, pesquisa com rate limiting + limite de volume de dados + auditoria

Chaves e Operações

Chaves apenas em variáveis de ambiente ou serviço de gerenciamento de chaves; proibir em repositório, camada de imagem, bundle do frontend, logs, relatórios de erro
Credenciais CI/CD com menor privilégio; implantação em produção requer aprovação; dependências de terceiros com versão bloqueada + varredura
Operações sensíveis (login, alteração de permissão, exportação, exclusão, reembolso) com log de auditoria; não alterável pelo código de negócio

Integridade da API (Prevenir Captura/Alteração de Pacotes / Replay / Falsificação de Resposta)

Requisições sensíveis (pagamento, financeiro, autorização, alteração de senha) com assinatura: HMAC(secret, method+path+sortedQuery+sha256(body)+timestamp+nonce), recalculado no servidor
Armazenamento de nonce com dedup (TTL = janela de tempo); janela de tempo ±300s; rejeitar expirados e replays
Respostas sensíveis (resultado de pagamento, resultado de autorização, saldo) com assinatura do servidor; cliente verifica; mas a verdade sempre está no servidor para reconsulta
Qualquer marcação "já validada", preço, papel enviado pelo cliente não é fonte de verdade; servidor recalcula/reconsulta
Mobile com certificate pinning; builds de release proibir confiança em certificados de usuário, proibir debug e chaves de captura de pacotes
Reforço do cliente (ofuscação/reforço/antidebug) apenas aumenta o custo, não é um limite de segurança; chaves não devem ser enviadas ao cliente

Aplicações de IA / LLM

Saída do modelo tratada como entrada não confiável: não eval, não concatenar diretamente em HTML/SQL/comando, não executar parâmetros de ferramenta diretamente
Ferramentas/chamadas de função com menor privilégio + validação de schema de parâmetros + ações de alto risco com confirmação humana
Documentos recuperados por RAG tratados como conteúdo não confiável, isolados do prompt do sistema; prevenir injeção indireta de prompt
Prompt do sistema separado da entrada do usuário; não colocar chaves, regras internas em locais que possam ser induzidos a saída
Rate limiting por usuário/inquilino para custo e frequência; logs com ofuscação de dados sensíveis (não registrar dados sensíveis do prompt completo)

Dispositivos Móveis / Miniprogramas

Dados sensíveis armazenados em Keychain (iOS) / Keystore (Android); não usar SharedPreferences em texto claro
Transporte forçar TLS + certificate pinning; InsecureSkipVerify/verify=False sempre proibidos
WebView desabilitar acesso a arquivos e exposição da ponte JS; onShouldStartLoadWithRequest com lista branca de domínios
session_key de miniprograma usada apenas no servidor; nunca enviada ao frontend; após code2session, emitir sessão própria
Detecção de root/jailbreak apenas como sinal de risco, não como base para autenticação

HTTP e Roteamento (Todos os Cenários)

Caminhos inexistentes retornar HTTP 404 real + página 404; proibir redirecionamento 302/200 para a página inicial
Fallback de history para SPA apenas para "rotas de frontend conhecidas"; /api e recursos estáticos com extensão sempre retornar 404
CORS com lista branca de Origins exata; proibir Access-Control-Allow-Origin: * com credentials; proibir reflexão de Origin arbitrária
Produção com cabeçalhos de segurança: HSTS, CSP, X-Content-Type-Options, Referrer-Policy, frame-ancestors
Respostas de autenticação/endpoints sensíveis com Cache-Control: no-store
Respostas de erro não retornar stack trace, SQL, versão do framework, caminhos internos

Indexação (Apenas Sites Públicos; Painéis/Sistemas Internos Fazem o Oposto)

Sites públicos: sitemap apenas com páginas 200, canonical para dedup, robots não revelar caminhos de admin, ambiente de staging com noindex completo
Painéis/sistemas internos/pessoais: site inteiro com X-Robots-Tag: noindex + robots Disallow: /; não gerar sitemap; e exigir autenticação (robots não é controle de acesso)

Fase Um: Durante o Design

Antes de começar, gaste 5 minutos em uma modelagem de ameaças leve:

Definir o cenário: Consulte a tabela de tipos de projeto acima, confirme se é site público, painel administrativo, sistema interno ou API; decida se a seção de SEO se aplica e qual a superfície de exposição.
Desenhar o fluxo de dados: Usuário → Gateway → Serviço → Banco de dados/Cache/MQ/Terceiros, marque cada ponto onde a confiança é atravessada.
Listar ativos e classificá-los: Contas, credenciais, pagamento, dados pessoais, painel administrativo; pergunte "quem pode ler, quem pode escrever, consequências de adulteração, por quanto tempo reter".
Em cada fronteira, fazer três perguntas: Quem pode alcançar? A entrada é validada? Em caso de falha, o padrão é negar?
Definir modelo de permissão: Papel → Recurso → Ação; impor no servidor; esconder botões no frontend não é suficiente; sistemas multi-inquilino exigem políticas de isolamento adicionais.
Definir fronteiras assíncronas: Quais operações devem ser síncronas (login, confirmação de pagamento), quais podem ser assíncronas (notificação, relatório, exportação).

O documento de design deve especificar no mínimo: tipo de projeto e estratégia de indexação, método de autenticação, modelo de autorização, classificação e criptografia de dados sensíveis, política de rate limiting, chaves de idempotência, modo de degradação em falha, escopo de log e auditoria.

Fase Dois: Durante a Implementação

Autenticação e Login (Maior Prioridade)

Login é o ponto de entrada mais sujeito a força bruta, credential stuffing e bypass. Regras completas em references/auth-and-session.md, o essencial intocável:

Rate limiting em camadas: IP único, conta única, impressão digital de dispositivo único; contagem de falhas com chaves Redis expiradas, não apenas em memória.
Mensagens de erro uniformes como "Usuário ou senha inválidos"; tempo de execução consistente (mesmo para contas inexistentes, executar um hash falso para evitar enumeração temporal).
Após login bem-sucedido, gerar novo identificador de sessão; invalidar sessões antigas.
Operações sensíveis (alterar senha, alterar vínculo, saque, exclusão) exigir verificação secundária ou timestamp da última autenticação (janela de reautenticação).
Token de redefinição de senha: alta entropia, uso único, curta duração (≤15 minutos), vinculado ao usuário e à ação.
Painel administrativo com entrada independente, domínio ou lista branca de IPs separados; não compartilhar sessão com o frontend do usuário.

Entrada, Injeção e Saída

Consulte references/web-vulnerability-prevention.md. Princípio: Validação unificada na entrada (schema), codificação por contexto na saída.

// Entrada: validar com schema, rejeitar campos desconhecidos, não "pegar apenas o necessário"
const LoginBody = z.object({ email: z.string().email(), password: z.string().min(8).max(128) }).strict();

// SQL: parametrizado, nunca concatenar
await db.query('SELECT id, password_hash FROM users WHERE email = $1', [email]);
// Para posições que não podem ser parametrizadas (ordenação, nomes de tabela): lista branca
const orderBy = { created_at: 'created_at', amount: 'amount_cents' }[sort] ?? 'created_at';

XSS: escape padrão do React/Vue é suficiente; APIs perigosas devem sanitizar; CSP como segunda linha de defesa.
Elevação de privilégio: incluir owner_id = $currentUser na condição da consulta; não "consultar e verificar no frontend".
Desserialização/injeção de template: não eval, não concatenar entrada do usuário em templates/expressões/regex.
Upload: limitar tamanho e tipo (detecção por magic bytes), nome de arquivo aleatório, armazenamento em objeto, recompressão de imagem.

Banco de Dados e Alta Concorrência

Consulte references/database-concurrency.md. Pontos-chave:

Índice antes da otimização: antes de uma nova consulta ir ao ar, EXPLAIN; ficar atento a type=ALL, filesort, tabelas temporárias.
Paginação com cursor (keyset), não usar OFFSET profundo; endpoints de listagem devem ter ordenação estável + limite.
Escrita em pontos quentes com "atualização condicional + lock de linha", exemplo de dedução de estoque:

UPDATE sku SET stock = stock - $1, version = version + 1
WHERE id = $2 AND stock >= $1;
-- Se linhas afetadas = 0 → estoque insuficiente ou conflito de concorrência, tentar novamente ou falhar conforme o negócio

Três problemas de cache: prevenir penetração (cache de valor nulo/filtro Bloom), prevenir colapso (lock de exclusão mútua/singleflight), prevenir avalanche (TTL com jitter aleatório).
Limite máximo do pool de conexões deve ser menor que max_connections do banco de dados / número de instâncias; configurar timeout de obtenção.
Escalar com sharding de banco/tabela só quando necessário; primeiro fazer índices, cache, separação leitura/escrita, separação quente/frio.

Lógica de Negócio e Condições de Corrida

Consulte references/business-logic-and-race-conditions.md. Esse tipo de vulnerabilidade não tem scanner universal; só pode ser tratada pensando item por item durante o design: preços e valores calculados no servidor, cupons consumidos atomicamente, validação de máquina de estados, prevenção de replay, dimensões de limitação de compra, rate limiting de exportação. "Consultar primeiro e depois alterar" em cenários concorrentes deve ser sempre substituído por atualização condicional ou lock + idempotência.

Arquitetura Assíncrona por Padrão

Consulte references/async-architecture.md. O sistema é projetado como assíncrono por padrão:

IO sempre não bloqueante; em Node, proibir fs/crypto síncrono e computação pesada no caminho da requisição (usar worker_threads).
Toda chamada externa deve ter timeout; propagar trace id na cadeia de chamadas.
Consumo de fila = pelo menos uma entrega, portanto deve ser idempotente; retry com limite, exceder vai para DLQ com alerta.
Consistência entre serviços com Outbox/CDC, não escrita dupla.
Tarefas longas (exportação, lote, revisão) vão para a fila; endpoint retorna imediatamente o ID da tarefa; frontend faz polling ou SSE para status.
Desligamento gracioso: parar de aceitar novas requisições → aguardar as em andamento → parar consumidores de fila → fechar conexões.

HTTP, Roteamento, CORS e SEO

Consulte references/http-routing-cors-seo.md. Três mais fáceis de errar:

404 deve ser 404. Não faça fallback global para a página inicial: SPA só deve cair para index.html para rotas conhecidas em tempo de build; /api/* e caminhos com extensão devem retornar 404 diretamente.
CORS com lista branca exata, comparando Origin com o item de configuração como conjunto igual; não includes, não correspondência de prefixo, não ecoar diretamente o cabeçalho da requisição.
Códigos de status semanticamente corretos: 401 não autenticado, 403 sem permissão, 404 não existe, 409 conflito, 422 falha de validação, 429 rate limited.

SEO se aplica apenas a sites públicos; painéis e sistemas internos seguem a tabela de cenários acima com "proibida indexação"; não adicione sitemap, canonical, dados estruturados a eles — isso aumenta a superfície de ataque para crawlers.

Chaves, Operações e Email

Consulte references/operations-and-secrets.md. Pontos-chave: chaves armazenadas em camadas com rotação, CI/CD com menor privilégio, contêineres não root, armazenamento de objetos e IAM da nuvem minimizados, logs de auditoria inalteráveis, domínio de email configurado com SPF/DKIM/DMARC para prevenir falsificação, políticas de retenção e exclusão de dados.

Integridade da API e Antimanipulação

Consulte references/api-integrity-and-tampering.md. Captura e alteração de pacotes e replay são os principais problemas para dispositivos móveis e APIs abertas: assinatura de requisição (HMAC + timestamp + nonce + hash do body), recálculo no servidor, assinatura de respostas sensíveis, dedup de nonce, janela de tempo, certificate pinning. Lembre-se: tudo que o cliente pode alterar é não confiável; assinatura apenas aumenta o custo, o servidor recalculando é a verdade.

Segurança para Aplicações de IA / LLM

Consulte references/ai-llm-security.md. Saída do modelo é equivalente a entrada externa: não executar, não concatenar diretamente, não usar como SQL/comando; chamadas de ferramenta com menor privilégio + validação de schema + ações de alto risco com confirmação humana; conteúdo RAG não confiável; rate limiting por inquilino para controlar custo.

Dispositivos Móveis e Miniprogramas

Consulte references/mobile-and-miniprogram.md. Keychain/Keystore, certificate pinning, reforço de WebView, session_key de miniprograma não enviado ao cliente, detecção de root apenas como sinal.

Fase Três: Revisão Pré-Lançamento

Percorra na ordem; qualquer item com "incerto" deve ser tratado como não aprovado:

Lista Vermelha 100% verificada; verifique por tipo de projeto: site público → itens de SEO; painel/sistema interno → noindex e isolamento de entrada; negócios sensíveis → integridade da API.
Execute python scripts/scan_redlines.py <diretório> --fail-on high; críticos devem ser zerados.
Varredura de dependências (npm audit / pip-audit / govulncheck / OWASP Dependency-Check); críticos devem ser tratados.
Verificação de chaves: repositório, imagens, logs, bundle do frontend não devem conter chaves; .env não entra no controle de versão; logs de CI também devem ser verificados.
Contêiner/host: não root, sistema de arquivos raiz somente leitura, exposição mínima de portas, lista branca de saída.
Monitoramento e alertas: taxa de falha de login, 5xx, acúmulo em filas, consultas lentas, requisições de saída anômalas.
Teste de backup e recuperação; contas de banco de dados com menor privilégio.
Teste de stress em caminhos críticos (login, pedido, listagem) para confirmar rate limiting e cache em vigor.
Domínio de email: SPF/DKIM/DMARC configurados, rate limiting em endpoints de envio, para evitar ser usado para phishing ou como fonte de spam.
Ciclo de vida dos dados: definir coleta mínima, período de retenção, processo de exportação e exclusão; logs ofuscados antes da retenção.
Plano de resposta a incidentes de segurança: quem é responsável, como isolar, como notificar usuários, como fazer post-mortem.
Mapeamento de conformidade (se necessário): consultar references/compliance-mapping.md para verificar itens OWASP/ASVS/classificação de segurança (etc.)/PIPL.

Fase Quatro: Tempo de Execução e Mitigação de 0day

Boas práticas de código não impedem vulnerabilidades desconhecidas; mitigue o impacto com:

Saída padrão negada + lista branca (primeira barreira contra SSRF e callback de supply chain).
Serviços críticos em sandbox/isolamento de contêiner, processo com privilégios reduzidos, seccomp/AppArmor sob demanda.
Dependências com versão bloqueada + capacidade de reconstrução rápida de imagem; monitorar avisos de segurança, reservar canal de patch de emergência.
WAF/gateway para bloqueio de características genéricas e rate limiting, mas não confiar apenas nisso.
Monitoramento de comportamento: saltos geográficos/de dispositivos em login anômalo, leitura/escrita em lote, tráfego de saída anômalo.
Classificação de dados: campos sensíveis criptografados em repouso (AES-GCM/KMS), logs ofuscados, exportação requer aprovação.

Índice de Referências

Arquivo	Quando Ler
`references/auth-and-session.md`	Login, registro, senha, JWT, 2FA, recuperação de senha, CSRF, elevação de privilégio, painel administrativo
`references/web-vulnerability-prevention.md`	SQL injection, XSS, SSRF, upload, path traversal, desserialização, cabeçalhos de resposta, riscos específicos de API
`references/business-logic-and-race-conditions.md`	Preços/valores, cupons, estoque, máquina de estados, condição de corrida TOCTOU, limitação de compra, abuso de exportação
`references/database-concurrency.md`	Criação de tabelas, índices, transações, locks, idempotência, cache, separação leitura/escrita, sharding de banco/tabela
`references/async-architecture.md`	Timeout, retry, consumo de fila, Outbox, backpressure, desligamento gracioso, observabilidade
`references/http-routing-cors-seo.md`	404, códigos de status, CORS, cache, robots/sitemap, separação de indexação para site público e painel
`references/operations-and-secrets.md`	Chaves, CI/CD, contêiner/nuvem, domínio de email, logs de auditoria, ciclo de vida de dados, resposta a incidentes
`references/api-integrity-and-tampering.md`	Captura/alteração de pacotes, assinatura de requisição/resposta, prevenção de replay, certificate pinning, limites de reforço do cliente
`references/ai-llm-security.md`	Injeção de prompt, permissões de chamada de ferramenta, envenenamento de RAG, tratamento de saída do modelo, rate limiting de custo
`references/mobile-and-miniprogram.md`	Armazenamento local, certificate pinning, WebView, estado de login de miniprograma, detecção de root
`references/compliance-mapping.md`	Correspondência para OWASP Top 10 / ASVS / Classificação de Segurança da Informação (etc.) / PIPL, para auditoria ou apresentação de revisão
`references/internal-policy.example.md`	Quando precisar de um modelo personalizado de proibição de ativos (domínios placeholder, sem endereços reais)

Acordo de Entrega

Toda vez que entregar código, na resposta, explique com 3–6 linhas as decisões de segurança envolvidas (pontos de validação, pontos de autenticação, chave de idempotência, rate limiting, tratamento de erro). Não pule.
Primeiro, especifique o tipo de projeto: se a entrega for para um painel ou sistema interno, indique claramente "sem SEO, noindex em todo o site"; apenas sites públicos incluirão configurações de indexação.
Ao encontrar código existente violando a Lista Vermelha, aponte diretamente a localização e forneça a correção; não diga apenas "recomendo reforçar".
Para partes que não podem ser verificadas (por exemplo, não realizou testes de ataque reais), escreva explicitamente "não verificado"; não afirme que passou nos testes de segurança.

bucai2417/secure-system-development

O que é secure-system-development?

Perguntar na sua IA favorita

Documentação