OWASP API Security Top 10 2021 with Java Examples

• Definition of Object-Level Authorization and Its Importance

• Explanation of BOLA Vulnerabilities and Their Prevalence in APIs

• Connection to OWASP Top 10: Broken Access Control

• Real-world examples of data breaches due to BOLA

• Consequences for organizations and users of not adhering to BOLA best practices

• Insecure Coding Practices Leading to BOLA

• Definition of Broken Object Property Level Authorization

• Importance in API security

• Threat Agents and Attack Vectors

• Security weaknesses and their impacts

• Real-world consequences of vulnerabilities

• Example Review - Scenario #1: Fitness App Workout Tracking

• Example Review - Scenario #2: Online Learning Platform Quiz Submissions

• Prevention Measures -

  • Implementing access controls

  • Minimizing Data Exposure

  • Using Schema-Based Validation

  • Avoiding Client-Side Filtering Reliance

• Related Concepts:

  • Excessive Data Exposure (OWASP API3:2019)

  • Mass Assignment (OWASP API6:2019)

• Definition of Unrestricted Resource Consumption

• Threat Agents and Attack Vectors

• Typical design flaws and configuration issues

• Technical Impact Analysis

• Business Impact Analysis

• Real-World Examples of Unrestricted Resource Consumption

• SMS Abuse Leading to Financial Loss (NordVPN)

• Increased Cloud Storage Costs (File Download Service)

• DDoS Attack on Poland’s Tax Portal

• CWE-770: Allocation of Resources Without Limits or Throttling

• CWE-400: Uncontrolled Resource Consumption

• CWE-799: Improper Control of Interaction Frequency

• Detection of Unrestricted Resource Consumption

• Prevention Strategies

• Best Practices

• Introduction to SSRF

• Similarities Between API7:2023 and A10:2021

• Differences Between API7:2023 and A10:2021

• Attack Scenarios in API7:2023

• Prevention Strategies

• Summary and Conclusion

• Introduction to Security Misconfiguration

• Similarities Between API8:2023 and A05:2021

• Differences Between API8:2023 and A05:2021

• Attack Scenarios in API8:2023

• Prevention Strategies

• Summary and Conclusion

List 1: Best Practices for Code Security - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Implementation of checksums or hashes for verifying the integrity of interpreted code, libraries, executables, and configuration files.

• Avoidance of passing user-supplied data to any dynamic execution function.

• Use of tested and approved managed code instead of creating new unmanaged code for common tasks.

Moderate Relevance (Common Security Concerns):

• Protection of shared variables and resources from inappropriate concurrent access.

• Review of all secondary applications, third-party code, and libraries to determine business necessity and validate safe functionality.

• Delay in raising elevated privileges until necessary, with prompt dropping of those privileges as soon as possible.

Low Relevance (Edge Cases and Lesser-known Threats):

• Utilization of task-specific built-in APIs for conducting operating system tasks, avoiding direct commands to the Operating System through application-initiated command shells.

• Implementation of safe updating practices, including the use of cryptographic signatures for code.

• Explicit initialization of all variables and data stores, either during declaration or prior to first usage.

• Restriction of user capabilities to generate new code or alter existing code.

• Use of locking mechanisms to prevent multiple simultaneous requests or synchronization mechanisms to avoid race conditions.

• Awareness of calculation errors through understanding the programming language's underlying representation.

List 2: Best Practices for Code Security - Ordered by Complexity

Basic (Beginner):

• Explicit initialization of all variables and data stores, either during declaration or prior to first usage.

• Restriction of user capabilities to generate new code or alter existing code.

• Protection of shared variables and resources from inappropriate concurrent access.

Intermediate:

• Use of locking mechanisms to prevent multiple simultaneous requests or synchronization mechanisms to avoid race conditions.

• Delay in raising elevated privileges until necessary, with prompt dropping of those privileges as soon as possible.

• Utilization of task-specific built-in APIs for conducting operating system tasks, avoiding direct commands to the Operating System through application-initiated command shells.

Advanced:

• Implementation of checksums or hashes for verifying the integrity of interpreted code, libraries, executables, and configuration files.

• Review of all secondary applications, third-party code, and libraries to determine business necessity and validate safe functionality.

• Avoidance of passing user-supplied data to any dynamic execution function.

• Implementation of safe updating practices, including the use of cryptographic signatures for code.

• Use of tested and approved managed code instead of creating new unmanaged code for common tasks.

• Awareness of calculation errors through understanding the programming language's underlying representation.

List 1: Data Validation Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

1. Client Data Validation before processing, including parameters, URLs, HTTP headers, and automated postbacks (e.g., JavaScript, Flash, etc.)

2. Data Validation on Trusted Systems (e.g., The server)

3. Classification of Data Sources into trusted and untrusted. Validation required for all data from untrusted sources.

4. Whitelist-Based Input Validation for allowed characters; implement additional controls for hazardous characters such as < > " ' % ( ) & + \ \' \".

5. Centralized Input Validation Routine for the application

Moderate Relevance (Common Security Concerns):

1. Redirect Data Validation (to avoid bypassing application logic and validation before redirect)

2. Canonicalization Process (Encoding data to a common character set before validation)

3. UTF-8 Character Set Support Validation post-decoding

4. Character Set Specification such as UTF-8 for all input sources

5. Data Length Validation

6. Data Type Validation

7. Data Range Validation

Low Relevance (Edge Cases and Lesser-known Threats):

1. ASCII Header Value Verification

2. Input Rejection on Validation Failure

3. Discrete Validation Checks for inputs not covered by standard routines:

   • Null Byte Validation (%00)

   • New Line Character Validation (%0d, %0a, \r, \n)

   • Path Traversal Validation (../ or ..)

