Skip to content
The OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific application security topics.
Branch: master
Clone or download
Latest commit b4a9194 May 17, 2019

CSCounterBadge LicenseBadge PushAndPullRequestIntegrityCheck OfflineWebsiteBuild



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

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:[KEYWORDS]


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

Project leaders

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.


PR usage for core commiters

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

  • Addition of a new cheat sheet.
  • Deep modification of an existing cheat sheet.

Below are the steps to properly submit a PR:

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

    git checkout master

  3. Ensure that you have the latest files:

    git pull

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

    git checkout -b CSS-[ID]

  5. Switch to this new branch (normally it's already the case):

    git checkout CSS-[ID]

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

    git push origin CSS-[ID]

  8. When the work is ready for the review, create a pull request by visiting this link:[ID]

  9. Implement the modifications requested by the reviewers. Once the reviewers approve the PR, it is then merged to the master branch.
  10. Once merged, delete the branch using this GitHub feature.

See project current branches.

Project logo

Project's official logo files are hosted here.



  • 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.


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


  • Contains the assets used by the cheat sheets (images, pdf, zip...).
    • Use PNG format for the images.


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


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


  • 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 compliance check actions at each Push/Pull Request. It must be/stay the fastest possible (currently inferior to 2 minutes) in order to provide a rapid compliance feedback about the Push/Pull Request.
    • CircleCI is used to perform operations taking longer time like build, publish and deploy actions.

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.
  • Project preface description applied on the generated site.

Automated build

This link allow you to download a build (zip archive) of the offline website.

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 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.


See here.

You can’t perform that action at this time.