May 17, 2021

Secure Coding Checklist

The intention of this checklist is to aid the developer, code reviewer, and AppSec professional in identifying existing vulnerable code that needs to be remediated. As well as creating new standards for new code that will be developed in the future.

Initial Recon

  • Check for vulns in dependencies
  • Check the attack surface of the application for missing input validation that reaches out to the client.
  • Check for hard-coded credentials in the application and config files.

Encrypted in Transit

  • Check that TLS 1.2 or greater is used for connectivity between server and client.
  • Check that the web application is partitioned into private and public URLs to protect anything that should be private.
  • Check that sensitive data has been secured in memory, storage and transit.

Registration Process

  • Check for response messages to the client on registration that allow for user enumeration.
  • Check for the existence of rate limiting during the registration process to limit brute forcing the existing usernames.

Authentication

  • Check the response message to client for incorrect username or an incorrect password. They should be the same to combat user enumeration efforts by an attacker.
  • Check that password hashes are using well-known framework or crypto library. Do not attempt to create crypto in-house, you’re not that good at it.
  • Check that users are unable to login using a GET request. Only POST request should be used.
  • Check that username minimum length is greater that 14 characters.
  • Check for strong password policy. Require passwords greater that 14 characters with as many character sets as possible. The maximum length of a password should be huge, like 128 or 256 chars.

Session Management

  • Check how session management is handled in the application and look for opportunities for an attacker to use a forged session ID.
  • Check that session cookies are encrypted and have a length of at least 128 bits and are complex.
  • Check that session cookies are not persistent.
  • Check that session cookies use HttpOnly, Secure, SameSite cookie attributes
  • Check that session tokens are not passed in URL parameters
  • Check for generation of a new session identifier and deactivate the old one periodically. This can mitigate certain session hijacking scenarios where the original identifier was compromised.
  • Check that the application does not allow concurrent logins with the same user ID

Data Validation

  • Check that all user input is validated for proper type, length, format, and range
  • Check that input validation is done server side. Never trust the client.
  • Check that any uploaded files are validated for content type, size, file type, and filename.
  • Check that special characters are sanitized (escaped or replaced) before being used in operations to be performed on the database.
  • Check if invalid input will result in a handled exception. Unhandled exceptions may lead to further exploitation or DoS conditions.

Application Output

  • Check that all page output is properly encoded
  • Check that all header output is URL encoded
  • Check that cache headers are properly set on sensitive data
  • Check that security headers are properly set on the application
  • Check that sensitive application information is not revealed to the user
  • Check that error messages don’t reveal sensitive information
  • Check that error messages aren’t user controllable

Cryptography

  • Check that user passwords are hashed and uniquely salted per user.
  • Check that salts are unique per user. Don’t use a hard-coded salt string that used for all users hashes.
  • Check for old busted and known weak ciphers (RC4), cryptographic hash functions (MD5) and insecure random number generation that don’t employ enough entropy to be effective.

Log Management

  • Check that all sensitive system and user actions are logged with the following: Where, What, When, Who, How responded to.
  • Check that no sensitive info is getting logged.
  • Check that user input is not trusted, and is sanitized before being placed in application logs.