List 2: Data Validation Best Practices - Ordered by Complexity

Basic (Beginner):

1. Data Type Validation

2. Data Range Validation

3. Data Length Validation

4. Input Rejection on Validation Failure

5. ASCII Header Value Verification

Intermediate:

1. Classification of Data Sources into trusted and untrusted. Validation required for all data from untrusted sources.

2. Client Data Validation before processing, including parameters, URLs, HTTP headers, and automated postbacks (e.g., JavaScript, Flash, etc.)

3. Character Set Specification such as UTF-8 for all input sources

4. Redirect Data Validation (to avoid bypassing application logic and validation before redirect)

5. UTF-8 Character Set Support Validation post-decoding

Advanced:

1. Data Validation on Trusted Systems (e.g., The server)

2. Canonicalization Process (Encoding data to a common character set before validation)

3. Centralized Input Validation Routine for the application

4. Whitelist-Based Input Validation for allowed characters; implement additional controls for hazardous characters such as < > " ' % ( ) & + \ \' \".

5. Discrete Validation Checks for inputs not covered by standard routines:

   • Null Byte Validation (%00)

   • New Line Character Validation (%0d, %0a, \r, \n)

Path Traversal Validation (../ or ..) with UTF-8 extended character set handling

List 1: Best Practices for Data Encoding and Sanitization - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Contextual sanitization of all output containing untrusted data for SQL, XML, and LDAP queries.

• Sanitization of all output with untrusted data for operating system commands.

• Contextual output encoding of all data returned to the client that originated outside the application's trust boundary; HTML entity encoding is one example, though not universally applicable.

Moderate Relevance (Common Security Concerns):

• Encoding of all characters unless they are confirmed safe for the intended interpreter.

• Utilization of a standard, tested routine for each type of outbound encoding.

Low Relevance (Edge Cases and Lesser-known Threats):

• Conducting all encoding on a trusted system (e.g., the server).

List 2: Best Practices for Data Encoding and Sanitization - Ordered by Complexity

Basic (Beginner):

• Encoding of all characters unless they are confirmed safe for the intended interpreter.

• Conducting all encoding on a trusted system (e.g., the server).

Intermediate:

• Utilization of a standard, tested routine for each type of outbound encoding.

• Contextual output encoding of all data returned to the client that originated outside the application's trust boundary; HTML entity encoding is one example, though not universally applicable.

Advanced:

• Contextual sanitization of all output containing untrusted data for SQL, XML, and LDAP queries.

• Sanitization of all output with untrusted data for operating system commands.

List 1: Authentication Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Requirement of authentication for all pages and resources, except those specifically intended to be public.

• Enforcement of all authentication controls on a trusted system (e.g., the server).

• Secure failure of all authentication controls.

• Encryption and protected storage of authentication credentials for accessing services external to the application on a trusted system (e.g., the server), avoiding source code as a secure location.

• Indistinct authentication failure responses that do not specify which part of the authentication data was incorrect (e.g., "Invalid username and/or password").

• Prevention of password re-use.

• Requirement for password reset and changing operations to have the same level of controls as account creation and authentication.

Moderate Relevance (Common Security Concerns):

• Establishment and utilization of standard, tested authentication services whenever possible.

• Centralized implementation for all authentication controls, including libraries that call external authentication services.

• Enforcement of password complexity and length requirements established by policy or regulation.

• Obscuring of password entry on the user's screen (e.g., "password" input type on web forms).

• Enforcement of account disabling after an established number of invalid login attempts (e.g., five attempts).

• Notification of users upon occurrence of a password reset.

• Re-authentication of users prior to performing critical operations.

• Use of Multi-Factor Authentication for highly sensitive or high-value transactional accounts.

Low Relevance (Edge Cases and Lesser-known Threats):

• Segregation of authentication logic from the requested resource, with redirection to and from the centralized authentication control.

• Management of a credential store ensuring storage of cryptographically strong one-way salted hashes of passwords, avoiding the MD5 algorithm if possible.

• Validation of authentication data only upon completion of all data input, particularly for sequential authentication implementations.

• Use of only HTTP POST requests to transmit authentication credentials.

• Short expiration time for temporary passwords and links, along with enforced changes upon next use.

• Disabling of "remember me" functionality for password fields.

• Reporting of the last use (successful or unsuccessful) of a user account to the user at the next successful login.

• Monitoring of attacks against multiple user accounts using the same password.

• Change or disabling of all vendor-supplied default passwords and user IDs.

• Enforcement of password changes based on requirements established in policy or regulation.

List 2: Authentication Best Practices - Ordered by Complexity

Basic (Beginner):

• Requirement of authentication for all pages and resources, except those specifically intended to be public.

• Indistinct authentication failure responses that do not specify which part of the authentication data was incorrect (e.g., "Invalid username and/or password").

• Prevention of password re-use.

• Obscuring of password entry on the user's screen (e.g., "password" input type on web forms).

• Short expiration time for temporary passwords and links, along with enforced changes upon next use.

• Disabling of "remember me" functionality for password fields.

Intermediate:

• Enforcement of all authentication controls on a trusted system (e.g., the server).

• Establishment and utilization of standard, tested authentication services whenever possible.

• Centralized implementation for all authentication controls, including libraries that call external authentication services.

• Encryption and protected storage of authentication credentials for accessing services external to the application on a trusted system (e.g., the server).

• Enforcement of password complexity and length requirements established by policy or regulation.

• Enforcement of account disabling after an established number of invalid login attempts (e.g., five attempts).

• Notification of users upon occurrence of a password reset.

