This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Secure Coding Cheat Sheet"

From OWASP
Jump to: navigation, search
(Migration to GitHub of the project)
 
(117 intermediate revisions by 4 users not shown)
Line 1: Line 1:
−
= DRAFT CHEAT SHEET - WORK IN PROGRESS =
+
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>
 +
 
 +
__NOTOC__
 +
 
 +
= IMPORTANT =
 +
 
 +
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!
 +
 
 +
An [https://github.com/OWASP/CheatSheetSeries/issues/13 open discussion] is pending about to exclude or not this cheat sheet of the V2 of the project.
 +
 
 
= Introduction =
 
= Introduction =
−
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.  
+
The goal of this document is to create high level guideline for secure coding practices. The goal is to keep the overall size of the document condensed and easy to digest. Individuals seeking addition information on the specific areas should refer to the included links to learn more.
 +
 
 
= How To Use This Document =
 
= 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.  
 
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.  
−
= Authentication=
+
 
−
== Password Complexity ==
+
= Secure Coding Policy =
−
Applications should have a password complexity requirement of:
+
Always maintain a secure coding policy. List down the activities that are related to maintenance of secure coding standards (would these standards be technology specific or technology agnostic), feedback of code review output to training, input data validation, output data validation etc
−
* 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]
+
Why should you be having a secure coding policy? It helps in maintaining consistency across organisation and helps in vertical and horizontal scaling of usage of standards for web development projects.
−
== Password Rotation ==
+
 
−
Password rotation should be required for privileged accounts within applications at a frequency of every 90 days
+
= User Authentication =
−
== Online Attack Guessing  ==
+
 
−
Applications must defend against online password guessing attempts by one of the following methods:
+
Please see https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Utilize_Multi-Factor_Authentication
−
* Account Lockout - Lock account after 5 failed password attempts
+
 
−
* Temporary Account Lockout- Temporarily lock account after 5 failed password attempts
+
= Password Complexity =
−
* Anti-automation Captcha - Require a captcha to be successfully completed after 5 failed password attempts
+
 
−
== Password Reset Functions ==
+
Please see [https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Implement_Proper_Password_Strength_Controls https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Implement_Proper_Password_Strength_Controls].
−
== 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 Management =
−
== Session ID Length ==
+
 
−
* Session tokens should be 128-bit or greater
+
Please see https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
−
== 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
 
−
== Logout ==
 
−
* 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 =
 
= 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 =
+
Please see https://www.owasp.org/index.php/Access_Control_Cheat_Sheet
−
== 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:
+
= Input Data Validation =
−
* 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)
+
Please see https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet
−
* 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 =
 
= Output Encoding =
−
== Preventing XSS and Content Security Policy ==
 
−
== Preventing SQL Injection ==
 
−
== Preventing OS Injection ==
 
−
== Preventing XML Injection ==
 
  
−
= Cross Domain Request Forgery =
+
Please see https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet#Output_Encoding
−
== Preventing CSRF ==
+
 
−
== Preventing Malicious Site Framing (ClickJacking) ==
+
= Secure Transmission / Network Layer security =
−
== 3rd Party Scripts ==
+
 
−
== Connecting with Twitter, Facebook, etc ==
+
Please see https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Benefits
 +
 
 +
= File Uploads =  
 +
 
 +
Please see https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet#File_Uploads
 +
 
 +
= Error Handling =
 +
 
 +
Please see https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet#Error_Handling
 +
 
 +
= Logging and Auditing =
 +
 
 +
Please see https://www.owasp.org/index.php/Logging_Cheat_Sheet
 +
 
 +
= Cryptography =
 +
 
 +
Please see https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet
 +
 
 +
= Cookie Management =
 +
 
 +
Please see https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Cookies
 +
 
 +
= Unvalidated Redirects and Forwards Cheat Sheet =
 +
 
 +
Please see https://www.owasp.org/index.php/Unvalidated_Redirects_and_Forwards_Cheat_Sheet
 +
 
 +
= SQL Injection =
 +
 
 +
Please see https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
 +
 
 +
= Cross Site Scripting =
 +
 
 +
Please see https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet
 +
 
 +
Please see https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
 +
 
 +
Please see https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
 +
 
 +
= Cross Site Request Forgery =
 +
 
 +
Please see https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
  
−
= Secure Transmission =
+
= Preventing Malicious Site Framing (ClickJacking) =
−
== When To Use SSL/TLS ==
 
−
== Don't Allow HTTP Access to Secure Pages ==
 
−
== Implement STS ==
 
  
 +
Please see https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet#Defending_with_X-Frame-Options_Response_Headers
  
−
== References ==
+
= Insecure Direct Object references =
  
−
{{Cheatsheet_Navigation}}
+
Please see https://www.owasp.org/index.php/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet
  
−
[[Category:Cheatsheets]]
+
{{taggedDocument| type=delete| comment=Tagged via fixme/delete.}}

Latest revision as of 10:26, 16 February 2019

Cheatsheets-header.jpg


IMPORTANT

The Cheat Sheet Series project has been moved to GitHub!

An open discussion is pending about to exclude or not this cheat sheet of the V2 of the project.

Introduction

The goal of this document is to create high level guideline for secure coding practices. The goal is to keep the overall size of the document condensed and easy to digest. Individuals seeking addition information on the specific areas should refer to the included links to learn more.

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.

Secure Coding Policy

Always maintain a secure coding policy. List down the activities that are related to maintenance of secure coding standards (would these standards be technology specific or technology agnostic), feedback of code review output to training, input data validation, output data validation etc

Why should you be having a secure coding policy? It helps in maintaining consistency across organisation and helps in vertical and horizontal scaling of usage of standards for web development projects.

User Authentication

Please see https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Utilize_Multi-Factor_Authentication

Password Complexity

Please see https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Implement_Proper_Password_Strength_Controls.

Session Management

Please see https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

Access Control

Please see https://www.owasp.org/index.php/Access_Control_Cheat_Sheet

Input Data Validation

Please see https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet

Output Encoding

Please see https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet#Output_Encoding

Secure Transmission / Network Layer security

Please see https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Benefits

File Uploads

Please see https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet#File_Uploads

Error Handling

Please see https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet#Error_Handling

Logging and Auditing

Please see https://www.owasp.org/index.php/Logging_Cheat_Sheet

Cryptography

Please see https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet

Cookie Management

Please see https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Cookies

Unvalidated Redirects and Forwards Cheat Sheet

Please see https://www.owasp.org/index.php/Unvalidated_Redirects_and_Forwards_Cheat_Sheet

SQL Injection

Please see https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

Cross Site Scripting

Please see https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet

Please see https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

Please see https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

Cross Site Request Forgery

Please see https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

Preventing Malicious Site Framing (ClickJacking)

Please see https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet#Defending_with_X-Frame-Options_Response_Headers

Insecure Direct Object references

Please see https://www.owasp.org/index.php/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet


This page has been recommended for deletion.
You can help OWASP by improving it or discussing it on its Talk page. See FixME
Comment: Tagged via fixme/delete.
Retrieved from "https://wiki.owasp.org/index.php?title=Secure_Coding_Cheat_Sheet&oldid=247583"