Por padrão, as instâncias do Amazon RDS não são criptografadas. Isso expõe os dados a um possível roubo e acesso não autorizado.

"Resources": {
    "RDSDBExample": {
        "Type": "AWS::RDS::DBInstance",
        "Properties": {
            "StorageEncrypted": false,
            "DBName": "Test DB",
            "DBInstanceClass": "db.m4.large"
        }
    }
}

Por padrão, os clusters do Amazon Redshift não são criptografados. Isso expõe os dados a acesso não autorizado e possível roubo.

Exemplo 1: O modelo a seguir define um cluster Redshift sem criptografia habilitada.

"Resources": {
    "RedshiftClusterTest": {
        "Type": "AWS::Redshift::Cluster",
        "Properties": {
            "DBName": "mydb",
            "MasterUsername": "master",
            "MasterUserPassword": "masterPass",
            "NodeType": "ds2.xlarge",
            "ClusterType": "single-node",
        }
    }

Um bucket do Amazon S3 é criado sem criptografia no lado do servidor. A criptografia atenua as violações de dados tornando os dados ilegíveis para qualquer pessoa sem as credenciais adequadas. Como tal, a criptografia em repouso é uma medida para atender a alguns requisitos de conformidade industrial e governamental, como GDPR, HIPAA e PCI.

Por padrão, os tópicos SNS não são criptografados em repouso. Isso expõe, possivelmente, os dados a visualizadores não autorizados.

Exemplo 1: O modelo de exemplo a seguir falha ao criptografar o tópico SNS ao negligenciar a definição de um identificador de chave AWS KMS.

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Description": "My SNS topic",
    "Resources": {
        "MySNSTopic": {
            "Type": "AWS::SNS::Topic",
            "Properties": {
                "Subscription": [
                    {
                        "Endpoint": "MySNSEndpoint",
                        "Protocol": "sqs"
                    }
                ],
                "TopicName": "MyTopic"
            }
        }
    }
}

A autenticação baseada em ID de toque pode ser implementada usando os serviços de conjunto de chaves armazenando um item no conjunto de chaves e definindo um controle de acesso que requer que o usuário use sua impressão digital para recuperar o item posteriormente. As seguintes políticas podem ser usadas para definir como o usuário será autenticado usando sua impressão digital:

- kSecAccessControlUserPresence: Restrição para acessar usando a ID de toque ou a senha. A ID de toque não precisa estar disponível ou registrada. O item ainda estará acessível pela ID de toque, mesmo se as impressões digitais forem adicionadas ou removidas.
- kSecAccessControlTouchIDAny: Restrição para acessar usando a ID de toque para quaisquer impressões digitais registradas. O item não será invalidado se as impressões digitais forem adicionadas ou removidas.
- kSecAccessControlTouchIDCurrentSet: Restrição para acessar usando a ID de toque para as impressões digitais registradas no momento. O item será invalidado se as impressões digitais forem adicionadas ou removidas.

Ao usar a ID de toque, você deve usar o atributo kSecAccessControlTouchIDCurrentSet para proteger contra a adição ou remoção de impressões digitais no futuro.

Exemplo 1: O seguinte código usa a restrição kSecAccessControlTouchIDAny que permite que todas as impressões digitais cadastradas no futuro desbloqueiem o item de conjunto de chaves:

    ...
    SecAccessControlRef sacRef = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
                 kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
                 kSecAccessControlTouchIDCurrentSet, 
                 nil);
    NSMutableDictionary *dict = [NSMutableDictionary dictionary];
    [dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
    [dict setObject:account forKey:(__bridge id)kSecAttrAccount];
    [dict setObject:service forKey:(__bridge id) kSecAttrService];
    [dict setObject:token forKey:(__bridge id)kSecValueData];
    ...
    [dict setObject:sacRef forKey:(__bridge id)kSecAttrAccessControl];
    [dict setObject:@"Please authenticate using the Touch ID sensor." forKey:(__bridge id)kSecUseOperationPrompt];

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        OSStatus status = SecItemAdd((__bridge CFDictionaryRef)dict, nil);
    });
    ...

É prática comum processar a saída dos valores de variáveis para fins depuração ou teste com um código que não se destina a ser distribuído ou permanecer ativo no aplicativo implantado. Quando esse tipo de código de depuração é acidentalmente deixado no aplicativo, este pode fornecer informações para um invasor de maneiras inesperadas. Nem todas as instruções de depuração deixam vazar informações confidenciais ou privadas. No entanto, a presença de uma instrução de depuração muitas vezes indica que o código circundante foi negligenciado e pode estar em mau estado de conservação.

O exemplo mais comum de código de depuração esquecido no ColdFusion é a tag <cfdump>. Embora o uso de <cfdump> seja aceitável durante o desenvolvimento do produto, os desenvolvedores responsáveis pelo código que faz parte de um aplicativo Web de produção deve considerar cuidadosamente se qualquer uso da tag <cfdump> deve ser permitido.

As vulnerabilidades de script entre estruturas ocorrem quando um aplicativo:

1. Permite a própria inclusão em um iframe.
2. Falha em especificar a política de estruturação por meio do cabeçalho X-Frame-Options.
3. Usa proteção fraca, como a lógica de redução de estrutura baseada em JavaScript.

Vulnerabilidades de geração de scripts entre quadros muitas vezes formam a base de explorações do tipo clickjacking, que os invasores podem usar para conduzir uma falsificação de solicitações entre sites ou ataques de phishing.