OWASP Cheat Sheet Series

= Main =  

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
 * valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

Our goal
The OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific application security topics. These cheat sheets were created by various application security professionals who have expertise in specific topics. We hope that the OWASP Cheat Sheet Series provides you with excellent security guidance in an easy to read format.

If you have any questions about the OWASP Cheat Sheet Series, please email the project leader [mailto:jim.manico@owasp.org Jim Manico], subscribe to our project email list or contact us on the project's Slack channel.

Important notice about project cleanup
In order to made the collection of Cheat Sheet more consistant and more easy to maintains, we have decided to remove a set of CS.

The set have been defined using the following criteria:
 * The CS is in draft since a long time (at least 1 year).
 * The current content of the CS do not bring a direct pragmatic/practical added value to developers or architects.

If you want to cancel the removal of a CS then contact the project leaders using Mail or Slack channel.

We let 1 month to the community to contact us before to start the cleanup.

The set is composed by the following CS:
 * AJAX_Security_Cheat_Sheet
 * Content do not bring useful infos.
 * Authentication_Cheat_Sheet_Espa%C3%B1ol
 * We have an english version.
 * Denial_of_Service_Cheat_Sheet
 * DOS should be handled by a dedicated external service or device.
 * DRAFT_Denial_of_Service_Cheat_Sheet
 * Draft
 * OWASP_Top_Ten_Cheat_Sheet
 * Usage of the OWASP TOP 10 is preferred.
 * Query_Parameterization_Cheat_Sheet_(Hawaiian_Pidgin_English)
 * We have an english version.
 * Secure_Coding_Cheat_Sheet
 * Usage of OWASP ASVS and MASVS is preferred.
 * Secure_SDLC_Cheat_Sheet
 * Usage of OWASP Open SAMM is preferred.
 * Security_Testing_Cheat_Sheet
 * Usage of OWASP OTG and MSTG is preferred.
 * Threat_Modeling_Cheat_Sheet
 * Usage of OWASP Threat Dragon or dedicated OWASP project is preferred.
 * Web_Application_Security_Testing_Cheat_Sheet
 * Usage of OWASP OTG and MSTG is preferred.
 * Web_Service_Security_Cheat_Sheet
 * Same remark like above.
 * Web_Service_Security_Testing_Cheat_Sheet
 * Same remark like above.
 * Application_Security_Architecture_Cheat_Sheet
 * Draft.
 * AppSensor_Cheat_Sheet
 * Draft.
 * Business_Logic_Security_Cheat_Sheet
 * Draft.
 * Grails_Secure_Code_Review_Cheat_Sheet
 * Draft.
 * PHP_Security_Cheat_Sheet
 * Draft.

Authors
Project Leaders: Jim Manico and Dominique Righetto [mailto:dominique.righetto@owasp.org @]

Contributors: Paweł Krawczyk, Mishra Dhiraj, Shruti Kulkarni, Torsten Gigler, Michael Coates, Jeff Williams, Dave Wichers, Kevin Wall, Jeffrey Walton, Eric Sheridan, Kevin Kenan, David Rook, Fred Donovan, Abraham Kang, Dave Ferguson, Shreeraj Shah, Raul Siles, Colin Watson, Neil Matatall, Zaur Molotnikov and many more!

OWASP Cheat Sheets

 * valign="top" style="padding-left:25px;width:200px;" |

Slack & Twitter
Slack channel information:
 * Server
 * Channel

Twitter hash tag: #owaspcheatsheetseries

Book
A PDF book of all Cheat Sheets can be downloaded here.

Email List
Project Email List

Licensing
The OWASP Cheat Sheet Series is free to use under the Creative Commons ShareAlike 3 License.

Related Projects

 * OWASP Proactive Controls
 * OWASP Application Security Verification Standard Project

News and Events

 * [Jul 15 2018] Error Handling Cheat Sheet added to project
 * [Jun 12 2018] Made available the PDF book of all Cheat Sheets
 * [May 10 2018] Protect File Upload Against Malicious File Cheat Sheet updated
 * [Mar 18 2018] Password Storage Cheat Sheet updated
 * [Feb 21 2018] HTML5 Security Cheat Sheet updated
 * [Feb 18 2018] Password Storage Cheat Sheet updated
 * [Jan 14 2018] Insecure Direct Object Reference Prevention Cheat Sheet updated
 * [Dec 04 2017] Ruby On Rails Cheat Sheet updated
 * [Nov 19 2017] JWT Cheat Sheet for Java updated
 * [Nov 17 2017] OS Command Injection Defense Cheat Sheet added to project
 * [Nov 04 2017] Authorization Testing Automation Cheat Sheet added to project
 * [Jan 17 2017] XML Security Cheat Sheet added to project
 * [Feb 06 2016] New navigation template rolled out project-wide
 * [Jun 11 2015] SAML Cheat Sheet added to project
 * [Feb 11 2015] Cheat Sheet "book" added to project
 * [Apr 04 2014] All non-draft cheat sheets moved to new wiki template!
 * [Feb 04 2014] Project-wide cleanup started


 * }

