Suporte upstream incluído

Arquivos de suporte são incluídos em caminhos relativos à skill. Veja UPSTREAM-NOTICE.md para suas fontes fixadas, licenças, hashes e alterações de importação.

name: sharp-edges description: "Identifica APIs propensas a erros, configurações perigosas e designs que facilitam erros de segurança. Use ao revisar designs de API, esquemas de configuração, ergonomia de bibliotecas criptográficas ou ao avaliar se o código segue 'seguro por..."

Análise de Bordas Afiadas

Avalia se APIs, configurações e interfaces são resistentes ao uso indevido por desenvolvedores. Identifica designs onde o "caminho fácil" leva à insegurança.

Quando Usar

• Revisando decisões de design de API ou biblioteca
• Auditando esquemas de configuração para opções perigosas
• Avaliando a ergonomia de APIs criptográficas
• Avaliando interfaces de autenticação/autorização
• Revisando qualquer código que exponha escolhas relevantes para segurança aos desenvolvedores

Quando NÃO Usar

• Bugs de implementação (use revisão de código padrão)
• Falhas na lógica de negócios (use análise específica do domínio)
• Otimização de desempenho (preocupação diferente)

Princípio Central

O fosso do sucesso: O uso seguro deve ser o caminho de menor resistência. Se os desenvolvedores precisam entender criptografia, ler a documentação cuidadosamente ou lembrar regras especiais para evitar vulnerabilidades, a API falhou.

Racionalizações a Rejeitar

Categorias de Bordas Afiadas

1. Armadilhas na Seleção de Algoritmo/Modo

APIs que permitem aos desenvolvedores escolher algoritmos convidam à escolha errada.

O Padrão JWT (exemplo canônico):

• Cabeçalho especifica algoritmo: o atacante pode definir "alg": "none" para ignorar assinaturas
• Confusão de algoritmo: chave pública RSA usada como segredo HMAC ao mudar de RS256 para HS256
• Causa raiz: Permitir que entrada não confiável controle decisões críticas de segurança

Padrões de detecção:

• Parâmetros de função como algorithm, mode, cipher, hash_type
• Enums/strings selecionando primitivas criptográficas
• Opções de configuração para mecanismos de segurança

Exemplo - PHP password_hash permitindo algoritmos fracos:

// DANGEROUS: allows crc32, md5, sha1
password_hash($password, PASSWORD_DEFAULT); // Good - no choice
hash($algorithm, $password); // BAD: accepts "crc32"

2. Padrões Perigosos

Padrões que são inseguros, ou valores zero/vazios que desativam a segurança.

O Padrão de Tempo de Vida do OTP:

# What happens when lifetime=0?
def verify_otp(code, lifetime=300):  # 300 seconds default
    if lifetime == 0:
        return True  # OOPS: 0 means "accept all"?
        # Or does it mean "expired immediately"?

Padrões de detecção:

• Timeouts/tempos de vida que aceitam 0 (infinito? expiração imediata?)
• Strings vazias que ignoram verificações
• Valores nulos que pulam a validação
• Padrões booleanos que desativam recursos de segurança
• Valores negativos com semântica indefinida

Perguntas a fazer:

• O que acontece com timeout=0? max_attempts=0? key=""?
• O padrão é a opção mais segura?
• Algum valor padrão pode desativar completamente a segurança?

3. APIs Primitivas vs. Semânticas

APIs que expõem bytes brutos em vez de tipos significativos convidam à confusão de tipos.

O Padrão Libsodium vs. Halite:

// Libsodium (primitives): bytes are bytes
sodium_crypto_box($message, $nonce, $keypair);
// Easy to: swap nonce/keypair, reuse nonces, use wrong key type

// Halite (semantic): types enforce correct usage
Crypto::seal($message, new EncryptionPublicKey($key));
// Wrong key type = type error, not silent failure

Padrões de detecção:

…