owasp / cheatsheetseries

The OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific application security topics.

Welcome to the OWASP Cheat Sheet Series

Welcome to the official repository for the Open Web Application Security Project® (OWASP) Cheat Sheet Series project. The project focuses on providing good security practices for builders in order to secure their applications.

In order to read the cheat sheets and reference them, use the project official website. The project details can be viewed on the OWASP main website without the cheat sheets.

🚩 Markdown files are the working sources and aren't intended to be referenced in any external documentation, books or websites.

Cheat Sheet Series Team

Project Leaders

• Jim Manico
• Jakub Maćkowski

Core Team

• Kevin W. Wall
• Shlomo Zalman Heigh

Chat With Us

We're easy to find on Slack:

1. Join the OWASP Group Slack with this invitation link.
2. Join the #cheatsheets channel.

Feel free to ask questions, suggest ideas, or share your best recipes.

Contributions, Feature Requests, and Feedback

We are actively inviting new contributors! To start, please read the contribution guide.

This project is only possible thanks to the work of many dedicated volunteers. Everyone is encouraged to help in ways large and small. Here are a few ways you can help:

• Read the current content and help us fix any spelling mistakes or grammatical errors.
• Choose an existing issue on GitHub and submit a pull request to fix it.
• Open a new issue to report an opportunity for improvement.

Automated Build

This link allows you to download a build (ZIP archive) of the offline website.

Local build

The OWASP Cheat Sheet Series website can be built and tested locally by issuing the following commands:

make install-python-requirements
make generate-site
make serve  # Binds port 8000

Contributors

• From 2014 to 2018: V1 - Initial version of the project hosted on the OWASP WIKI.
• From 2019: V2 - Hosted on GitHub.

Special thanks

A special thank you to the following people for their help provided during the migration:

• Dominique Righetto: For his special leadership and guidance.
• Elie Saad: For valuable help in updating the OWASP Wiki links for all the migrated cheat sheets and for years of leadership and other project support.
• Jakub Maćkowski: For valuable help in updating the OWASP Wiki links for all the migrated cheat sheets.

Open Web Application Security Project and OWASP are registered trademarks of the OWASP Foundation, Inc.

cheatsheetseries's Issues

Cheat sheet update/refactor proposal: JWT for Java AES/GCM usage issue

Section "Token information disclosure" in JSON_Web_Token_Cheat_Sheet_for_Java.md describes an elaborate scheme to encrypt JWTs in order to hide their content from clients.

While I am not qualified to judge the overall quality of the cheat sheet regarding the JWT implementation, the usage of AES/GCM in this scheme demonstrates severe lack of understanding of its properties.

For the purpose of this description I will treat the JWT to be encrypted as an opaque, secret plaintext string P.
The cheat sheet proposes the following steps for encryption of the secret, given the secret key K and the plaintext P to be encrypted:

1. Initialize a AES/GCM cipher instance in encryption mode with the key K and a random nonce N
2. Obtain 32 random bytes (which I will call A) and add them as AAD to the AES/GCM cipher instance
3. Encrypt P using the AES/GCM cipher instance. This yields the ciphertext C.
4. Compute SHA256(C)
5. Store SHA256(C), A and N as a row in a database
6. Return C to send to the client

The proposed (authenticated) decryption then works as follows, given C and K:

1. Compute SHA256(C)
2. Use SHA256(C) to obtain A and N from the database
3. Initialize a AES/GCM cipher instance in decryption mode with key K and nonce N
4. Supply AAD data A to the cipher instance
5. Obtain P by decrypting C with the cipher instance and return it for further processing

Most of this protocol is completely pointless. The nonce N for AES/GCM must be unique, but is not required to be secret. It can safely be prepended to C and sent to the client. This removes the need to store the nonce in the database.
The AAD A that is used serves no purpose as well. It is random and is never used anywhere else but in the cipher. AES/GCM is an authenticated encryption mode. The additional data is optinal, and not required for authentication to be performed. The random AAD can safely be eliminated from the protocol.
This means that now no database is necessary for authenticated encryption/decryption. SHA256(C) was only used as a key to look up the other two values in the database, so this step can be dropped as well.

I suspect the other sections of the document may contain similar errors. Regrettably I am not knowledgeable enough about JWT to review it.

Please review the cheat sheet, or remove it if no volunteers can be found to do it. A lot of developers see OWASP as a trustworthy resource for security guidelines, so a flawed cheat sheet may cause more harm than good.

