By default, Amazon RDS instances are not encrypted. This exposes the data to potential theft and unauthorized access.

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

By default, Amazon Redshift clusters are not encrypted. This exposes the data to unauthorized access and potential theft.

Example 1: The following template defines a Redshift cluster with no encryption enabled.

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

An Amazon S3 bucket is created without server-side encryption. Encryption mitigates data breaches by making data unreadable to anyone without the proper credentials. As such, encryption at rest is a measure to meet some industrial and government compliance requirements such as GDPR, HIPAA, and PCI.

By default, SNS topics are not encrypted at rest. This potentially exposes the data to unauthorized viewers.

Example 1: The following example template fails to encrypt the SNS topic by neglecting to define an AWS KMS key identifier.

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

Touch ID based authentication can be implemented using the Keychain services by storing an item in the Keychain and setting an access control which requires the user to use their fingerprint to retrieve the item at a later time. The following policies can be used to define how the user will be authenticated using his fingerprint:

- kSecAccessControlUserPresence: Constraint to access with either Touch ID or passcode. Touch ID does not have to be available or enrolled. Item is still accessible by Touch ID even if fingerprints are added or removed.
- kSecAccessControlTouchIDAny: Constraint to access with Touch ID for any enrolled fingerprints. Item is not invalidated if fingerprints are added or removed.
- kSecAccessControlTouchIDCurrentSet: Constraint to access with Touch ID for currently enrolled fingerprints. Item is invalidated if fingerprints are added or removed.

When using Touch ID you should use the kSecAccessControlTouchIDCurrentSet attribute to protect against fingerprints being added or removed in the future.

Example 1: The following code uses the kSecAccessControlTouchIDAny constraint that allows any future-enrolled fingerprint to unlock the Keychain item:

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

It is common practice to output the values of variables for debugging or testing purposes with code that is not intended to be shipped or remain active in the deployed application. When this sort of debug code is accidentally left in the application, the application may provide information to an attacker in unintended ways. Not all debugging statements leak sensitive or private information. However, the presence of a debugging statement often indicates that the surrounding code has been neglected and may be in a state of disrepair.

The most common example of forgotten debug code in ColdFusion is the <cfdump> tag. Although use of <cfdump> is a acceptable during product development, developers responsible for code that is part of a production web application should carefully consider whether any use of the <cfdump> tag should be allowed.

Cross-frame scripting vulnerabilities occur when an application:

1. Allows itself to be included inside an iframe.
2. Fails to specify framing policy via the X-Frame-Options header.
3. Uses poor protection, such as JavaScript-based frame busting logic.

Cross-frame scripting vulnerabilities often form the basis of clickjacking exploits that attackers may use to conduct cross-site request forgery or phishing attacks.