• Validation of authentication data only upon completion of all data input, particularly for sequential authentication implementations.

• Re-authentication of users prior to performing critical operations.

• Use of only HTTP POST requests to transmit authentication credentials.

Advanced:

• Secure failure of all authentication controls.

• Segregation of authentication logic from the requested resource, with redirection to and from the centralized authentication control.

• Management of a credential store ensuring storage of cryptographically strong one-way salted hashes of passwords, avoiding the MD5 algorithm if possible.

• Use of Multi-Factor Authentication for highly sensitive or high-value transactional accounts.

• Monitoring of attacks against multiple user accounts using the same password.

• Reporting of the last use (successful or unsuccessful) of a user account to the user at the next successful login.

• Change or disabling of all vendor-supplied default passwords and user IDs.

• Enforcement of password changes based on requirements established in policy or regulation.

List 1: Session Management Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Full termination of the associated session or connection through logout functionality.

• Creation of session identifiers on a trusted system (e.g., the server).

• Use of well-vetted algorithms for session management controls to ensure sufficiently random session identifiers.

• Prevention of session identifier exposure in URLs, error messages, or logs. Session identifiers should only be located in the HTTP cookie header, not passed as GET parameters.

• Protection of server-side session data from unauthorized access through appropriate access controls on the server.

• Generation of a new session identifier when the connection security changes from HTTP to HTTPS, with consistent use of HTTPS recommended throughout the application.

• Disallowance of persistent logins and enforcement of periodic session terminations, even when sessions are active.

Moderate Relevance (Common Security Concerns):

• Periodic generation of a new session identifier and deactivation of the old one to mitigate session hijacking risks.

• Generation of a new session identifier upon re-authentication.

• Establishment of a session inactivity timeout that balances risk and business requirements, typically no longer than several hours.

• Prohibition of concurrent logins with the same user ID.

• Setting of the domain and path for cookies containing authenticated session identifiers to a restricted value for the site.

• Closure of any pre-login session and establishment of a new session after a successful login.

Low Relevance (Edge Cases and Lesser-known Threats):

• Setting of the "secure" attribute for cookies transmitted over a TLS connection.

• Setting of cookies with the HttpOnly attribute, unless client-side scripts specifically require access to read or set a cookie's value.

• Supplementation of standard session management for sensitive server-side operations (e.g., account management) by utilizing per-session strong random tokens or parameters to prevent CSRF attacks.

• Supplementation of standard session management for highly sensitive or critical operations by using per-request strong random tokens or parameters.

• Availability of logout functionality on all pages protected by authorization.

List 2: Session Management Best Practices - Ordered by Complexity

Basic (Beginner):

• Use of server or framework-based session management controls, with the application recognizing only these session identifiers as valid.

• Availability of logout functionality on all pages protected by authorization.

• Setting of the domain and path for cookies containing authenticated session identifiers to a restricted value for the site.

• Setting of the "secure" attribute for cookies transmitted over a TLS connection.

• Setting of cookies with the HttpOnly attribute, unless client-side scripts specifically require access to read or set a cookie's value.

Intermediate:

• Creation of session identifiers on a trusted system (e.g., the server).

• Use of well-vetted algorithms for session management controls to ensure sufficiently random session identifiers.

• Generation of a new session identifier upon re-authentication.

• Generation of a new session identifier when the connection security changes from HTTP to HTTPS, with consistent use of HTTPS recommended throughout the application.

• Prohibition of concurrent logins with the same user ID.

• Closure of any pre-login session and establishment of a new session after a successful login.

Advanced:

• Full termination of the associated session or connection through logout functionality.

• Prevention of session identifier exposure in URLs, error messages, or logs. Session identifiers should only be located in the HTTP cookie header, not passed as GET parameters.

• Protection of server-side session data from unauthorized access through appropriate access controls on the server.

• Periodic generation of a new session identifier and deactivation of the old one to mitigate session hijacking risks.

• Establishment of a session inactivity timeout that balances risk and business requirements, typically no longer than several hours.

• Disallowance of persistent logins and enforcement of periodic session terminations, even when sessions are active.

• Supplementation of standard session management for sensitive server-side operations (e.g., account management) by utilizing per-session strong random tokens or parameters to prevent CSRF attacks.

• Supplementation of standard session management for highly sensitive or critical operations by using per-request strong random tokens or parameters.

List 1: Best Practices for Access Control - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Restriction of access to protected URLs to only authorized users.

• Restriction of access to protected functions to only authorized users.

• Restriction of access to application data to only authorized users.

• Secure failure of access controls.

• Denial of all access if the application cannot retrieve its security configuration information.

• Restriction of direct object references to only authorized users.

• Restriction of access to files or resources, including those outside the application's direct control, to only authorized users.

Moderate Relevance (Common Security Concerns):

• Enforcement of authorization controls on every request, including those made by server-side scripts, "includes," and requests from rich client-side technologies like AJAX and Flash.

• Periodic re-validation of a user’s authorization if long authenticated sessions are allowed, with logout and re-authentication if privileges have changed.

• Matching of server-side implementation and presentation layer representations of access control rules.

• Limitation of the number of transactions a single user or device can perform in a given period, set above actual business requirements but low enough to deter automated attacks.

• Segregation of privileged logic from other application code.

• Restriction of access to user and data attributes and policy information used by access controls.

Low Relevance (Edge Cases and Lesser-known Threats):

• Use of encryption and integrity checking on the server side to catch state tampering if state data must be stored on the client.

• Use of the "referer" header as a supplemental check only, never as the sole authorization check, due to its susceptibility to spoofing.

