De forma predeterminada, las instancias de RDS de Amazon no están cifradas. Esto expone los datos a posible robo y acceso no autorizados.

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

De forma predeterminada, los clústeres de Amazon Redshift no están cifrados. Esto expone los datos al acceso no autorizado y posible robo.

Ejemplo 1: La siguiente plantilla define un clúster de Redshift sin cifrado habilitado.

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

Se crea un contenedor de Amazon S3 sin cifrado del lado del servidor. El cifrado mitiga las vulneraciones de datos al hacer que los datos sean ilegibles para cualquier persona sin las credenciales adecuadas. Como tal, el cifrado en reposo es una medida para cumplir con algunos requisitos de cumplimiento industriales y gubernamentales, como RGPD, HIPAA y PCI.

De forma predeterminada, los temas de SNS no están cifrados en reposo. Esto potencialmente expone los datos a espectadores no autorizados.

Ejemplo 1: La siguiente plantilla de ejemplo no puede cifrar el tema de SNS al no definir un identificador de clave de AWS KMS.

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

La autenticación basada en Touch ID puede implementarse con los servicios de llaves mediante el almacenamiento de un elemento en las llaves y la configuración de un control de accesos que requiera que el usuario utilice su huella digital para recuperar el elemento más tarde. Las siguientes directivas pueden usarse para definir cómo se autenticará al usuario con su huella digital:

- kSecAccessControlUserPresence: restricción de acceso con Touch ID o un código de acceso. No es necesario que Touch ID esté disponible o registrado. Touch ID puede tener acceso al elemento aunque se agreguen o eliminen huellas digitales.
- kSecAccessControlTouchIDAny: restricción de acceso con Touch ID para las huellas digitales registradas. No se invalida el elemento si se agregan o eliminan huellas digitales.
- kSecAccessControlTouchIDCurrentSet: restricción de acceso con Touch ID para las huellas digitales registradas actualmente. Se invalida el elemento si se agregan o eliminan huellas digitales.

Cuando usa Touch ID, debe utilizar el atributo kSecAccessControlTouchIDCurrentSet para impedir que se agreguen o eliminen huellas digitales en el futuro.

Ejemplo 1: el siguiente código usa la restricción kSecAccessControlTouchIDAny que permite que el elemento de las llaves se desbloquee con cualquier huella digital que se registre en el futuro:

    ...
    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);
    });
    ...

Es muy común generar valores de variables para depurar o realizar pruebas con el código que no se pretende enviar ni permanecer activo en la aplicación implementada. Cuando este tipo de código de depuración se deja accidentalmente en la aplicación, esta puede proporcionar información a un usuario malintencionado de forma no deseada. No todas las instrucciones de depuración pierden información confidencial o privada. Sin embargo, la presencia de una instrucción de depuración suele indicar que el código que lo rodea ha quedado desatendido y puede estar en un estado de deterioro.

El ejemplo de código de depuración olvidado en ColdFusion más común es la etiqueta <cfdump>. Aunque el uso de <cfdump> es aceptable durante el desarrollo del producto, los desarrolladores responsables del código que forma parte de una aplicación web de producción deben considerar cuidadosamente si se debe permitir el uso de la etiqueta <cfdump>.

Las vulnerabilidades de Cross-Site Scripting ocurren cuando una aplicación:

1. Permite que se incluya en un iframe.
2. No puede especificar la directiva de marcos a través del encabezado X-Frame-Options.
3. Utiliza protección deficiente, como lógica de reducción de marcos de JavaScript.

Las vulnerabilidades de Cross-Site Scripting con frecuencia forman la base de ataques de clickjacking que los atacantes pueden utilizar para realizar falsificación de solicitud entre sitios o ataques de suplantación de identidad.