Welcome to OWASP Cheat Sheet Series V2

This repository contains all the cheat sheets of the project and represent the V2 of the OWASP Cheat Sheet Series project.

Table of Contents

• Cheat Sheets index
• Special thanks
• Editor & validation policy
• Conversion rules
• How to setup my contributor environment?
• How to contribute?
• Offline website
• Project leaders
• Core technical review team
• PR usage for core commiters
• Project logo
• Folders
• License
• Code of conduct

Cheat Sheets index

The following indexes are provided:

• This index reference all released cheat sheets sorted alphabetically.
  • This index is automatically generated by this script.
• This index reference all released cheat sheets using the OWASP ASVS project as reading source.
  • This index is manually managed in order to allow contribution along custom content.
• This index reference all released cheat sheets using the OWASP Proactive Controls project as reading source.
  • This index is manually managed in order to allow contribution along custom content.

You can also search into this repository using a keywords via this URL:

https://github.com/OWASP/CheatSheetSeries/search?q=[KEYWORDS]

Example:

https://github.com/OWASP/CheatSheetSeries/search?q=csrf

More information about the GitHub search feature can be found here.

Project leaders

• Dominique Righetto.
• Jim Manico.

Core technical review team

Any GitHub member is free to add a comment on any Proposal (issue) or PR.

However, we have created an official core technical review team (core commiters) in order to:

• Review all PR/Proposal in a consistent/regular way using GitHub's review feature.
• Extend the field of technologies known by the review team.
• Allow several technical opinions on a Proposal/PR, all exchanges are public because we use the GitHub comment feature.

Decision of the core technical review team have the same weight than the projet leaders, so, if a reviewer reject a PR (rejection must be technically documented and explained) then project leaders will apply the global decision.

Members:

• Elie Saad.
• Jakub Maćkowski.
• Dominique Righetto.
• Jim Manico.

PR usage for core commiters

For the following kind of modification, the PR system will be used by the core commiters in order to allow peer review using the GitHub PR review system:

• Adding of new cheat sheet.
• Deep modification of an existing cheat sheet.

This the procedure:

1. Clone the project.
2. Move on the master branch:

   git checkout master

3. Create a branch named feature_request_[ID] where [ID] is the number of the linked issue opened prior to the PR to follow the contribution process:

   git checkout -b feature_request_[ID]