• Implementation of account auditing and enforcement of disabling unused accounts (e.g., after no more than 30 days from the expiration of an account’s password).

• Support for disabling accounts and terminating sessions when authorization ceases (e.g., changes to role, employment status, or business process).

• Application of the least privilege principle to service accounts or accounts supporting connections to or from external systems.

• Creation of an Access Control Policy to document an application's business rules, data types, and access authorization criteria and processes for proper provisioning and control of access.

List 2: Best Practices for Access Control - Ordered by Complexity

Basic (Beginner):

• Restriction of access to protected URLs to only authorized users.

• Restriction of access to protected functions to only authorized users.

• Restriction of access to application data to only authorized users.

• Secure failure of access controls.

• Denial of all access if the application cannot retrieve its security configuration information.

Intermediate:

• Enforcement of authorization controls on every request, including those made by server-side scripts, "includes," and requests from rich client-side technologies like AJAX and Flash.

• Segregation of privileged logic from other application code.

• Periodic re-validation of a user’s authorization if long authenticated sessions are allowed, with logout and re-authentication if privileges have changed.

• Matching of server-side implementation and presentation layer representations of access control rules.

• Restriction of direct object references to only authorized users.

• Limitation of the number of transactions a single user or device can perform in a given period, set above actual business requirements but low enough to deter automated attacks.

Advanced:

• Use of encryption and integrity checking on the server side to catch state tampering if state data must be stored on the client.

• Restriction of access to files or resources, including those outside the application's direct control, to only authorized users.

• Restriction of access to user and data attributes and policy information used by access controls.

• Use of the "referer" header as a supplemental check only, never as the sole authorization check, due to its susceptibility to spoofing.

• Implementation of account auditing and enforcement of disabling unused accounts (e.g., after no more than 30 days from the expiration of an account’s password).

• Support for disabling accounts and terminating sessions when authorization ceases (e.g., changes to role, employment status, or business process).

• Application of the least privilege principle to service accounts or accounts supporting connections to or from external systems.

• Creation of an Access Control Policy to document an application's business rules, data types, and access authorization criteria and processes for proper provisioning and control of access.

List 1: Zero Trust Architecture and Modern Authentication Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Adoption of the Zero Trust principle, where no user or device is trusted by default, even inside the network perimeter.

• Implementation of multi-factor authentication (MFA) across all systems to ensure stronger identity verification.

• Use of biometric verification methods (e.g., fingerprint scanning, facial recognition) for secure user authentication and to prevent credential-based attacks.

• Continuous monitoring and behavioral analytics to detect anomalies in user behavior and identify potential security threats.

• Enforcement of least privilege access based on real-time user behavior, identity, and context, ensuring that users only have the minimum necessary access to resources.

Moderate Relevance (Common Security Concerns):

• Integration of strong identity and access management (IAM) systems to ensure that all users and devices are authenticated and authorized before accessing any resource.

• Segmentation of the network using micro-segmentation to isolate sensitive resources and limit lateral movement in case of a breach.

• Implementation of device trust policies to ensure that only secure, compliant devices are allowed access to critical systems.

• Use of context-aware access controls that take into account the user’s device, location, and time of access to assess the risk before granting access.

• Adoption of zero trust for cloud environments, enforcing identity verification and least privilege for users accessing cloud-based resources.

Low Relevance (Edge Cases and Lesser-known Threats):

• Use of behavioral biometrics (e.g., typing patterns, mouse movements) as an additional authentication layer to enhance security.

• Continuous session validation to ensure that authenticated sessions remain secure over time, with periodic re-authentication when necessary.

• Logging and auditing of all access attempts and activities to ensure full visibility into user and device behavior for detecting and responding to potential threats.

• Implementation of adaptive access policies that can dynamically adjust access privileges based on the risk level of user behavior and context.

• Elimination of VPN reliance, replacing traditional network security approaches with zero trust controls that authenticate and authorize users regardless of network location.

List 2: Zero Trust Architecture and Modern Authentication Best Practices - Ordered by Complexity

Basic (Beginner):

• Adoption of the Zero Trust principle, where no user or device is trusted by default, even inside the network perimeter.

• Enforcement of least privilege access based on real-time user behavior, identity, and context, ensuring that users only have the minimum necessary access to resources.

• Use of multi-factor authentication (MFA) across all systems to ensure stronger identity verification.

• Integration of strong identity and access management (IAM) systems to ensure that all users and devices are authenticated and authorized before accessing any resource.

• Continuous session validation to ensure that authenticated sessions remain secure over time, with periodic re-authentication when necessary.

Intermediate:

• Use of biometric verification methods (e.g., fingerprint scanning, facial recognition) for secure user authentication and to prevent credential-based attacks.

• Continuous monitoring and behavioral analytics to detect anomalies in user behavior and identify potential security threats.

• Implementation of device trust policies to ensure that only secure, compliant devices are allowed access to critical systems.

• Segmentation of the network using micro-segmentation to isolate sensitive resources and limit lateral movement in case of a breach.

• Adoption of zero trust for cloud environments, enforcing identity verification and least privilege for users accessing cloud-based resources.

Advanced:

• Use of context-aware access controls that take into account the user’s device, location, and time of access to assess the risk before granting access.

• Use of behavioral biometrics (e.g., typing patterns, mouse movements) as an additional authentication layer to enhance security.

• Logging and auditing of all access attempts and activities to ensure full visibility into user and device behavior for detecting and responding to potential threats.

• Implementation of adaptive access policies that can dynamically adjust access privileges based on the risk level of user behavior and context.

• Elimination of VPN reliance, replacing traditional network security approaches with zero trust controls that authenticate and authorize users regardless of network location.

