APIs only intended for debug purposes are used.

By default, task flows in a Fusion application are not directly accessible from a GET request: whenever a URL attempts to invoke the task flow, it receives an HTTP 403 status code. However, relying on an implicit setting always lacks clarity and can potentially lead to unwanted behavior if the default setting changes underneath.

Example 1: The following snippet from a task flow definition file shows an example of a task flow configured with the implicit default url-invoke-disallowed setting.

...
    <task-flow-definition id="password">
        <default-activity>PasswordPrompt</default-activity>
        <view id="PasswordPrompt">
            <page>/PasswordPrompt.jsff</page>
        </view>
        <use-page-fragments/>
    </task-flow-definition>
...

Storing encryption keys in static class fields allows easy recovery by an entity that can access the process memory (e.g. rooted device) or process memory dumps (e.g. crash dumps).

A common development practice is to add "back door" code specifically designed for debugging or testing purposes that is not intended to be shipped or deployed with the application. When this sort of debug code is accidentally left in the application, the application is open to unintended modes of interaction. These back door entry points create security risks because they are not considered during design or testing and fall outside of the expected operating conditions of the application.

By default, EBS volumes are not encrypted.
Example 1: The following example template exposes the data to potential theft and unauthorized access.

	Resources:
  	  EBSVOLExample:
    	Type: AWS::EC2::Volume
    	Properties:
      	  Encrypted: false
	

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

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

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

AWS API Gateway methods that are publicly accessible can expose the organization to attack.

Example 1: The following example template defines publicly accessible AWS API Gateway methods.

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Resources": {
        "MyMethod0": {
            "Type": "AWS::ApiGateway::Method",
            "Properties": {
                "RestApiId": "MyAPIID",
                "ResourceId": "MyResourceID",
                "HttpMethod": "GET",
                "AuthorizationType": "NONE"
            }
        },
        "MyMethod1": {
            "Type": "AWS::ApiGateway::Method",
            "Properties": {
                "RestApiId": "MyAPIID",
                "ResourceId": "MyResourceID",
                "HttpMethod": "POST",
                "AuthorizationType": "NONE",
                "ApiKeyRequired": false
            }
        }
    }
}

A wildcard configuration for lambda principals violates the least privilege principle and allows an attacker to invoke the lambda from any account.

Example 1: The following example template defines a wildcard lambda principal.

{
    "Resources": {
        "LambdaPerm": {
            "Type": "AWS::Lambda::Permission",
            "Properties": {
            "SourceAccount": "AWS::AccountId",
            "SourceArn": "bucket.Arn",
            "FunctionName": "function.Arn",
            "Action": "lambda:InvokeFunction",
            "Principal": "*"
            }
        }
    },
    "AWSTemplateFormatVersion": "2010-09-09",
    "Description": "Lambda Permission"
}

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

Example 1: The following example shows a template that defines an Amazon DocumentDB with encryption disabled.

"Resources": {
    "DocDBDefault": {
        "Type": "AWS::DocDB::DBCluster",
        "Properties": {
            "MasterUsername": "name",
            "MasterUserPassword": "password"
        }
    }

By default, EBS volumes are not encrypted.
Example 1: The following example template exposes the data to potential theft and unauthorized access.

"Resources": {
    "EBSVOLExample": {
        "Type": "AWS::EC2::Volume",
        "Properties": {
            "Encrypted": false,
        }
    }
}

By default, Amazon ElastiCache Replication Groups are not encrypted. This exposes the data to unauthorized access and potential theft.

Example 1: The following example template defines an Amazon ElastiCache Replication Group with encryption disabled.

{
    "Description": "ElastiCache redis",
    "Resources": {
        "MyReplicationGroup": {
            "Type": "AWS::ElastiCache::ReplicationGroup",
            "Properties": {
                "AutomaticFailoverEnabled": true,
                "CacheNodeType": {
                    "Ref": "CacheNodeType"
                },
                Cache  "ParameterGroupName": {
                    "Ref": "CacheParameterGroup"
                },
                "CacheSubnetGroupName": {
                    "Ref": "CacheSubnetGroupName"
                },
                "Engine": "redis",
                "EngineVersion": {
                    "Ref": "EngineVersion"
                },
                "NumNodeGroups": {
                    "Ref": "NumShards"
                },
                "ReplicasPerNodeGroup": {
                    "Ref": "NumReplicas"
                },
                "PreferredMaintenanceWindow": "sat:10:00-sat:08:00",
                "SecurityGroupIds": [
                    {
                        "Ref": "SecurityGroup"
                    }
                ],
                "SnapshotRetentionLimit": {
                    "Ref": "SnapshotRetentionLimit"
                },
                "SnapshotWindow": "00:00-03:00"
            },
            "UpdatePolicy": {
                "UseOnlineResharding": true
            }
        }
    }
}

By default, Neptune DB clusters are not encrypted. This exposes the data to potential theft and unauthorized access by attackers.

Example 1: The following example template fails to enable encryption at rest.

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Description": "My Neptune DB cluster",
    "Resources": {
        "NeptuneDBCluster": {
            "Type": "AWS::Neptune::DBCluster",
            "Properties": {
                "BackupRetentionPeriod": 10,
                "DBClusterIdentifier": "MyDBClusterIdentifier",
                "DBClusterParameterGroupName": "MyNeptuneDBClusterParameterGroup",
                "DBSubnetGroupName": "MyNeptuneDBSubnetGroup",
                "IamAuthEnabled": true,
                "Port": 8080,
                "PreferredBackupWindow": "NeptuneDBClusterPreferredBackupWindow",
                "PreferredMaintenanceWindow": "NeptuneDBClusterPreferredMaintenanceWindow"
            }
        }
    }
}

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.