Kingdom: API Abuse

An API is a contract between a caller and a callee. The most common forms of API abuse are caused by the caller failing to honor its end of this contract. For example, if a program fails to call chdir() after calling chroot(), it violates the contract that specifies how to change the active root directory in a secure fashion. Another good example of library abuse is expecting the callee to return trustworthy DNS information to the caller. In this case, the caller abuses the callee API by making certain assumptions about its behavior (that the return value can be used for authentication purposes). One can also violate the caller-callee contract from the other side. For example, if a coder subclasses SecureRandom and returns a non-random value, the contract is violated.

Often Misused: Weak SSL Certificate

Abstract
The target server uses a self-signed certificate.
Explanation
Server certificates declare the public key of the server for use in transport layer security. Trusted third-party vendors known as Certificate Authorities (CAs) sign and issue the certificates to ensure that they are authentic and contain the public key of the intended server. The public key of the root CA is embedded in the operating system (OS) by the vendor (e.g. Microsoft for Windows or Apple for macOS). After receipt of a certificate, the client (e.g. a web browser) verifies the identity with the OS's embedded trusted CA. In case of a self-signed certificate, the certificate is signed using its own private key, and the client is unable to verify the certificate owner identity with a trusted CA. Because third-party verification is not possible, attackers can mount a man-in-the-middle attack by issuing a certificate with fake details and a public key that they control.

Clients often display a security warning after encountering a self-signed certificate, although the user can usually override this behavior and manually trust the certificate. However, using self-signed certificates in production can encourage the insecure practice of overriding these certificate warnings without properly verifying the certificate's details, which in turn can make users more susceptible to man-in-the-middle attacks.

With a successful man-in-the-middle attack, an attacker can modify or steal sensitive data as it is transmitted. Because self-signed certificates are not verified by a third-party, it is difficult to revoke them. A security issue such as Heartbleed could require servers to revoke their certificates to ensure the effectiveness of bug remediation.
References
[1] Transport Layer Protection Cheat Sheet OWASP
[2] The Hidden Costs of Self-Signed SSL Certificates Thawte
[3] Standards Mapping - Common Weakness Enumeration CWE ID 296
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [25] CWE ID 295
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000185, CCI-001941, CCI-001942
[11] Standards Mapping - FIPS200 CM
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-10 Non-Repudiation (P2), IA-2 Identification and Authentication (Organizational Users) (P1), IA-5 Authenticator Management (P1), SC-17 Public Key Infrastructure Certificates (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, IA-2 Identification and Authentication (Organizational Users), IA-5 Authenticator Management, SC-17 Public Key Infrastructure Certificates
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 9.2.1 Server Communications Security Requirements (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M3 Insufficient Transport Layer Protection
[17] Standards Mapping - OWASP Mobile 2024 M5 Insecure Communication
[18] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[19] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.9
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3305 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3305 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3305 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3305 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3305 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3305 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3305 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15), Insufficient Authentication (WASC-01)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication
desc.dynamic.xtended_preview.often_misused_weak_ssl_certificate