List 1: Cryptographic and Logging Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Protection of master secrets from unauthorized access.

• Implementation of all cryptographic functions used to protect secrets on a trusted system (e.g., the server).

• Secure failure of cryptographic modules.

• Generation of random numbers, file names, GUIDs, and strings using an approved cryptographic module's random number generator for un-guessable values.

• Logging of all authentication attempts, with emphasis on failed attempts.

• Logging of all access control failures.

• Logging of all apparent tampering events, including unexpected state data changes.

Moderate Relevance (Common Security Concerns):

• Compliance of cryptographic modules with FIPS 140-2 or an equivalent standard.

• Logging of all input validation failures.

• Logging of all system exceptions.

• Avoidance of sensitive information disclosure in error responses, including system details, session identifiers, or account information.

• Use of cryptographic hash functions to validate log entry integrity.

• Logging of all backend TLS connection failures.

• Logging of cryptographic module failures.

Low Relevance (Edge Cases and Lesser-known Threats):

• Establishment and utilization of a policy and process for cryptographic key management.

• Use of error handlers that do not expose debugging or stack trace details.

• Implementation of generic error messages and custom error pages.

• Handling of application errors directly within the application, not relying solely on server configuration.

• Proper memory deallocation when error conditions occur.

• Denial of access by default in error handling logic associated with security controls.

• Implementation of logging controls on a trusted system (e.g., the server).

• Ensuring logs contain important log event data.

• Prevention of untrusted data in log entries from executing as code in log viewing interfaces or software.

• Restriction of log access to authorized individuals only.

• Utilization of a centralized routine for all logging operations.

• Avoidance of storing sensitive information in logs, such as system details, session identifiers, or passwords.

• Ensuring a mechanism exists for log analysis.

• Logging of attempts to connect using invalid or expired session tokens.

• Logging of all administrative functions, particularly changes to security configuration settings.

List 2: Cryptographic and Logging Best Practices - Ordered by Complexity

Basic (Beginner):

• Avoidance of sensitive information disclosure in error responses, including system details, session identifiers, or account information.

• Use of error handlers that do not expose debugging or stack trace details.

• Implementation of generic error messages and custom error pages.

• Proper memory deallocation when error conditions occur.

• Logging of all authentication attempts, with emphasis on failed attempts.

• Logging of all access control failures.

• Logging of all input validation failures.

• Logging of all system exceptions.

Intermediate:

• Implementation of all cryptographic functions used to protect secrets on a trusted system (e.g., the server).

• Logging of all backend TLS connection failures.

• Logging of cryptographic module failures.

• Logging of all apparent tampering events, including unexpected state data changes.

• Use of cryptographic hash functions to validate log entry integrity.

• Prevention of untrusted data in log entries from executing as code in log viewing interfaces or software.

• Restriction of log access to authorized individuals only.

• Utilization of a centralized routine for all logging operations.

• Ensuring a mechanism exists for log analysis.

Advanced:

• Protection of master secrets from unauthorized access.

• Secure failure of cryptographic modules.

• Generation of random numbers, file names, GUIDs, and strings using an approved cryptographic module's random number generator for un-guessable values.

• Compliance of cryptographic modules with FIPS 140-2 or an equivalent standard.

• Establishment and utilization of a policy and process for cryptographic key management.

• Denial of access by default in error handling logic associated with security controls.

• Implementation of logging controls on a trusted system (e.g., the server).

• Ensuring logs contain important log event data.

• Logging of attempts to connect using invalid or expired session tokens.

• Logging of all administrative functions, particularly changes to security configuration settings.

List 1: Data Protection Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Implementation of least privilege, restricting users to only the necessary functionality, data, and system information required for their tasks.

• Encryption of highly sensitive stored information, such as authentication verification data, even on the server side, using well-vetted algorithms (refer to "Cryptographic Practices" for further guidance).

• Protection of all cached or temporary copies of sensitive data stored on the server from unauthorized access, with purging of temporary working files once no longer required.

• Implementation of appropriate access controls for sensitive data stored on the server, including cached data, temporary files, and data restricted to specific system users.

• Protection of server-side source code from unauthorized downloads by users.

Moderate Relevance (Common Security Concerns):

• Avoidance of storing passwords, connection strings, or other sensitive information in clear text or non-cryptographically secure methods on the client side, including insecure formats like MS viewstate, Adobe Flash, or compiled code.

• Disabling of client-side caching on pages containing sensitive information, with the use of Cache-Control: no-store, and optionally "Pragma: no-cache" for backward compatibility with HTTP/1.0.

• Avoidance of including sensitive information in HTTP GET request parameters.

• Removal of comments in user-accessible production code that may disclose backend system details or other sensitive information.

Low Relevance (Edge Cases and Lesser-known Threats):

• Disabling of autocomplete features on forms expected to contain sensitive information, such as authentication forms.

• Support for the removal of sensitive data from the application when it is no longer required (e.g., personal information or financial data).

• Removal of unnecessary application and system documentation to prevent attackers from accessing useful information.

List 2: Data Protection Best Practices - Ordered by Complexity

Basic (Beginner):

• Avoidance of including sensitive information in HTTP GET request parameters.

• Removal of comments in user-accessible production code that may disclose backend system details or other sensitive information.

• Removal of unnecessary application and system documentation to prevent attackers from accessing useful information.

• Disabling of autocomplete features on forms expected to contain sensitive information, such as authentication forms.

Intermediate:

• Disabling of client-side caching on pages containing sensitive information, with the use of Cache-Control: no-store, and optionally "Pragma: no-cache" for backward compatibility with HTTP/1.0.