Cheat sheet update/refactor proposal: [Session_Management_Cheat_Sheet]

The following section suggests usage of SHA1 for session cookie generation

Session ID Content (or Value)
It is recommended to create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits).

Based on research carried out by Google, SHA-1 was found to be vulnerable to collision attacks and hence we should not recommend usage of SHA-1 in security context.

Cheat sheet update/refactor proposal: Cross-Site Request Forgery Prevention Cheat Sheet

Fix typo in: Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md in line:

"and no enterprise would want to loose even this minor % of traffic"

should be:

"and no enterprise would want to lose even this minor % of traffic"

New cheat sheet proposal: DNS Security

NOTE: In light of this recent event wanted to create the following DNS Cheat Sheet

---

Thanks you for proposing a new cheat sheet.

Please provides the following information about your proposal:

1. Which security issues are bring or commonly meet when someone must work on this topic?
   How do I secure my domain at the DNS level, which if not secure undermines everything else?
2. What is the objective of the cheat sheet?
   Instruct the reader on which DNS records they need to set depending on their set-up, as well as other best DNS practices.
3. What the CS will bring to the reader?
   One stop shop for DNS security best practices that currently require hours of Googling to effectively gather.

Thanks you again for your contribution 😃

Multi-Factor Authentication CS

List of common factors (SMS, e-mail, application, hardware tokens etc) that can be used for Multi-Factor Authentication with comparison.
Example implementation of Multi-Factor Authentication.

Cheat sheet update/refactor proposal: Content Security Policy Cheat Sheet

Provide common pitfalls and the addition of strict-dynamic, as well as a general update to the whole CS based on reviews from the first version release.
This should be done in the coming weekend/next week.

This issue is mainly based on the insight of the following tweet: https://twitter.com/LewisArdern/status/1112926476498698240

Cheat sheet update/refactor proposal: Abuse_Case_Cheat_Sheet

• Updated the language to be more concistent with the rest of the OWASP framework. Changing the wording from the informal "guy" to formal neutral "person/people/profile".

• Correction typos and spelling errors.

Cheat sheet update/refactor proposal: XML_External_Entity_(XXE)_Prevention_Cheat_Sheet

The CERT coding standard indicates a no-op EntityResolver as a way to prevent XXE in Java, but I don't see it anywhere on the XXE Cheat Sheet.

I'd be happy to add a section describing its use.

Cheat sheet update/refactor proposal: Authentication_Cheat_Sheet

Update Password Complexity section.
I want to include some tips from this Troy's Hunt article. In particulate I think that we should eliminate complex characters rules in exchange for for long passwords and support for password managers (e.i. allow paste password)

Server-side Request Forgery (SSRF) Prevention CS

There is no Server-side request forgery prevention CS.
Aim is to provide short description about SSRF, where we can find this vuln and methods how to prevent/defend against SSRF.

Remove the "Authors and Primary Editors" section

In order to only use the GH feature for contributors, the section Authors and Primary Editors of all CS will be removed.

The information will be transfered in a file named CONTRIBUTOR-V1.md in which there will be the list of contributors (of the project V1 in fact) and the associated CSs.

Cheat sheet update/refactor proposal: Cross Site Scripting Prevention Cheat Sheet

Please provides the following information about your proposal:

• What update/refactoring do you want to perform?

In bonus rule 5 (Properly use modern JS frameworks like Angular (2+) or ReactJS), React and Agular are mentioned.
React currently has a particular recommandation :

When using ReactJS do not use dangerouslySetInnerHTML. If you really, really really have to use dangerouslySetInnerHTML remember that now all framework protections are turned off and you have to escape or sanitize all the data by yourself.

This type of "tool" also exists in Angular via bypassSecurityTrust* functions.

Even if it works a bit differently, I think it would probably be relevant extend the notice to Angular as it is mentioned on this rule and wouldn't really add complexity to the CS.

We could reword it as something like :

"When using ReactJS, do not use dangerouslySetInnerHTML. When using Angular (2+), do not use functions with the pattern bypassSecurityTrust{something}.
If you really, really really have to use these functions remember that now all framework protections are turned off and you have to escape or sanitize all the data by yourself."

New cheat sheet proposal: Dependency Management

1. Which security issues are bring or commonly meet when someone must work on this topic?

When a project use 3rd party dependencies it can happen a day in which one or more dependencies used are impacted by a CVE.

