The following is a developer-centric defensive cheat sheet for the 2013 release of the OWASP Top Ten Project. It also presents a quick reference based on OWASP Testing Project to help how to identify the risks.

OWASP Top Ten Cheat Sheet

A1 Injection

Presentation

Render:

Set a correct content type

Set safe character set (UTF-8)

Set correct locale

On Submit:

Enforce input field type and lengths.

Validate fields and provide feedback.

Ensure option selects and radio contain only sent values.

Controller

Canonicalize using correct character setPositive input validation using correct character set

(NR) Negative input validation.
(LR) Sanitize input.

Tip: updating a negative list (such as looking for "script", "sCrIpT", "ßCrîpt", etc) will require expensive and constant deployments and will always fail as attackers work out your list of "bad" words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism.

Model

Validate role is sufficient to create, read, update, or delete data

Tip: Consider the use of a "governor" to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.

A6 Sensitive Data Exposure

Presentation

Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).

Use strong hashes (SHA 256 or better) with salts for passwords.

Protect keys more than any other asset.

Use TLS 1.2 or later for all web communications.

Buy extended validation (EV) certificates for public web servers.

Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.

Render:

Do not send keys or hashes to the browser.

Controller

Design:

Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).

Use strong hashes (SHA 256 or better) with salts for passwords.

Protect keys more than any other asset.

Mandate strong encrypted communications between web and database servers and any other servers or administrative users.

Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen.

Tip: It is best to encrypt data on the application server, rather than the database server.

Model

Design:

Mandate strong encrypted communications with application servers and any other servers or administrative users.

Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being "encrypted" on disk.

A7 Missing Function Level Access Control

Presentation

Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar.

Ensure every page requires a role, even if it is "guest".

Pre-render:

Validate user is authenticated.

Validate role is sufficient to view secured URL.

Render:

Send CSRF token.

Controller

Validate user is authenticated.

Validate role is sufficient to perform secured action.

Validate CSRF token.

Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming.

Tip: Assume attackers will learn where "hidden" directories and "random" filenames are, so do not store these files in the web root, even if they are not directly linked.