• Support for the removal of sensitive data from the application when it is no longer required (e.g., personal information or financial data).

• Avoidance of storing passwords, connection strings, or other sensitive information in clear text or non-cryptographically secure methods on the client side, including insecure formats like MS viewstate, Adobe Flash, or compiled code.

Advanced:

• Implementation of least privilege, restricting users to only the necessary functionality, data, and system information required for their tasks.

• Encryption of highly sensitive stored information, such as authentication verification data, even on the server side, using well-vetted algorithms (refer to "Cryptographic Practices" for further guidance).

• Protection of all cached or temporary copies of sensitive data stored on the server from unauthorized access, with purging of temporary working files once no longer required.

• Protection of server-side source code from unauthorized downloads by users.

• Implementation of appropriate access controls for sensitive data stored on the server, including cached data, temporary files, and data restricted to specific system users.

List 1: Database Security Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Use of strongly typed parameterized queries.

• Access to the database by the application using the lowest possible level of privilege.

• Use of secure credentials for database access.

• Storage of connection strings in a separate, encrypted configuration file on a trusted system, avoiding hardcoding within the application.

• Removal or modification of all default database administrative passwords, ensuring strong passwords/phrases or multi-factor authentication.

Moderate Relevance (Common Security Concerns):

• Utilization of input validation and output encoding, ensuring meta characters are properly handled, and prevention of database command execution if validation fails.

• Use of stored procedures to abstract data access, allowing the removal of direct permissions to base tables in the database.

• Disabling of default accounts that are not necessary for business requirements.

• Deactivation of unnecessary database functionality, such as unneeded stored procedures, services, or utility packages, and installation of only the required features (surface area reduction).

Low Relevance (Edge Cases and Lesser-known Threats):

• Ensuring that variables are strongly typed.

• Closure of database connections as soon as possible.

• Removal of unnecessary default vendor content, such as sample schemas.

• Connection to the database with distinct credentials for each trust level (e.g., user, read-only user, guest, administrators).

List 2: Database Security Best Practices - Ordered by Complexity

Basic (Beginner):

• Use of strongly typed parameterized queries.

• Ensuring that variables are strongly typed.

• Closure of database connections as soon as possible.

Intermediate:

• Access to the database by the application using the lowest possible level of privilege.

• Use of secure credentials for database access.

• Removal or modification of all default database administrative passwords, ensuring strong passwords/phrases or multi-factor authentication.

• Utilization of input validation and output encoding, ensuring meta characters are properly handled, and prevention of database command execution if validation fails.

• Removal of unnecessary default vendor content, such as sample schemas.

Advanced:

• Storage of connection strings in a separate, encrypted configuration file on a trusted system, avoiding hardcoding within the application.

• Use of stored procedures to abstract data access, allowing the removal of direct permissions to base tables in the database.

• Deactivation of unnecessary database functionality, such as unneeded stored procedures, services, or utility packages, and installation of only the required features (surface area reduction).

• Disabling of default accounts that are not necessary for business requirements.

• Connection to the database with distinct credentials for each trust level (e.g., user, read-only user, guest, administrators).

List 1: File and Memory Management Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Requirement of authentication before allowing file uploads.

• Limitation of uploadable file types to only those necessary for business purposes.

• Validation of uploaded files by checking file headers rather than file extensions alone.

• Prevention or restriction of file uploads that can be interpreted by the web server.

• Deactivation of execution privileges in file upload directories.

• Avoidance of passing user-supplied data into dynamic redirects, or ensuring only validated, relative path URLs are allowed.

• Avoidance of passing user-supplied data directly into dynamic include functions.

• Scanning of user-uploaded files for viruses and malware.

Moderate Relevance (Common Security Concerns):

• Separation of file storage from the application’s web context, with files stored on a content server or in a database.

• Use of a whitelist for referencing existing files, validating file names and types against expected values.

• Replacement of directory or file paths with index values mapped to predefined path lists.

• Ensuring that application files and resources are read-only.

• Safe uploading in UNIX through mounting the target file directory as a logical drive or using the chrooted environment.

Low Relevance (Edge Cases and Lesser-known Threats):

• Avoidance of sending absolute file paths to clients.

• Use of input and output control for untrusted data.

• Verification that buffers are as large as specified.

• Checking of buffer boundaries when functions are called in a loop, ensuring no writes beyond allocated space.

• Truncation of input strings to a reasonable length before using copy or concatenation functions.

• Awareness of potential non-termination of strings when using functions like strncpy(), especially when the destination buffer size matches the source buffer size.

• Explicit closure of resources, avoiding reliance on garbage collection (e.g., connection objects, file handles).

• Avoidance of known vulnerable functions (e.g., printf, strcat, strcpy).

• Proper freeing of allocated memory upon function completion and at all exit points.

• Use of non-executable stacks when available.

List 2: File and Memory Management Best Practices - Ordered by Complexity

Basic (Beginner):

• Avoidance of passing user-supplied data directly into dynamic include functions.

• Avoidance of sending absolute file paths to clients.

• Verification that buffers are as large as specified.

• Checking of buffer boundaries when functions are called in a loop, ensuring no writes beyond allocated space.

• Truncation of input strings to a reasonable length before using copy or concatenation functions.

• Explicit closure of resources, avoiding reliance on garbage collection (e.g., connection objects, file handles).

Intermediate:

• Requirement of authentication before allowing file uploads.

• Limitation of uploadable file types to only those necessary for business purposes.

• Validation of uploaded files by checking file headers rather than file extensions alone.

• Prevention or restriction of file uploads that can be interpreted by the web server.

• Use of input and output control for untrusted data.

