Secure Coding Cheat Sheet

Revision as of 00:05, 17 November 2011 by MichaelCoates (talk | contribs)

Jump to: navigation, search



The goal of this document is to create a high level guideline for secure coding practices within an application. The material is concise and the goal is to keep the overall size of the document condensed and easy to digest.

How To Use This Document

The information listed below are generally acceptable secure coding practices; however, it is recommend that organizations consider this a base template and update individual sections with secure coding recommendations specific to the organization's policies and risk tolerance.


Password Complexity

Applications should have a password complexity requirement of:

  • Passwords must be 8 characters or greater
  • Passwords must require 3 of the following 4 character types [upper case letters, lower case letters, numbers, special characters]

Password Rotation

Password rotation should be required for privileged accounts within applications at a frequency of every 90 days

Online Attack Guessing

Applications must defend against online password guessing attempts by one of the following methods:

  • Account Lockout - Lock account after 5 failed password attempts
  • Temporary Account Lockout- Temporarily lock account after 5 failed password attempts
  • Anti-automation Captcha - Require a captcha to be successfully completed after 5 failed password attempts

Password Reset Functions

Email Verification Functions

If the application requires verification of ownership of an email address then observe the following

  • Email verification links should only satisfy the requirement of verify email address ownership and should not provide the user with an authenticated session (e.g. the user must still authenticate as normal to access the application).
  • Email verification codes must expire after the first use or expire after 8 hours if not used.

Password Storage

  • Passwords should be stored in a format, such as Bcrypt, that is resistant to high speed offline brute force attacks
  • Password storage using hashing algorithms plus a per user salt are good, but not sufficient.

Session Management

Session ID Length

  • Session tokens should be 128-bit or greater

Session ID Creation

  • The session tokens should be handled by the web server if possible or generated via a cryptographically secure random number generator.

Inactivity Time Out

  • Authenticated sessions should timeout after determined period of inactivity - 15 minutes is recommended.

Secure Flag

  • The "Secure" flag should be set during every set-cookie. This will instruct the browser to never send the cookie over HTTP. The purpose of this flag is to prevent the accidental exposure of a cookie value if a user follows an HTTP link.

HTTP-Only Flag

  • The "HTTP-Only" flag should be set to disable malicious script access to the cookie values, such as the session ID


  • Upon logout the session ID should be invalidated on the server side and deleted on the client via expiring and overwriting the value.

Access Control

Presentation Layer

  • It is recommended to not display links or functionality that is not accessible to a user. The purpose is to minimize unnecessary access controls messages and minimize privileged information from being unnecessarily provided to users.

Business Layer

  • Ensure that an access control verification is performed before an action is executed within the system. A user could craft a custom GET or POST message to attempt to execute unauthorized functionality.

Data Layer

  • Ensure that an access control verification is performed to check that the user is authorized to act upon the target data. Do not assume that a user authorized to perform action X is able to necessarily perform this action on all data sets.

Input Validation

Goal of Input Validation

Input validation is performed to minimize malformed data from entering the system. Input Validation is NOT the primary method of preventing XSS, SQL Injection. These are covered in output encoding below.

Input Validation Must Be:

  • Applied to all user controlled data
  • Define the types of characters that can be accepted (often U+0020 to U+007E, though most special characters could be removed and control characters are almost never needed)
  • Defines a minimum and maximum length for the data (e.g. {1,25} )

JavaScript vs Server Side Validation

Positive Approach

Robust Use of Input Validation

Validating Rich User Content

File Upload

Output Encoding

Preventing XSS and Content Security Policy

Preventing SQL Injection

Preventing OS Injection

Preventing XML Injection

Cross Domain Request Forgery

Preventing CSRF

Preventing Malicious Site Framing (ClickJacking)

3rd Party Scripts

Connecting with Twitter, Facebook, etc

Secure Transmission

When To Use SSL/TLS

Don't Allow HTTP Access to Secure Pages

Implement STS


OWASP Cheat Sheets Project Homepage