Hardcoding a password allows all project developers to view the password. It also makes fixing the problem difficult. After the code is in production, no one can change the password without patching the software. If the account protected by the password is compromised, the system's owners must choose between security and availability.

When creating an instance of NSURLCredential containing the user's credentials in the form or a username/password pair or a client certificate, a persistence attribute needs to be defined. The possible values are:

- NSURLCredentialPersistenceNone: Credential should not be stored.
- NSURLCredentialPersistenceForSession: Credential should be stored only for this session.
- NSURLCredentialPersistencePermanent: Credential should be stored in the Keychain.
- NSURLCredentialPersistenceSynchronizable: Credential should be stored permanently in the Keychain, and in addition should be distributed to other devices based on the owning AppleID.

Since NSURLCredentialPersistenceSynchronizable credentials are distributed to other devices and iCloud, failing to completely remove the credential from all places will leave instances that could be leaked.

Example 1: The following snippet of code creates a synchronizable credential, uses it and then removes it locally but fails to remove it from other devices and iCloud:

    ...
    // Create the credential
	NSURLCredential *credential = [NSURLCredential credentialWithUser:user password:password persistence:NSURLCredentialPersistenceSynchronizable]; 
    NSURLCredentialStorage *shared = [NSURLCredentialStorage sharedCredentialStorage];
    [shared setDefaultCredential:credential forProtectionSpace:protectionSpace]; 

    // Use the credential as needed
    ...

    // Removes the credential
    [shared removeCredential:credential forProtectionSpace:protectionSpace];
    ...

When creating an instance of NSURLCredential containing the user's credentials in the form or a username/password pair or a client certificate, a persistence attribute needs to be defined. The possible values are:

- NSURLCredentialPersistenceNone: Credential should not be stored.
- NSURLCredentialPersistenceForSession: Credential should be stored only for this session.
- NSURLCredentialPersistencePermanent: Credential should be stored in the Keychain.
- NSURLCredentialPersistenceSynchronizable: Credential should be stored permanently in the Keychain, and in addition should be distributed to other devices based on the owning Apple ID.

The NSURLCredentialPersistenceSynchronizable attribute implies the distribution of the credential and its storage in the Apple's cloud environment. Depending upon the privacy requirements of the application, storing the credential in the Apple cloud environment may not be acceptable.

Example 1: The following snippet of code creates a synchronizable credential that will be distributed to other devices and iCloud:

    ...
    NSURLCredential *credential = [NSURLCredential credentialWithUser:user password:password persistence:NSURLCredentialPersistenceSynchronizable]; 
    NSURLCredentialStorage *shared = [NSURLCredentialStorage sharedCredentialStorage];
    [shared setDefaultCredential:credential forProtectionSpace:protectionSpace]; 
    ...

Service account credentials are shared among controllers because the command to start the Kubernetes controller manager does not contain the --use-service-account-credentials=true flag. This flag instructs the controller manager to start each controller using a separate service account. When used in combination with role-based access control (RBAC), this ensures that each controller runs with the minimum permissions needed to perform its tasks.

Example 1: The following configuration starts a Kubernetes controller manager without the --use-service-account-credentials flag.

apiVersion: v1
kind: Pod
...
spec:
  containers:
    - command:
        - /usr/local/bin/kube-controller-manager
    image: k8s.gcr.io/kube-controller-manager:v1.9.7
...

Using Google Remote Procedure Call (gRPC) channel security settings that are specified as to not be encrypted, do not support authentication, or lack the capacity of connection identity leaves the channel open to many forms of attack. Data sent with this insecure channel cannot be trusted.

Example 1: The following code shows a gRPC channel setup with insecure channel credentials

...
ManagedChannel channel = Grpc.newChannelBuilder("hostname", InsecureChannelCredentials.create()).build();
...

Using Google Remote Procedure Call (gRPC) server security settings that are specified as not be encrypted, or do not have the capacity of connection identity leaves the server open to many forms of attack. Data sent to and from this insecure server cannot be trusted.

Example 1: The following code shows a gRPC server setup with insecure server credentials

...
Server server = Grpc.newServerBuilderForPort(port, InsecureServerCredentials.create())
...

The misconception that any information stored in the binary SWF files is safe from unauthorized access often leads to programmers embedding sensitive information like passwords, cryptographic data and sensitive business logic in them. Attackers can however easily decompile the binary SWF files and steal the sensitive information. This could lead to further compromise of the system.
Example:

 if (password eq '783-1') {
    getURL('http://.../client_pages/.../783.html', '');
} 
else {
    if (password eq '771-2 Update') {
        getURL('http://.../client_pages/.../771.html', '');
    } 
    else {
        if (password eq '7990') {
            getURL('http://.../client_pages/.../799.html', '');
        }
}

By decompile the binary SWF, an attacker can not only gain access to the passwords but also to locations of unexposed URLs.