Skip to content

CWE-321: Use of Hard-coded Cryptographic Key

Overview

This guidance helps you interpret and remediate findings from DAST (Dynamic Application Security Testing) tools. The scanner detected evidence suggesting the application uses static or predictable cryptographic keys. Evidence includes consistent encryption/signing behavior across restarts, identical tokens generated from the same input, or cryptographic operations that don't vary with key rotation. Dynamic analysis may reveal this through token analysis (JWT signatures verifiable with publicly-known keys), or responses indicating hard-coded secrets (error messages, debug endpoints).

Analyzing the Dynamic Scan Result

What the DAST Scanner Found

DAST findings for CWE-321 typically indicate cryptographic behavior that suggests the use of a fixed or embedded key, such as:

  • Identical encrypted values across requests or deployments
  • Tokens or ciphertext that remain valid after redeployment or restart
  • Cryptographic material that does not change across environments

DAST does not directly observe hard-coded keys; these findings indicate a likely key-management design flaw that must be confirmed in code.

Mapping DAST Findings to Source Code

DAST cannot directly identify hard-coded cryptographic keys; the following steps help trace runtime cryptographic behavior back to likely implementation causes.

Find the Vulnerable Endpoint

Search for cryptographic operations:

# Search for encryption/crypto code
grep -r "encrypt" src/
grep -r "decrypt" src/
grep -r "crypto" src/
grep -r "AES" src/
grep -r "key.*=" src/

Locate Encryption Code

Common patterns to search for:

  • Python: Fernet(key), AES.new(key, ...)
  • Node.js: crypto.createCipher(algorithm, key)
  • Java: SecretKeySpec(keyBytes, "AES")
  • C#/.NET: Aes.Create(), key initialization
  • PHP: openssl_encrypt($data, $method, $key)

Find Hard-Coded Keys

Search for literal key values:

# Find hard-coded encryption keys
grep -r "key.*=.*['\"]" src/
grep -r "SECRET_KEY.*=" src/
grep -r "iv.*=.*['\"]" src/

Trace to Vulnerable Operation

Look for hard-coded keys in:

  • Encryption keys: AES, DES keys as string literals
  • JWT secrets: HS256 signing keys in code
  • Session keys: Cookie encryption keys
  • Initialization vectors (IV): Fixed/hard-coded IVs
  • Salts: Hard-coded password hashing salts

Remediation

Core Principle: Never embed cryptographic keys in application artifacts (source code, binaries, images, or client-accessible configuration); keys must be provided to the application at runtime from a dedicated key-management boundary and treated as replaceable secrets.

→ For comprehensive remediation guidance, see Static CWE-321 Guidance

Verification and Follow-Up Testing

After applying the fix:

Reproduce the Vulnerability

# Search for hard-coded encryption keys
grep -ri "SECRET_KEY" src/
grep -ri "key.*=.*['\"]" src/
grep -r "Fernet\|AES\|DES" src/

# Check for JWT secrets
grep -ri "jwt.*secret" src/

Verify the Fix

  • Confirm encryption keys loaded from environment
  • Verify key management solution used
  • Check keys rotated regularly
  • Ensure separate keys per environment
  • Test IVs are randomly generated (not fixed)
  • Verify encrypted values differ across deployments or restarts

Test Edge Cases

# Hard-coded encryption keys
grep -r "AES.*key.*=" src/
grep -r "SECRET.*=.*['\"]" src/

# JWT/session keys
grep -ri "jwt.*secret.*=" src/
grep -ri "session.*key" src/

# Initialization vectors
grep -r "iv.*=.*['\"]" src/

# Check config files
cat config/*.conf | grep -i "key\|secret"

# Or use browser DevTools Network tab to copy as cURL

Re-run DAST Scanner

Run your dynamic scanner again on the fixed endpoint to confirm remediation.

Additional Resources