= Master Cheat Sheet =

Authentication
Ensure all entities go through an appropriate and adequate form of authentication. All the application non-public resource must be protected and shouldn't be bypassed.

For more information, check Authentication Cheat Sheet

Session Management
Use secure session management practices that ensure that authenticated users have a robust and cryptographically secure association with their session.

For more information, check Session Management Cheat Sheet

Access Control
Ensure that a user has access only to the resources they are entitled to. Perform access control checks on the server side on every request. All user-controlled parameters should be validated for entitlemens checks. Check if user name or role name is passed through the URL or through hidden variables. Prepare an ACL containing the Role-to-Function mapping and validate if the users are granted access as per the ACL.

For more information, check Access Control Cheat Sheet

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.

For more information, check Input Validation Cheat Sheet

Output Encoding
Output encoding is the primary method of preventing XSS and injection attacks. Input validation helps minimize the introduction of malformed data, but it is a secondary control.

For more information, check XSS (Cross Site Scripting) Prevention Cheat Sheet.

Cross Domain
Ensure that adequate controls are present to prevent against Cross-site Request Forgery, Clickjacking and other 3rd Party Malicious scripts.

For more information, check Cross Site Request Forgery

Secure Transmission
Ensure that all the applications pages are served over cryptographically secure HTTPs protocols. Prohibit the transmission of session cookies over HTTP.

For more information, check Transport Protection Cheat Sheet

Logging
Ensure that all the security related events are logged. Events include: User log-in (success/fail); view; update; create, delete, file upload/download, attempt to access through URL, URL tampering. Audit logs should be immutable and write only and must be protected from unauthorized access.

For more information, check Logging Cheat Sheet

Uploads
Ensure that the size, type, contents, and name of the uploaded files are validated. Uploaded files must not be accessible to users by direct browsing. Preferably store all the uploaded files in a different file server/drive on the server. All files must be virus scanned using a regularly updated scanner.

For more information, check https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet#File_Uploads

= Roadmap =

Global:


 * Bring all cheat sheets out of draft fin end of 2018.
 * Go through the cheat sheets to make sure what they recommend is consistent with ASVS.
 * Move all code snippets of CS from pre tag to syntaxhighlight tag to enhance CS readability.
 * Find a way to automate the generation of a PDF referential file gathering all CS ( Work in progress by Dominique Righetto ).
 * Go through the cheat sheets to make sure they follow the CS guideline.
 * Create branding stickers for the project.
 * Remove CS that that do not bring added value.

Next work on Cheat Sheets (CS) and work assignment:


 * Ruby On Rails CS:
 * Action: CS complete refactoring.
 * People in charge: Zaur Molotnikov.
 * Status: Work in progress.
 * General OAuth introduction CS:
 * Action: Create it.
 * People in charge: Simon Bennetts & Jim Manico.
 * Status: Work in progress.
 * OAuth and OIDC for SPA Applications CS:
 * Action: Create it.
 * People in charge: Simon Bennetts & Jim Manico.
 * Status: Work in progress.
 * Credential Stuffing Prevention CS:
 * Action: Refresh it.
 * People in charge: Michael Coates & Jim Manico.
 * Status: Work in progress.
 * Serverless CS:
 * Action: Create it.
 * People in charge: Paul Ionescu.
 * Status: Work in progress.
 * Server Side Request Forgery Defense CS:
 * Action: Create it.
 * People in charge: Not assigned.
 * Status: In backlog.
 * Forgot Password CS:
 * Action: Add a POC in order to provide actionable code.
 * People in charge: Not assigned.
 * Status: In backlog.
 * OS Command Injection Defense CS:
 * Action: Add information about system command escaping.
 * People in charge: Not assigned.
 * Status: In backlog.
 * Best practices about security handling in a Source Code Management system (ex: GitHub, GitLab, Bitbucket...) CS:
 * Action: Create it.
 * People in charge: Not assigned.
 * Status: In backlog.
 * Sources (among others): https://snyk.io/blog/ten-git-hub-security-best-practices/
 * SNYK source usage authorization: https://twitter.com/righettod/status/1006558576289177600

= Cheat sheet Guideline =

Cheat sheet content
The key points that all cheat sheets (called CS) must provides are the following:


 * 1) Address a single topic (ex: password storage, OS command injection, REST service, CSRF, HTML5 new features security...).
 * 2) Be concise and focused: A cheat sheet must be directly actionable (a CS is not a guide) and must be directly useful for a developer.
 * 3) Do not re-address topic handled by others CS. In this case, the target CS will be enhanced with missing points.
 * 4) When applicable, provide a solution proposal implementation through a full documented POC on a public well know Git repository (GitHub is highly prefered), the POC can be used as a playground for a developer wanting to play/evaluate your solution proposal.

