Never hardcode credentials, including usernames, passwords, API keys, API secrets, and API Tokens. Not only are hardcoded credentials visible to all of the project developers, they are extremely difficult to update. After the code is in production, the credentials cannot be changed without patching the software. If the credentials are compromised, the organization must choose between security and system availability.

The Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols provide a protection mechanism to ensure the authenticity, confidentiality, and integrity of data transmitted between a client and web server. Both TLS and SSL have undergone revisions resulting in periodic version updates. Each new revision is designed to address the security weaknesses discovered in previous versions. Use of an insecure version of TLS/SSL weakens the data protection strength and might allow an attacker to compromise, steal, or modify sensitive information.

Weak versions of TLS/SSL might exhibit one or more of the following properties:

- No protection against man-in-the-middle attacks
- Same key used for authentication and encryption
- Weak message authentication control
- No protection against TCP connection closing
- Use of weak cipher suites

The presence of these properties might allow an attacker to intercept, modify, or tamper with sensitive data.

The Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols provide a protection mechanism to ensure the authenticity, confidentiality, and integrity of data transmitted between a client and web server. Both TLS and SSL have undergone revisions resulting in periodic version updates. Each new revision is designed to address the security weaknesses discovered in previous versions. Use of an insecure version of TLS/SSL weakens the data protection strength and might allow an attacker to compromise, steal, or modify sensitive information.

Weak versions of TLS/SSL might exhibit one or more of the following properties:

- No protection against man-in-the-middle attacks
- Same key used for authentication and encryption
- Weak message authentication control
- No protection against TCP connection closing
- Use of weak cipher suites

The presence of these properties might allow an attacker to intercept, modify, or tamper with sensitive data.

The Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols provide a protection mechanism to ensure the authenticity, confidentiality, and integrity of data transmitted between a client and web server. Both TLS and SSL have undergone revisions resulting in periodic version updates. Each new revision is designed to address the security weaknesses discovered in previous versions. Use of an insecure version of TLS/SSL weakens the data protection strength and might allow an attacker to compromise, steal, or modify sensitive information.

Weak versions of TLS/SSL might exhibit one or more of the following properties:

- No protection against man-in-the-middle attacks
- Same key used for authentication and encryption
- Weak message authentication control
- No protection against TCP connection closing
- Use of weak cipher suites

The presence of these properties might allow an attacker to intercept, modify, or tamper with sensitive data.

The Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols provide a protection mechanism to ensure the authenticity, confidentiality, and integrity of data transmitted between a client and web server. Both TLS and SSL have undergone revisions resulting in periodic version updates. Each new revision is designed to address the security weaknesses discovered in previous versions. Use of an insecure version of TLS/SSL weakens the data protection strength and might allow an attacker to compromise, steal, or modify sensitive information.

Weak versions of TLS/SSL might exhibit one or more of the following properties:

- No protection against man-in-the-middle attacks
- Same key used for authentication and encryption
- Weak message authentication control
- No protection against TCP connection closing
- Use of weak cipher suites

The presence of these properties might allow an attacker to intercept, modify, or tamper with sensitive data.

The Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols provide a protection mechanism to ensure the authenticity, confidentiality, and integrity of data transmitted between a client and web server. Both TLS and SSL have undergone revisions resulting in periodic version updates. Each new revision is designed to address the security weaknesses discovered in previous versions. Use of an insecure version of TLS/SSL weakens the data protection strength and might allow an attacker to compromise, steal, or modify sensitive information.

Weak versions of TLS/SSL might exhibit one or more of the following properties:

- No protection against man-in-the-middle attacks
- Same key used for authentication and encryption
- Weak message authentication control
- No protection against TCP connection closing
- Use of weak cipher suites

The presence of these properties might allow an attacker to intercept, modify, or tamper with sensitive data.

Example 1: This Node.js snippet tries to create a server with a secure connection:

...
var options = {
  port: 443,
  path: '/',
  key : fs.readFileSync('my-server-key.pem'),
  cert : fs.readFileSync('server-cert.pem'),
  ...
}
https.createServer(options);
...

Since Node.js sets the default value of secureProtocol to SSLv23_method, the server is inherently insecure when secureProtocol is not specifically overridden.

The Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols provide a protection mechanism to ensure the authenticity, confidentiality, and integrity of data transmitted between a client and web server. Both TLS and SSL have undergone revisions resulting in periodic version updates. Each new revision is designed to address the security weaknesses discovered in previous versions. Use of an insecure version of TLS/SSL weakens the data protection strength and might allow an attacker to compromise, steal, or modify sensitive information.

Weak versions of TLS/SSL might exhibit one or more of the following properties:

- No protection against man-in-the-middle attacks
- Same key used for authentication and encryption
- Weak message authentication control
- No protection against TCP connection closing
- Use of weak cipher suites

The presence of these properties might allow an attacker to intercept, modify, or tamper with sensitive data.

Example 1: The following example uses the default SSL version which is SSL v3.0:

NSURLSessionConfiguration *configuration = [NSURLSessionConfiguration ephemeralSessionConfiguration];
[configuration setTLSMinimumSupportedProtocol = kSSLProtocol3];
NSURLSession *mySession = [NSURLSession sessionWithConfiguration:configuration delegate:self delegateQueue:operationQueue];

The Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols provide a protection mechanism to ensure the authenticity, confidentiality, and integrity of data transmitted between a client and web server. Both TLS and SSL have undergone revisions resulting in periodic version updates. Each new revision is designed to address the security weaknesses discovered in previous versions. Use of an insecure version of TLS/SSL weakens the data protection strength and might allow an attacker to compromise, steal, or modify sensitive information.

Weak versions of TLS/SSL might exhibit one or more of the following properties:

- No protection against man-in-the-middle attacks
- Same key used for authentication and encryption
- Weak message authentication control
- No protection against TCP connection closing
- Use of weak cipher suites

The presence of these properties might allow an attacker to intercept, modify, or tamper with sensitive data.

The Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols provide a protection mechanism to ensure the authenticity, confidentiality, and integrity of data transmitted between a client and web server. Both TLS and SSL have undergone revisions resulting in periodic version updates. Each new revision is designed to address the security weaknesses discovered in previous versions. Use of an insecure version of TLS/SSL weakens the data protection strength and might allow an attacker to compromise, steal, or modify sensitive information.

Weak versions of TLS/SSL might exhibit one or more of the following properties:

- No protection against man-in-the-middle attacks
- Same key used for authentication and encryption
- Weak message authentication control
- No protection against TCP connection closing
- Use of weak cipher suites

The presence of these properties might allow an attacker to intercept, modify, or tamper with sensitive data.

The Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols provide a protection mechanism to ensure the authenticity, confidentiality, and integrity of data transmitted between a client and web server. Both TLS and SSL have undergone revisions resulting in periodic version updates. Each new revision is designed to address the security weaknesses discovered in previous versions. Use of an insecure version of TLS/SSL weakens the data protection strength and might allow an attacker to compromise, steal, or modify sensitive information.

Weak versions of TLS/SSL might exhibit one or more of the following properties:

- No protection against man-in-the-middle attacks
- Same key used for authentication and encryption
- Weak message authentication control
- No protection against TCP connection closing
- Use of weak cipher suites

The presence of these properties might allow an attacker to intercept, modify, or tamper with sensitive data.

The Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols provide a protection mechanism to ensure the authenticity, confidentiality, and integrity of data transmitted between a client and web server. Both TLS and SSL have undergone revisions resulting in periodic version updates. Each new revision is designed to address the security weaknesses discovered in previous versions. Use of an insecure version of TLS/SSL weakens the data protection strength and might allow an attacker to compromise, steal, or modify sensitive information.

Weak versions of TLS/SSL might exhibit one or more of the following properties:

- No protection against man-in-the-middle attacks
- Same key used for authentication and encryption
- Weak message authentication control
- No protection against TCP connection closing
- Use of weak cipher suites

The presence of these properties might allow an attacker to intercept, modify, or tamper with sensitive data.

Example 1: The following example configures the session to use SSL v3.0:

let configuration : NSURLSessionConfiguration = NSURLSessionConfiguration.defaultSessionConfiguration()
let mySession = NSURLSession(configuration: configuration, delegate: self, delegateQueue: operationQueue)

