Unofficial Application Programming Guide

This application programming guide outlines some basic security issues to keep in mind when developing applications and performing code reviews. It specifies several areas of application to consider including user input, program file dependencies and system settings, accounts and passwords, storage of data, and program operation and functionality. This application programming guide is intended to provide a brief list of security areas and items to consider while developing or reviewing code.

1.0 User Input


  1. Through forms
  2. Through the network
  3. Through files

Consider all methods that input from the user is received by the program.


  1. Consider SQL command statement injection into the user input
  2. Consider possible escape characters, special characters, quotes, semicolons, colons and other special characters in the user input that the program may process differently or improperly.
  3. How will the program handle the user leaving input values blank?
  4. How will the program handle input of illegal values such as negative numbers which should cause error messages?
  5. Prevent buffer overflow by limiting length of user input whether through forms or other communication such as through the network.
  6. Can the source of the data or program input be faked?
  7. If the data or program input is not available, how will the program handle it?

2.0 File dependencies and system settings

Types of files the application may use:

  1. Configuration
  2. Library files
  3. Executable
  4. System registry
  5. System environment variables
  6. Data files
  7. Command line switches and program settings


  1. Check for success or failure when accessing:
    1. Libraries such as system libraries used to support code.
    2. Configuration files or other files such as data files for reading or writing.
    3. Other executable files.
  2. Check for file corruption or wrong version, or unauthorized file modification when possible. Ways to know if the file is modified or corrupt is to do a CRC check, examine the size and date of the file to tell if it is correct.
  3. Can any unusual program settings or command line switches cause unpredictable program behavior?
  4. Be aware of what information is stored in local or remote files, the system registry, or in the system environment or other system files that the program either depends on, modifies, or can change the behavior of the program. Ask:
    1. Is this information sensitive?
    2. If it is changed without authorization, can it affect the security of my program or data?
    3. Can unauthorized persons change these registry values, environment values, or other system files without proper access?
    4. If a file is corrupt how can my program or data be affected? Can the program test the file to tell whether it is corrupt?
    5. Can the program be fooled into using a file with the same name in a different directory than the intended file due to the environment path as it is used to search for files?

3.0 Accounts and Passwords - access

  1. Are test accounts still active in the application when it is made public?
  2. Are default accounts and passwords known which may allow unauthorized access?
  3. Are all undocumented accounts removed from the program?
  4. Where are accounts and passwords stored and are they encrypted?
  5. How many levels of access exist and is data sensitive?

4.0 Storage

  1. Cookies - Be careful about what data you have your application store in cookies. Consider these possibilities:
    1. A browser vulnerability allows an attacker to get all client cookies.
    2. Cookies are sniffed by an attacker while traveling over the internet.
    3. Someone unintended read the cookies while stored in the client computer temporary folder.
  2. Temporary data storage
    1. Does the program store sensitive data in temporary files directly or indirectly using system calls?
    2. Does the program store sensitive data in memory?

5.0 Program operation and functionality

  1. Ports
    1. Are the ports opened by the application intended to be open and is input and output through them handled securely? Is the input protected against buffer overflow, SQL or special data injection, and malformed input?
    2. Can the application open additional ports and will this compromise security?
  2. Testing procedures and loadable modules
    1. Are testing procedures and loadable modules either removed or made secure?
    2. Can any test code be used to bypass normal authentication or security controls?
  3. Program functionality:
    1. Can program functionality or commands be executed over and over in an effort to ultimately deny service to users?
    2. How many methods can be used to execute a program function and are all these methods secure?
    3. Are testing procedures and loadable modules either removed or made secure? Can any test code be used to bypass normal authentication or security controls?
  4. Program security checks
    1. When the program checks data, can an attacker substitute false data?
    2. Is there enough time between when the data is checked to when the data is used for an attacker to substitute false data?

6.0 Error Checking

  1. Provide least privilege in the case of an error - When testing for errors in a process, if the exact condition is not met, do not allow the action to take place. For example if testing to determine whether user access is allowed to some program function, do not allow the operation only if access is denied.
  2. Only allow the operation if access is allowed. This way if an additional error occurs such as a buffer overflow or a library is not available, security is not compromised.