• Use of a whitelist for referencing existing files, validating file names and types against expected values.

• Replacement of directory or file paths with index values mapped to predefined path lists.

• Ensuring that application files and resources are read-only.

• Awareness of potential non-termination of strings when using functions like strncpy(), especially when the destination buffer size matches the source buffer size.

Advanced:

• Deactivation of execution privileges in file upload directories.

• Separation of file storage from the application’s web context, with files stored on a content server or in a database.

• Safe uploading in UNIX through mounting the target file directory as a logical drive or using the chrooted environment.

• Avoidance of passing user-supplied data into dynamic redirects, or ensuring only validated, relative path URLs are allowed.

• Scanning of user-uploaded files for viruses and malware.

• Avoidance of known vulnerable functions (e.g., printf, strcat, strcpy).

• Proper freeing of allocated memory upon function completion and at all exit points.

• Use of non-executable stacks when available.

List 1: Communication Security Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Implementation of encryption for transmitting all sensitive information, including the use of TLS for protecting connections. Discrete encryption may supplement this for sensitive files or non-HTTP based connections. TLS certificates must be valid, associated with the correct domain name, unexpired, and installed with intermediate certificates when needed.

• Prevention of fallback to insecure connections upon TLS failure.

• Use of TLS for all content requiring authenticated access and other sensitive information.

• Application of TLS for connections to external systems that handle sensitive information or perform sensitive functions.

• TLS certificate validation (correct domain, unexpired, and with intermediate certificates)

Moderate Relevance (Common Security Concerns):

• Adoption of a single, standardized TLS implementation with proper configuration.

• Specification of character encodings for all connections.

Low Relevance (Edge Cases and Lesser-known Threats):

• Filtering of parameters containing sensitive information from HTTP referer headers when linking to external sites.

List 2: Communication Security Best Practices - Ordered by Complexity

Basic (Beginner):

• Filtering of parameters containing sensitive information from HTTP referer headers when linking to external sites.

• Specification of character encodings for all connections.

Intermediate:

• Use of TLS for all content requiring authenticated access and other sensitive information.

• Application of TLS for connections to external systems that handle sensitive information or perform sensitive functions.

• Adoption of a single, standardized TLS implementation with proper configuration.

Advanced:

• Implementation of encryption for transmitting all sensitive information, including the use of TLS for protecting connections. Discrete encryption may supplement this for sensitive files or non-HTTP based connections. TLS certificates must be valid, associated with the correct domain name, unexpired, and installed with intermediate certificates when needed.

• Prevention of fallback to insecure connections upon TLS failure.

• TLS certificate validation (correct domain, unexpired, and with intermediate certificates)

List 1: System Configuration Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Restriction of web server, process, and service accounts to the least privileges necessary.

• Secure failure handling when exceptions occur.

• Removal of unnecessary functionality and files.

• Assurance that servers, frameworks, and system components are running the latest approved versions.

• Application of all patches issued for the version in use across servers, frameworks, and system components.

• Removal of test code and any non-production functionality prior to deployment.

• Isolation of development environments from the production network, with access restricted to authorized development and test groups.

Moderate Relevance (Common Security Concerns):

• Disabling of unnecessary HTTP methods, such as WebDAV extensions, with well-vetted authentication mechanisms required if file-handling methods are needed.

• Deactivation of directory listings.

• Prevention of directory structure disclosure in the robots.txt file by placing directories not intended for public indexing into an isolated parent directory and disallowing the entire parent directory.

• Removal of unnecessary information from HTTP response headers, such as OS details, web server version, and application framework identifiers.

• Definition of supported HTTP methods, such as GET or POST, and consideration of their use across different application pages.

Low Relevance (Edge Cases and Lesser-known Threats):

• Configuration of both HTTP 1.0 and 1.1 to ensure similarity or proper understanding of any differences, especially regarding extended HTTP methods.

• Capability to output the security configuration store in a human-readable form for auditing purposes.

• Implementation of an asset management system for registering system components and software.

• Implementation of a software change control system to manage and document code changes in both development and production.

List 2: System Configuration Best Practices - Ordered by Complexity

Basic (Beginner):

• Removal of unnecessary functionality and files.

• Deactivation of directory listings.

• Removal of test code and any non-production functionality prior to deployment.

• Definition of supported HTTP methods, such as GET or POST, and consideration of their use across different application pages.

• Removal of unnecessary information from HTTP response headers, such as OS details, web server version, and application framework identifiers.

Intermediate:

• Restriction of web server, process, and service accounts to the least privileges necessary.

• Secure failure handling when exceptions occur.

• Assurance that servers, frameworks, and system components are running the latest approved versions.

• Application of all patches issued for the version in use across servers, frameworks, and system components.

• Disabling of unnecessary HTTP methods, such as WebDAV extensions, with well-vetted authentication mechanisms required if file-handling methods are needed.

• Prevention of directory structure disclosure in the robots.txt file by placing directories not intended for public indexing into an isolated parent directory and disallowing the entire parent directory.

Advanced:

• Isolation of development environments from the production network, with access restricted to authorized development and test groups.

• Configuration of both HTTP 1.0 and 1.1 to ensure similarity or proper understanding of any differences, especially regarding extended HTTP methods.

• Capability to output the security configuration store in a human-readable form for auditing purposes.

• Implementation of an asset management system for registering system components and software.

• Implementation of a software change control system to manage and document code changes in both development and production.

List 1: Cloud Security Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Implementation of strong identity and access management (IAM) controls to enforce least privilege and limit access to cloud resources.

• Encryption of sensitive data both in transit and at rest using industry-standard encryption protocols.