The Transport Layer Security (TLS) protocol and the Secure Sockets Layer (SSL) protocol provide a protection mechanism to ensure authenticity, confidentiality, and integrity of the data transmitted between a client and web server.
The TLS/SSL protocol has undergone various revisions resulting in periodic version updates. Each new revision addressed security weaknesses discovered in the previous versions. Use of insecure protocol versions weakens the strength of the transport protection and can enable an attacker to compromise, steal, or modify sensitive information.
Weak TLS/SSL protocols might exhibit any of the following properties:
1. No protection against man-in-the-middle attacks
2. Same key used for authentication and encryption
3. Weak message authentication control
4. No protection against TCP connection closing

It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:

...
encryptionKey = "lakdsljkalkjlksdfkl".
...

Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.

It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:

    ...
    var encryptionKey:String = "lakdsljkalkjlksdfkl";
    var key:ByteArray = Hex.toArray(Hex.fromString(encryptionKey));
    ...
    var aes.ICipher = Crypto.getCipher("aes-cbc", key, padding);
    ...

Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.

Never hardcode an encryption key because it makes the encryption key visible to all of the project's developers, and makes fixing the problem extremely difficult. Changing the encryption key after the code is in production requires a software patch. If the account that the encryption key protects is compromised, the organization must choose between security and system availability.

Example 1: The following code performs AES encryption using a hardcoded encryption key:

...
Blob encKey = Blob.valueOf('YELLOW_SUBMARINE');
Blob encrypted = Crypto.encrypt('AES128', encKey, iv, input);
...

Anyone with access to the code can see the encryption key. After the application has shipped, there is no way to change the encryption key without a software patch. An employee with access to this information can use it to break into the system. Any attacker with access to the application executable can extract the encryption key value.

It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:

...
using (SymmetricAlgorithm algorithm = SymmetricAlgorithm.Create("AES"))
{
  string encryptionKey = "lakdsljkalkjlksdfkl";
  byte[] keyBytes = Encoding.ASCII.GetBytes(encryptionKey);
  algorithm.Key = keyBytes;
  ...
}

Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.

It is never a good idea to hardcode an encryption key. Not only does hardcoding an encryption key allow all of the project's developers to view the encryption key, it also makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example: The following code uses a hardcoded encryption key:

...
char encryptionKey[] = "lakdsljkalkjlksdfkl";
...

Anyone with access to the code has access to the encryption key. After the program ships, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers have access to the executable for the application they can disassemble the code, which will contain the value of the encryption key used.

It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:

	...
	<cfset encryptionKey = "lakdsljkalkjlksdfkl" />
	<cfset encryptedMsg = encrypt(msg, encryptionKey, 'AES', 'Hex') />
	...

Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.

It is never a good idea to hardcode an encryption key because all of the project's developers can view the encryption key, and fixing the problem is extremely difficult. After the code is in production, changing the encryption key requires a software patch. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:

...
key := []byte("lakdsljkalkjlksd");
block, err := aes.NewCipher(key)
...

Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.

It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:

...
private static final String encryptionKey = "lakdsljkalkjlksdfkl";
byte[] keyBytes = encryptionKey.getBytes();
SecretKeySpec key = new SecretKeySpec(keyBytes, "AES");
Cipher encryptCipher = Cipher.getInstance("AES");
encryptCipher.init(Cipher.ENCRYPT_MODE, key);
...

Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.

It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:

  ...
  var crypto = require('crypto');
  var encryptionKey = "lakdsljkalkjlksdfkl";
  var algorithm = 'aes-256-ctr';
  var cipher = crypto.createCipher(algorithm, encryptionKey);
  ...
  

Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.

It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:

...
NSString encryptionKey = "lakdsljkalkjlksdfkl";
...

Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.

It is never a good idea to hardcode an encryption key. Not only does hardcoding an encryption key allow all of the project's developers to view the encryption key, it also makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account protected by the encryption key is compromised, the owners of the system must choose between security and availability.
Example: The following code uses a hardcoded encryption key to encrypt information:

...
$encryption_key = 'hardcoded_encryption_key';

//$filter = new Zend_Filter_Encrypt('hardcoded_encryption_key');
$filter = new Zend_Filter_Encrypt($encryption_key);

$filter->setVector('myIV');

$encrypted = $filter->filter('text_to_be_encrypted');
print $encrypted;
...