2. What is the objective of the cheat sheet?

• Explains which tools (free and open source first) can be used to monitor and detect the presence of CVE in dependencies (like OWASP Dependency Check...).
• Explains how to manage the vulnerable dependency when a CVE is detected and impact it.

3. What the CS will bring to the reader?

A concrete and pragmatic proposal of approach to manage the dependency in a project.

Note:

OPC associated Control: C2 - Leverage Security Frameworks and Libraries.

CS update proposal: Content Security Policy

Missing SOP websockets section/notes as they are a special case.

Marketing presentation

Create a marketing presentation in order to allow any people to talk about the project during any kind event.

No need to have many slides, the objective is to have a small set of slides with the key figures or important information about the project like:

• What is the project?
• What is its goal?
• For whom is it targeted?
• Which domain are supported?
• ...

Cheat sheet update/refactor proposal: PHP_Configuration_Cheat_Sheet

Thanks you for proposing a update/refactor of a cheat sheet.

Please provides the following information about your proposal:

• What update/refactoring do you want to perform?

Hello. I noticed that the cookie_lifetime value provided does not match the comment on the same line. The cookie_lifetime is given as 864000 (seconds), which is ten days. However, the comment says "4 hours." I'll submit a PR momentarily.

Thanks you again for your contribution 😃

Cheat sheet update/refactor proposal: C-Based_Toolchain_Hardening_Cheat_Sheet

Fixing 2 typos

Cheat sheet update/refactor proposal: CSP CS Add Trusted Types

What update/refactoring do you want to perform?

Add a section explaining how to apply a CSP policy that leverage the Trusted Types new feature.

According to this post, currently (may 2019) this feature is not ready for production usage:

We are working on providing more code examples, guides and documentation on how to migrate applications to Trusted Types. We feel this is the right moment for the web developer community to start experimenting with it.

By the way, I have tested (may 2019) the demo page:

• All tests are green on the last version of Firefox (66.0.3) and Chrome (74.0.3729.131) and Opera (58.0.3135.132) on a WIN10 Pro.
• Tests n°4 and n°12 are red on Edge (44.17763.1.0) on a WIN10 Pro.
• Page do not load in IE11 (11.437.17763.0) with error SCRIPT5009: 'Reflect' is undefined and SCRIPT5009: 'TrustedTypes' is undefined on a WIN10 Pro.

⏰ Process this request only when Google will indicate that the Trusted Types will be ready for production

New cheat sheet proposal: Apache HTTP Server

Thanks you for proposing a new cheat sheet.

Please provides the following information about your proposal:

1. Which security issues are bring or commonly meet when someone must work on this topic?
   Most web servers completely undermine any security that was built into the application. It can render all app security code pointless. Very important to get this right.
2. What is the objective of the cheat sheet?
   Make an updated single source of truth for a generally secure Apache config.
3. What the CS will bring to the reader?
   Eliminate the need to rely on 10 year old+ documentation that is scattered across the internet and often wasn't even right back then. Actually explain Apache HTTP Server in a way people not committing to the source code can actually understand.

Thanks you again for your contribution 😃

New cheat sheet proposal: Microservices-based Security Architecture Documentation

1. Which security issues are bring or commonly meet when someone must work on this topic?

Design flaw (mostly, related with authorization) in web application based on microservices architecture.
During securing web-application based on microservices architecture security engineers usually face with the following questions:

• What scopes (OAuth 2 framework) does microservice minimally (principle of least privileges) need to access other microservices API?
• What grants does microservice minimally (principle of least privileges) need to access database or message queue?
• What microservices are invoked by dedicated microservices (call graph, to analyze sensitive data leakage)?
• Does microservices read/write date from/to specific database or message queue (to analyze sensitive data leakage)?
• What storages does contain sensitive data?
• What microservices endpoints need to be tested?

In most cases existing application architecture is not suitable to answer that questions.

2. What is the objective of the cheat sheet?

Explain what architecture security-specific information can be collected to answer the questions above.

3. What the CS will bring to the reader?

A concrete proposal of approach to collect microservices-based architecture information to securing architecture.

Cheat sheet update/refactor proposal: TLS Cipher String Cheat Sheet - Cipher suites priority

As mentioned in #70 (comment), the SSL cipher suites priority should be updated to be in sync with Mozilla SSL cipher suites priority.

CSP CS Avoid section update