Cheat sheet structure
A CS must have these sections:


 * 1) Introduction: Provide high level information about the topic in order to introduce it to people that do not know it. You can add pointer to external sources if needed but at least give an overview allowing a reader to continue on the CS. You can also add schema or diagram in any part of the CS but be sure to respect the copyright of the source file.
 * 2) Context: Describe the security issues that are bring or commonly meet when someone must work on this topic.
 * 3) Objective: Describe the objective of the CS. What the CS will bring to the reader?
 * 4) Proposition:
 * 5) Describe how to address the security issues in a possible technology agnostic approach.
 * 6) Using your POC, describe your solution proposal in the more teaching possible way.
 * 7) Sources of the prototype: Add pointer to the public GitHub repository on which the source code of POC is hosted.

For the code snippet, use the mediawiki tag syntaxhighlight:
 * Tag documentation.
 * Supported languages.

If you want to be careful in order to prevent to break something in the target existing CS, you can follow this contribution procedure:
 * 1) Take a copy of the CS that you want to enhance (mediawiki syntax in the source tab).
 * 2) Add your enhancement and publish the updated CS on the same GitHub repository than your POC (it support the mediawiki syntax).
 * 3) Notify the CS Community using this mailing list and the CS Community will review the CS using GitHub comments system.
 * 4) When the feedback loop is finished, the CS Community will help you to have right access to the wiki in order to update the CS.

Cheat sheet template
If the target CS is a new one then please use the following template struture.

It allow you to work:
 * Online by using the wiki Show preview option.
 * Offline by using an text editor like Atom with the mediawiki plugin.

= Project Logo =

This section contains the information that we have gathered and plan to use for the creation of the project logo and related design materials.

The first phase of the work is to commission a project logo.

Introduction
The project requires a logo which will comprise three components:


 * Graphical element indicating the idea or use of the cheat sheets
 * The project title
 * Motto/straplines.

Not all of these will necessarily be shown together at the same time. Phase 1 requires the creation of a logo, which may be used with one, two or all three of these components.

The logo will be used in many ways such as on a website banner, or just the graphical element on a bag, or the graphical element and a motto/strapline on a t-shirt. These other outputs are not included in the scope of Phase 1.

Project Name
The project name is OWASP Cheat Sheet Series project. The project name will be positioned next to the graphical element in some outputs, and this layout must be provided. In other cases, the project name will not be included beside the logo.

Motto/Strapline
Three mottos/straplines will be used in the logo - they are context dependent:


 * Life is too short, AppSec is tough, Cheat!
 * Its not cheating if you do it for the right reasons
 * Sometimes the only good thing to do is cheat.

The logo layout must allow for any of these or none to be included.

Layout, Media Formats and Colours
Some media or placements may mean the motto/strapline does not fit or is not needed. Therefore the logo must be usable with, or without, the motto/strapline.

The logo will need to be used at multiple scales. For example, if the logo is square excluding the motto/strapline, the following formats must work


 * Low-resolution use on web pages (e.g. as small as 100x100 pixels excluding moto/strapline)
 * Medium resolution use on fabric such as t-sirts or bags (e.g. 900x900 pixels at 150 dpi)
 * High-resolution use on large posters and banners (e.g. as large as 5,000x5,000 pixels at 300dpi).

The logo may be printed in CMYK for physical media, but must also have RGB colours for screen use. Additionally the logo must also be available in grayscale, and separately as single colour (i.e. black and white without any tones).

Deliverables Required
All outputs must be provided digitally:


 * 1) Logo demonstrating how it looks with just the graphical element, the graphical element with the project title, and the graphical element with each of the mottos/straplines, and everything together
 * 2) Source layered vector graphic files created in Adobe Illustrator
 * 3) Exported versions for quick use low, medium and high resolution full-colour PNG/JPEGs in RGB and CMYK
 * 4) Colour and font specification.

Rights/licensing:


 * 1) The designer will not retain any rights - all design and use rights will be given to OWASP, who will publish the logo and files using am open source licence, and OWASP will be able to use the logo, source files, ideas, designs in any manner it desires in any media in any quantity, without any additional payments, commission or royalties to the designer or anyone else
 * 2) All fonts used in the design must be provided to OWASP and comply with the above requirements

Future Phases: Other Graphical Elements
Scope TBC - Banners, t-shirts, etc

Background pictures (picture provider and designer will be cited on the project site):
 * A smart tech looking woman reading a piece of paper (the cheatsheet) while resting on a beach.
 * A woman hand holding cards with an ace up the sleeve.

Pictures proposal (just a proposal as bootstrap, others pictures can be used):
 * Cards:
 * https://www.pexels.com/photo/woman-holding-queen-of-hearts-and-diamonds-922706/
 * https://www.pexels.com/photo/ace-card-gambling-hand-274373/
 * https://www.pexels.com/photo/ace-bet-business-card-262333/
 * Beach:
 * https://www.pexels.com/photo/laptop-mockup-notebook-outside-4778/
 * https://www.pexels.com/photo/apple-check-computer-female-7079/
 * https://www.pexels.com/photo/beach-beach-chair-blur-casual-319921/
 * https://www.pexels.com/photo/close-up-of-woman-typing-on-keyboard-of-laptop-6352/
 * https://www.pexels.com/photo/black-and-gray-computer-laptop-159784/