Skip to content

CWE-326: Inadequate Encryption Strength

Overview

This guidance helps you interpret and remediate findings from DAST (Dynamic Application Security Testing) tools. The scanner detected that the application uses weak cryptographic algorithms or insufficient key lengths. Evidence includes TLS connections negotiating weak ciphers (RC4, DES, export-grade), small RSA key sizes (<2048 bits), or legacy SSL/TLS versions (SSLv3, TLS 1.0). Scanner analysis of negotiated cipher suites, certificate key sizes, or cryptographic headers in responses reveals these weaknesses.

Analyzing the Dynamic Scan Result

What the DAST Scanner Found

DAST findings for CWE-326 typically indicate that the application negotiated weak or deprecated cryptographic parameters at runtime, such as:

  • Use of deprecated TLS protocol versions
  • Acceptance of weak or export-grade cipher suites
  • Use of insufficient key sizes
  • Successful negotiation of cryptography that a modern client would reject

Evidence is based on observed protocol and cipher negotiation behavior rather than request parameters or response content.

Mapping DAST Findings to Source Code

CWE-326 does not map to a specific HTTP endpoint or request parameter.
The issue resides in cryptographic configuration and protocol negotiation logic.

When tracing this issue in code and configuration, look for:

  • TLS/SSL configuration specifying weak protocol versions
  • Cipher suite allowlists that include deprecated algorithms
  • Explicit key-size configuration below modern minimums
  • Legacy crypto libraries or compatibility modes
  • Server or client configuration overriding secure defaults

Remediation

Core Principle: Never allow cryptographic strength to be determined by legacy compatibility or client input; cryptographic algorithms, protocols, and key sizes must be centrally defined, server-controlled, and constrained to secure minimums.

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

The static guidance provides detailed remediation steps for all languages. If you need language-specific examples:

Verification and Follow-Up Testing

The following tests validate the cryptographic parameters negotiated by the application at runtime.

After applying the fix:

Reproduce the Vulnerability

These examples assume the application terminates TLS directly; if TLS is terminated by a load balancer or proxy, test that component instead.

# Test TLS/SSL configuration
ssl scan --show-protocols --show-ciphers localhost:443
nmap --script ssl-enum-ciphers -p 443 localhost

# Or use online tools: SSL Labs, testssl.sh

Verify the Fix

  • Confirm TLS 1.2+ is minimum version (disable SSLv3, TLS 1.0/1.1)
  • Verify strong cipher suites only (AES-GCM, ChaCha20)
  • Check key sizes: ≥128-bit symmetric, ≥2048-bit RSA
  • Ensure forward secrecy (ECDHE, DHE)
  • Test weak ciphers are disabled

Test Edge Cases

# Check for weak protocols
openssl s_client -connect localhost:443 -ssl3  # Should fail
openssl s_client -connect localhost:443 -tls1  # Should fail

# Check for weak ciphers
openssl s_client -connect localhost:443 -cipher 'DES'    # Should fail
openssl s_client -connect localhost:443 -cipher 'RC4'    # Should fail
openssl s_client -connect localhost:443 -cipher 'EXPORT' # Should fail

# Verify strong ciphers work
openssl s_client -connect localhost:443 -cipher 'AES128-GCM-SHA256'

# 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