Following PR #92, Avoid CSP section should be re-worded and changed to highlight how CSP can act as a firm second layer to protect against XSS attacks.

New cheat sheet proposal

Thanks for proposing a new cheat sheet.

Please provides the following information about your proposal:

1. Which security issues are brought or commonly meet when someone must work on this topic?
2. What is the objective of the cheat sheet?
3. What the CS will bring to the reader?

Thanks again for your contribution 😃

Cheat sheet update/refactor proposal: DotNet Security Cheat Sheet

I propose changing the section:

After .NET Core 2.0 it is possible to automatically generate and verify the antiforgery token. Forms must have the requisite helper as seen here:

<form action="RelevantAction" >
@Html.AntiForgeryToken()
</form>

And then add the [AutoValidateAntiforgeryToken] attribute to the action result.

Regarding to the ASP.NET Core docs this is not necessary if tag helpers are used, so you just need to check if this line is in your currently active _ViewImports.cshtml :

@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers

E.g. the Web Project Templates that come with Visual Studio 2019 and 2017 for ASP.Net Core Web projects (MVC or Razor pages) include this by default.

HMAC based token pattern scheme

Excusme, I wanna ask you about this :

https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md

i want to implement this but i still got no idea about the flow work HMAC based token, pointly on verify the token using HMAC. can you explain more detail sir ? Any help from you will be useful for me in the future. Thank you

Cheat sheet update/refactor proposal: Credential Stuffing Prevention Cheat Sheet