4. Switch on this new branch (normally it's the already the case):

   git checkout feature_request_[ID]

5. Do the expected work.
6. Push the new branch:

   git push origin feature_request_[ID]

7. When the work is ready for the review, create a pull request by visiting this link:

   https://github.com/OWASP/CheatSheetSeries/pull/new/feature_request_[ID]

8. Implements the modification requested by the reviewers and when the core technical review team is OK then the PR is merged.
9. Once merged, delete the branch using this GitHub feature.

See project current branches.

Project logo

Project's official logo files are hosted here.

Folders

cheatsheets_excluded:

• Contains the cheat sheets markdown files converted with PANDOC and for which a discussion must be made in order to decide if we include them into the V2 of the project due to the content has not been updated since a long time or is not relevant anymore. See this discussion.

cheatsheets:

• Contains the final cheat sheets files.
• Any .md file present into this folder is considered released.

assets:

• Contains the assets used by the cheat sheets (images, pdf, zip...).
  • Naming convention is [CHEAT_CHEET_MARKDOWN_FILE_NAME]_[IDENTIFIER].[EXTENSION]
  • Use PNG format for the images.

scripts:

• Contains all the utility scripts used to operate the project (markdown linter audit, dead link identification...).

templates:

• Contains templates used for different kinds of files (cheatsheet...).

.github:

• Contains materials used to configure different behaviors of GitHub.

.circleci / .travis.yml (file):

• Contains the definition of the integration jobs used to control the integrity and consistency of the whole project:
  • TravisCI is used to perform build and check actions at each Push or on each Pull Request.
  • CircleCI is used to perform regular scheduled build and check actions (night build).

Offline website

Unfortunately, a PDF file generation is not possible because the content is cut in some cheat sheets like for example the abuse case one.

However, to propose the possibility the consult, in a full offline mode, the collection of all cheat sheets, a script to generate a offline site using GitBook has been created. The script is here.

• book.json: Gitbook configuration file.
• Preface.md: Project preface description applied on the generated site.

Automated night build

This link provide the url where to download a night build of the offline website:

[ {
  "path" : "OfflineWebsite-NightBuild.zip",
  "pretty_path" : "OfflineWebsite-NightBuild.zip",
  "node_index" : 0,
  "url" : "https://14-162723104-gh.circle-artifacts.com/0/OfflineWebsite-NightBuild.zip"
} ]

The attribute url must be used to download the ZIP archive.

Manual build

Use the commands below to generate the site:

# Your python version must be >= 3.5
$ python --version
Python 3.5.3
# Dependencies:
#  sudo apt install -y nodejs
#  sudo npm install gitbook-cli -g
$ cd scripts
$ bash Generate_Site.sh
Generate a offline portable website with all the cheat sheets...
Step 1/5: Init work folder.
Step 2/5: Generate the summary markdown page.
Index updated.
Summary markdown page generated.
Step 3/5: Create the expected GitBook folder structure.
Step 4/5: Generate the site.
info: found 45 pages
info: found 86 asset files
info: >> generation finished with success in 14.2s !
Step 5/5: Cleanup.
Generation finished to the folder: ../generated/site
$ cd ../generated/site/
$ ls -l
drwxr-xr-x 1 Feb  3 11:05 assets
drwxr-xr-x 1 Feb  3 11:05 cheatsheets
drwxr-xr-x 1 Feb  3 11:05 gitbook
-rw-r--r-- 1 Feb  3 11:05 index.html
-rw-r--r-- 1 Feb  3 11:05 search_index.json

Conversion rules

• Use the markdown syntax described in this guide.
• Use this sheet for Superscript and Subscript characters.
• Use this sheet for Arrows (left, right, top, down) characters.
• Store all assets in the assets folder and use the following syntax:
  • ![ALTERNATE_NAME](../assets/ASSET_NAME.png) for the insertion of an image. Use PNG format for the images (this software can be used to handle format conversion).
  • [ALTERNATE_NAME](../assets/ASSET_NAME.EXT) for the insertion of other kinds of media (pdf, zip...).
• Use ATX style (# syntax) for section head.
• Use **bold** syntax for bold text.
• Use *italic* syntax for italic text.
• Use TAB for nested lists and not spaces.
• Use code fencing syntax along syntax highlighting for code snippet (prevent when possible horizontal scrollbar).
• If you use {{ or }} pattern in code fencing then add a space between the both curly braces (ex: { {) otherwise it break GitBook generation process.
• Same remark about the cheat sheet file name, only the following syntax is allowed: [a-zA-Z_]+.
• No HTML code is allowed, only markdown syntax is allowed!
• Use this site for generation of tables.
• Use a single new line between a section head and the beginning of its content.

Editor & validation policy

Visual Studio Code is used for the work on the markdown files. It is also used for the work on the scripts.

The file Project.code-workspace is the workspace file in order to open the project in VSCode.

The following plugin is used to validate the markdown content.

The file .markdownlint.json define the central validation policy applied at VSCode (IDE) and TravisCI (CI) levels.

Details about rules is here.

The file .markdownlinkcheck.json define the configuration used to validate using this tool, at TravisCI level, all web and relatives links used in cheat sheets.

How to setup my contributor environment?

See here.

How to contribute?

See here.

Special thanks

A special thanks you to the following peoples for the help provided during the migration:

• ThunderSon: Deeply help about updating the OWASP wiki links for all the migrated cheat sheets.
• mackowski: Deeply help about updating the OWASP wiki links for all the migrated cheat sheets.

License

See here.