• Regular monitoring and auditing of cloud environments for unusual activity and potential security incidents.

• Implementation of multi-factor authentication (MFA) for all user accounts, especially privileged accounts.

• Application of security patches and updates to cloud infrastructure, operating systems, and applications.

• Use of cloud provider-native security services (e.g., firewalls, DDoS protection, key management) to secure cloud environments.

Moderate Relevance (Common Security Concerns):

• Establishment of strong backup and disaster recovery plans for critical cloud-based data and applications.

• Ensuring proper network segmentation in cloud environments to isolate sensitive resources.

• Regular review and audit of third-party cloud service providers' security practices and certifications.

• Monitoring and securing API endpoints to prevent unauthorized access or abuse.

Low Relevance (Edge Cases and Lesser-known Threats):

• Implementation of data loss prevention (DLP) solutions to detect and prevent unauthorized sharing of sensitive information.

• Conducting regular penetration testing of the cloud environment to identify vulnerabilities.

• Implementation of container and serverless security best practices for microservices-based cloud deployments.

• Continuous training and awareness programs for cloud users and administrators to prevent phishing and social engineering attacks.

• Regular review of cloud service-level agreements (SLAs) to ensure compliance with security and privacy requirements.

List 2: Cloud Security Best Practices - Ordered by Complexity

Basic (Beginner):

• Implementation of multi-factor authentication (MFA) for all user accounts, especially privileged accounts.

• Encryption of sensitive data both in transit and at rest using industry-standard encryption protocols.

• Application of security patches and updates to cloud infrastructure, operating systems, and applications.

• Establishment of strong backup and disaster recovery plans for critical cloud-based data and applications.

• Continuous training and awareness programs for cloud users and administrators to prevent phishing and social engineering attacks.

Intermediate:

• Implementation of strong identity and access management (IAM) controls to enforce least privilege and limit access to cloud resources.

• Regular monitoring and auditing of cloud environments for unusual activity and potential security incidents.

• Use of cloud provider-native security services (e.g., firewalls, DDoS protection, key management) to secure cloud environments.

• Ensuring proper network segmentation in cloud environments to isolate sensitive resources.

• Regular review and audit of third-party cloud service providers' security practices and certifications.

Advanced:

• Monitoring and securing API endpoints to prevent unauthorized access or abuse.

• Implementation of data loss prevention (DLP) solutions to detect and prevent unauthorized sharing of sensitive information.

• Conducting regular penetration testing of the cloud environment to identify vulnerabilities.

• Implementation of container and serverless security best practices for microservices-based cloud deployments.

• Regular review of cloud service-level agreements (SLAs) to ensure compliance with security and privacy requirements.

List 1: Mobile Application Security Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Implementation of strong authentication and authorization mechanisms, such as multi-factor authentication (MFA) and secure token management.

• Encryption of sensitive data both in transit and at rest using strong encryption standards.

• Regularly updating the mobile app and its dependencies to apply security patches and address known vulnerabilities.

• Protection of sensitive user data, including personally identifiable information (PII), by adhering to privacy regulations and minimizing data collection.

• Secure storage of sensitive information, such as passwords and tokens, using device-provided secure storage mechanisms (e.g., Keychain for iOS, Keystore for Android).

Moderate Relevance (Common Security Concerns):

• Implementation of secure coding practices to prevent common vulnerabilities such as SQL injection, buffer overflows, and cross-site scripting (XSS).

• Secure communication between the mobile app and backend services, ensuring SSL/TLS is properly configured.

• Use of secure APIs, ensuring proper validation and authorization for accessing backend services.

• Protection against reverse engineering through code obfuscation and securing the app's source code.

• Regular security testing and vulnerability assessments, including penetration testing.

Low Relevance (Edge Cases and Lesser-known Threats):

• Prevention of data leakage by restricting app permissions to only those necessary for functionality.

• Implementation of tamper detection mechanisms, such as checking for jailbroken/rooted devices.

• Monitoring of the mobile app for suspicious activity and potential security incidents.

• Use of in-app security tools (e.g., runtime application self-protection) to monitor and defend against threats in real-time.

• Proper management and revocation of user sessions and tokens to prevent unauthorized access to services.

List 2: Mobile Application Security Best Practices - Ordered by Complexity

Basic (Beginner):

• Regularly updating the mobile app and its dependencies to apply security patches and address known vulnerabilities.

• Encryption of sensitive data both in transit and at rest using strong encryption standards.

• Secure storage of sensitive information, such as passwords and tokens, using device-provided secure storage mechanisms (e.g., Keychain for iOS, Keystore for Android).

• Implementation of strong authentication and authorization mechanisms, such as multi-factor authentication (MFA) and secure token management.

• Protection of sensitive user data, including personally identifiable information (PII), by adhering to privacy regulations and minimizing data collection.

Intermediate:

• Implementation of secure coding practices to prevent common vulnerabilities such as SQL injection, buffer overflows, and cross-site scripting (XSS).

• Secure communication between the mobile app and backend services, ensuring SSL/TLS is properly configured.

• Use of secure APIs, ensuring proper validation and authorization for accessing backend services.

• Protection against reverse engineering through code obfuscation and securing the app's source code.

• Prevention of data leakage by restricting app permissions to only those necessary for functionality.

Advanced:

• Regular security testing and vulnerability assessments, including penetration testing.

• Monitoring of the mobile app for suspicious activity and potential security incidents.

• Implementation of tamper detection mechanisms, such as checking for jailbroken/rooted devices.

• Use of in-app security tools (e.g., runtime application self-protection) to monitor and defend against threats in real-time.

• Proper management and revocation of user sessions and tokens to prevent unauthorized access to services.