I want to add some additional mitigations against Credential Stuffing like: CAPTCHA, Pwned Passwords(https://haveibeenpwned.com/Passwords)

In addition I think that Credential_Stuffing_Prevention_Cheat_Sheet should be refreshed, for example I want to add some examples how several mitigations can be combined together, different mitigations for different account privileges (admin, user, etc), example reference implementations or tools that can help etc.

Cheat sheet update/refactor proposal: Password_Storage_Cheat_Sheet

Please provides the following information about your proposal:

• What update do you want to perform?

Correct typo or number formatting on line 65.

The problem is that the way it is now is confusing (at least to me), we don't know if the number meant is "one billion" or "a hundred thousand" :

In the example above, as PBKDF2 [...] at least 1 second (like 1000.000 for example).

Should probably become :

In the example above, as PBKDF2 [...] at least 1 second (like 100.000 for example).

Or :

In the example above, as PBKDF2 [...] at least 1 second (like 1.000.000 for example).

Based on popular implementations, I think 100.000 was meant but I'm unsure.
I'll submit a PR if you validate the change and provide which one of the two is the correct number.

Cheat sheets index from OWASP ASVS point of view

Task:
Create a index file (maintained manually in order to allow contribution on it) that classify all the cheat sheets using of the point of view of the differents sections of the ASVS.

Objective:
Address the following important problem raised by the community:

Too many best practices:
It would be nice to have them structured so people drill down to Exactly what they want.
Like the @thoughtworks tech radar: https://www.thoughtworks.com/radar

Cheat sheet update/refactor proposal: REST Security Cheat Sheet

There is a broken link in https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Security_Cheat_Sheet.md

Bypassing Web Authentication and Authorization with HTTP Verb Tampering leads to a generic page on ey.com.

@nahsra is there a valid link to the original presentation?

Fix building in Travis CI

It look that PR build are not isolated and some very simple PR like #104 are failing due to error on other, not modified CSs: https://travis-ci.com/OWASP/CheatSheetSeries/builds/111723804

Cheat sheets index from OWASP Proactive Controls point of view

Task:
Create a index file (maintained manually in order to allow contribution on it) that classify all the cheat sheets using of the point of view of the differents controls point of the Proactive Controls.

Objective:
Address the following important problem raised by the community:

Too many best practices:
It would be nice to have them structured so people drill down to Exactly what they want.
Like the @thoughtworks tech radar: https://www.thoughtworks.com/radar

Cheat sheet update/refactor proposal: DotNet_Security_Cheat_Sheet

On the DotNet_Security_Cheat_Sheet.md.

I would like to add a new section at the bottom for "Security Announcements "
In that new section, I would like a link to ASP.NET Security Announcements and a note about subscribing:

"ASP.NET Security Announcements" https://github.com/aspnet/Announcements/issues?q=is%3Aopen+is%3Aissue+label%3ASecurity

Select the "Watch" button to receive notifications.

If that sounds OK, and is the proper place for it, I will submit a PR with the change tied back to this issue. Thanks for considering! I have also added a link to the DotNet_Security_Cheat_Sheet from the security portion of the TOC for ASP.NET Core docs here: dotnet/AspNetCore.Docs#11743

Thanks!

Cheat sheet update/refactor proposal: SQL Injection Prevention Cheat Sheet

Thanks you for proposing a update/refactor of a cheat sheet.

Please provides the following information about your proposal:

• What update/refactoring do you want to perform?
  The SQL Server Escaping sections makes a reference to a blog post I wrote some time ago (https://blogs.msdn.microsoft.com/raulga/2007/01/04/dynamic-sql-sql-injection/). This particular post is going to be moved to a new location soon.
  I have created a short URL (https://aka.ms/sql-injection) that right now points to the same location, and once the new location is available, I will change the redirected URL without disruption or having to make further changes to this CS.
  Thanks.

Thanks you again for your contribution 😃

OWASP Wiki content update: Redirect CS pages to GitHub MD files

Goal

This issue has been created in order to track and provide information about the update of the OWASP wiki content of the project in order to replace every cheat sheet wiki page content with a redirection ,along a text, pointing to the associated markdown file hosted in this repository.

❗ Important note: Only cheat sheets for which a file in the folder cheatsheets is present must be updated.

The list of the cheat sheet wiki pages is here.

This is the content (mediawiki format) to use:

The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!

Please visit [FULL_URL_TO_MD_FILE CHEAT_SHEET_NAME] to see the latest version of the cheat sheet.

Example:

The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!

Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Abuse_Case_Cheat_Sheet.md Abuse Case Cheat Sheet] to see the latest version of the cheat sheet.

Help

Anyone with a OWASP wiki account can help for this task, just post a comment on this issue with the name of the cheat sheet that you have ou you will handle in order to allow a little sync between contributors 😃

Thanks you

I thanks you very much in advance any contributor that will help us in this step of the migration 👍

CS XSS Prevention update rule 6 JS/Node lib(s)

• What update/refactoring do you want to perform?

Update JS/Node lib(s) on Cross Site Scripting Prevention rule 6.

Cross Site Scripting Prevention rule 6 links to ecto/bleach under "Other libraries that provide HTML Sanitization include: [...] JavaScript/Node.js Bleach" (Line 344).

The current (5 year-old) version, [email protected], contains 1 moderate severity vulnerability according to https://npmjs.com/advisories/47

Overview

All versions of the bleach package are vulnerable to a regular expression denial of service attack when certain types of input are passed into the sanitize function.

Remediation

The bleach package is not currently maintained, and has not seen an update since 2014.

To mitigate this issue, it is necessary to use an alternative module that is actively maintained and provides similar functionality.

The advisory then links to a fairly unhelpful search for "html sanitizer" on npmjs.com.

There is an open issue from 2016 at ecto/bleach#12.

My cursory research into currently maintained libraries yielded two options:

1. cure53/DOMPurify, a DOM-only library that requires JSDOM on Node.js
2. punkave/sanitize-html, a Node.js-only library that depends on htmlparser2

If OWASP contributors find both libraries adequate and satisfactory, my suggestion for the revision would be to split "JavaScript/Node.js Bleach" (Line 344) into two lines/list items like so:

• JavaScript (DOM-only, requires JSDOM for Node.js)
• Node.js (depends on htmlparser2)

If desired, I am willing to open a PR for the above suggested revision or whatever contributors advise. Thoughts?

Cheat sheet update/refactor proposal: DotNet Security Cheat Sheet

Thanks you for proposing a update/refactor of a cheat sheet.

Please provides the following information about your proposal:

I would like to update the OWASP Top 10 list from 2013:

1. A1 Injection
2. A2 Broken Authentication and Session Management
3. A3 Cross-Site Scripting (XSS)
4. A4 Insecure Direct Object References
5. A5 Security Misconfiguration
6. A6 Sensitive Data Exposure
7. A7 Missing Function Level Access Control
8. A8 Cross-Site Request Forgery (CSRF)
9. A9 Using Components with Known Vulnerabilities
10. A10 Unvalidated Redirects and Forwards

to 2017:

1. A1 Injection.
2. A2 Broken Authentication.
3. A3 Sensitive Data Exposure.
4. A4 XML External Entities (XXE) [NEW]
5. A6 Security Misconfiguration.
6. A7 Cross-Site Scripting (XSS)
7. A8 Insecure Deserialization [New]
8. A9 Using Components with Known Vulnerabilities.
9. A10 Insufficient Logging & Monitoring.

Thanks you again for your contribution 😃

New cheat sheet proposal - Docker Security

1. Which security issues are bring or commonly meet when someone must work on this topic?

Misconfigurations when working with docker containers can downgrade application security (e.g. default runs as a root user) or even introduce new vulnerabilities to the system (like exposing docker port)

2. What is the objective of the cheat sheet?

Spread the knowledge about good practices when working with docker containers.
(On one side provide informations about most common misconfigurations and how to avoid them, and on the other side inform how good configuration can significantly increase overall application security.)

3. What the CS will bring to the reader?

Single place describing how to securely use docker, and what can be done to improve security of application or mitigate results of vulnerabilities in applications. List of tools, that can help with two previous points.

Add OPC to the project

• Add OPC index in the README and into the offline website generated job/script.
• Do notification.

Discussion about excluded cheat sheet from the migration

The following cheat sheets are subject to discussion about the need to be migrated or discarded.

The reason of my decision to open the discussion on these cheat sheets is related to either the quality or either the added value of the content provided.

Content Security Policy

I think that the content of this CS is too old and needs to be deeply refactored and I think they currently do not bring added value to a dev team.

✅ Refactored and released by @ThunderSon

PL SQL Security

I think that the content of this CS need to more thorough and I think they currently do not bring added value to a dev team.

Secure SDLC

I think that this CS is not needed because the OWASP Open SAMM project is dedicated to this topic.

Security Testing

The CS do not add any added value and the content is too light.

Web Application Security Testing

I think that this CS is not needed because the OWASP Testing Guide project is dedicated to this topic and there this project for a checklist about the OTG.

Web Service Security Testing

Same remarks than for Web Application Security Testing CS.

OWASP TOP 10

I think that this CS is not needed because the OWASP ASVS project and the OWASP Proactive Controls project are dedicated to help developers. Moreover, OWASP TOP 10 should only be used for awareness operation...

Secure Coding

I think that this CS is not needed because the OWASP ASVS project should be used for code review operation

XSS Filter Evasion

The CS project is oriented defense and prevention. This CS is oriented attack so I think it must be re-classified into the Attack category of the OWASP wiki.

Feel free to post a comment, it's the reason of existence of this post 😃

New cheat sheet proposal: OAuth

Hi, so the goal being which OAuth flow to use for which use case (which I think we are largely OK with), which flow has which threats and the countermeasures for them (which the IEFTs provides although across a substantial number of documents)

(https://tools.ietf.org/html/rfc8252, https://tools.ietf.org/html/rfc6819. https://tools.ietf.org/html/draft-ietf-oauth-security-topics-11) - IETF
https://openbanking.atlassian.net/wiki/spaces/DZ/pages/68550784/Open+Banking+Security+Profile+-+Implementer+s+Draft+v1.1.1#OpenBankingSecurityProfile-Implementer'sDraftv1.1.1-OAuth2.0,OIDCandFAPI - Open Bankings pattern which includes a standard for using OAuth
https://hackernoon.com/strengthening-oauth2-for-mobile-f4f3925dbf18

My goal is to get comfort that when teams say we are doing 'OAuth' we 1 know which flow to use, 2 build it securely and can reference how it's aligned to 'best practise' so we don't need to independently verify that implementation each time.

With the added benefit of producing a reference deployment pattern for said flow. eg when doing Authorisation code grant flow PKCE is mandated/recommended.

Maybe I am over complicating the challenge but feedback welcome...

Cheat sheet update/refactor proposal: Content Security Policy Cheat Sheet

Full update of the cheat sheet.

Cheat sheet update/refactor proposal: TLS Cipher String Cheat Sheet

Hi,
I'd suggest to update the TLS cipher string recommendations by increasing the recommendations by one level.
Cheers Torsten

CS Credential Stuffing Grammar Update

• What update/refactoring do you want to perform?

Grammar update

Cheat sheet update/refactor proposal: Issue on the PBKDF2 iteration counter specified in the Password Storage Cheat Sheet

The password storage cheat sheet recommends an iteration count of 10.000 for PBKDF2 key derivation, referencing a 2012 Apple report using these numbers. I believe it should be clear that a 2012 recommendation is out of place in a current security cheat sheet.

The 2018 version of the report states that 10 million iterations are now used for iOS backups. Other reports (although not quite up to date either) mention 100.000 and 200.000 iterations.

Considering how quickly these recommendations seem to be changing at the moment, does it even make sense to include a fixed number at all?

Cheat sheet update/refactor proposal: TLS_Cipher_String_Cheat_Sheet - TLSv1.3

Hello OWASP!

First of all, thanks for migrating Cheat Sheet Series to GitHub. 😉

I'd like to get a statement from your side about the TLSv1.3 topic.
Currently the OWASP Cipher String 'A+' uses TLSv1.2 protocol.

In September 2018 OpenSSL released the final TLSv1.3 support in the 1.1.1 version.
Firefox 61 (June 2018) has been released with on-by-default support for TLSv1.3.
Chrome 70 (October 2018) has been released with on-by-default support for TLSv1.3.

There are open issues in Mozilla SSL Generator in this topic: mozilla/server-side-tls#217,
mozilla/server-side-tls#191.

I'd be happy if OWASP releases an update for the recommended TLS (1.3) cipher strings.
Then I can update nginxconfig.io with the new rulesets (digitalocean/nginxconfig.io#42).

Deploy offline website to GitHub page

Update the CircleCI job in order to deploy the generated offline website to the repository associated GitHub page system in order to allow user to see what is the content of the offline website.

Cheat sheet update/refactor proposal: DotNet Security Cheat Sheet

The DotNet security cheatsheet talks about use of customErrors in web.config, but it appears that this might have been superseded by httpErrors.

HttpErrors can provide protection in more scenarios, so having people update their web.config setups to use httpErrors might offer better protection. As an example, we've had a penetration tester raise an issue whereby an attempt to access a non-existent page in a non-existent directory results in the standard ASP.NET error page being displayed, despite having customErrors set up to deal with missing pages using a custom 404 error page defined in customErrors.

CustomErrors is only used if the request is passed to ASP.NET; there are some scenarios in which a request will never get that far.

HttpErrors includes several options that need better explanations than are present elsewhere on the web; should a 404 error code be returned, or is it better to return a 200 with the custom error page? This decision determines what mode should be used, and we're struggling to know what is best. We are probably not alone. I think it would be great if OWASP could be the definitive source of best practice in this regard.

Cheat sheet update/refactor proposal: XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet.md

• What update/refactoring do you want to perform?

Add Bonus Rule #5 about good practices when using modern JS frameworks

In case of ReactJS - do not use dangerouslySetInnerHTML
In case of Angular (2+) - remember to build with -prod parameter (ng build --prod) in order to avoid template injection

Cheat sheet update/refactor proposal: PHP_Configuration_Cheat_Sheet

Thanks you for proposing a update/refactor of a cheat sheet.

Please provides the following information about your proposal:

• What update/refactoring do you want to perform?
  PHP Config Sheet, and probably later a general PHP Language Sheet (new).

Thanks you again for your contribution 😃

New cheat sheet proposal: Best Practices for sharing online code

Good day,

As requested by Dominique, here's my question to the group.

I am trying to compile a list of best practices in my business on how to share code responsibly and securely.

In basic terms, I’m trying to come out with a short of checklist for our coders like a best practices or do’s and don’ts on how to make sure your code is clean to post online to open source repositories like GitHub and others.

Because right now, it’s like the wild, wild, west. Upper management is telling coders to do everything in the cloud and share your code, but they do so carelessly.

In big, am trying to see if you offer such a list or ideas what to do, like an OWASP top 10.

Stuff I know I need my coders to look for is;

• Ensuring that no internal server names or IP addresses are posted in the code
• To use caution when posting DB’s and ensuring that they only contain non-sensitive / test data and not actual client data.
• Usernames, passwords, private keys to be removed and /or replaced as appropriate
• Scan code with security tool

If you do have guidelines or checklist for this type of security / sanitation, I would appreciate being guided towards it.

Here are the answers to the template for new issues/proposal:

1. Which security issues are bring or commonly meet when someone must work on this topic?
   Safe sharing of corporate code information and apps, without leaking corporate data and simply be more vigilant.
2. What is the objective of the cheat sheet?
   Help out the community on best practices for sharing clean code online (not only format, but what to include and what not to include)
3. What the CS will bring to the reader?
   Another great arsenal for the OWASP community and a safer internet

Any help on this subject is greatly appreciated.

Best Regards,

Brian Maher