This code will run successfully, but anyone who has access to it will have access to the encryption key. After the program ships, there is likely no way to change the hardcoded encryption key ('hardcoded_encryption_key') unless the program is patched. A devious employee with access to this information can use it to compromise data encrypted by the system.

It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.



Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.

It is never a good idea to hardcode an encryption key. Not only does hardcoding an encryption key allow all of the project's developers to view the encryption key, it also makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account protected by the encryption key is compromised, the owners of the system must choose between security and availability.
Example: The following code uses a hardcoded encryption key to encrypt information:

...
from Crypto.Ciphers import AES
encryption_key = b'_hardcoded__key_'
cipher = AES.new(encryption_key, AES.MODE_CFB, iv)
msg = iv + cipher.encrypt(b'Attack at dawn')
...

This code will run successfully, but anyone who has access to it will have access to the encryption key. After the program ships, there is likely no way to change the hardcoded encryption key _hardcoded__key_ unless the program is patched. A devious employee with access to this information can use it to compromise data encrypted by the system.

It is never a good idea to hardcode an encryption key. Not only does hardcoding an encryption key allow all of the project's developers to view the encryption key, it also makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account protected by the encryption key is compromised, the owners of the system must choose between security and availability.
Example 1: The following code uses a hardcoded encryption key:

require 'openssl'
...
encryption_key = 'hardcoded_encryption_key'
...
cipher = OpenSSL::Cipher::AES.new(256, 'GCM')
cipher.encrypt
...
cipher.key=encryption_key
...

This code will run successfully, but anyone who has access to it will have access to the encryption key. After the program ships, there is likely no way to change the hardcoded encryption key "hardcoded_encryption_key" unless the program is patched. A devious employee with access to this information can use it to compromise data encrypted by the system.

It is never a good idea to hardcode an encryption key. Not only does hardcoding an encryption key allow all of the project's developers to view the encryption key, it also makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:

...
let encryptionKey = "YELLOW_SUBMARINE"
...

Example 2: The following code performs AES encryption using a hardcoded encryption key:

...
CCCrypt(UInt32(kCCEncrypt),
UInt32(kCCAlgorithmAES128),
UInt32(kCCOptionPKCS7Padding),
"YELLOW_SUBMARINE",
16,
iv,
plaintext,
plaintext.length,
ciphertext.mutableBytes,
ciphertext.length,
&numBytesEncrypted)
...

Anyone with access to the code has access to the encryption key. After the program ships, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application they could extract the encryption key value.

Never hardcode an encryption key because it makes the encryption key visible to all of the project's developers, and makes fixing the problem extremely difficult. Changing the encryption key after the code is in production requires a software patch. If the account that the encryption key protects is compromised, the organization must choose between security and system availability.

Example 1: The following example shows an encryption key inside a .pem file:

...
-----BEGIN RSA PRIVATE KEY-----
MIICXwIBAAKBgQCtVacMo+w+TFOm0p8MlBWvwXtVRpF28V+o0RNPx5x/1TJTlKEl
...
DiJPJY2LNBQ7jS685mb6650JdvH8uQl6oeJ/aUmq63o2zOw=
-----END RSA PRIVATE KEY-----
...

Anyone with access to the code can see the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. Any attacker with access to the application executable can extract the encryption key value.

It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:

...
Dim encryptionKey As String
Set encryptionKey = "lakdsljkalkjlksdfkl"
Dim AES As New System.Security.Cryptography.RijndaelManaged
On Error GoTo ErrorHandler
  AES.Key = System.Text.Encoding.ASCII.GetBytes(encryptionKey)
  ...
Exit Sub
...

Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.

Never hardcode an encryption key because it makes the encryption key visible to all of the project's developers, and makes fixing the problem extremely difficult. Changing the encryption key after the code is in production requires a software patch. If the account that the encryption key protects is compromised, the organization must choose between security and system availability.

Example 1: The following example shows an encryption key inside the secrets.yml file of a Ruby on Rails configuration:

...
production:
  secret_key_base: 0ab25e26286c4fb9f7335947994d83f19861354f19702b7bbb84e85310b287ba3cdc348f1f19c8cdc08a7c6c5ad2c20ad31ecda177d2c74aa2d48ec4a346c40e
...

Anyone with access to the code can see the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. Any attacker with access to the application executable can extract the encryption key value.