PR issue#1011

[Pastekitoo]

Update of Cross-Site Request Forgery Prevention Cheat Sheet
This PR fixes issue#1011
Am I in the right direction for this issue ? What's missing ?
PR by me and ouch3n

[mackowski]

This duplicates content from "Employing Custom Request Headers for AJAX/API"

[mackowski]

This change require bigger changes ;-) For example you are adding technique that is already described https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md#employing-custom-request-headers-for-ajaxapi

[mackowski]

@Pastekitoo do you want to work on this? You will need to merge what you have here with 'Employing Custom Request Headers for AJAX/AP' so we do not duplicate the content

[Pastekitoo]

@mackowski I wasn't sure how to merge my part and 'Employing Custom Request Headers for AJAX/AP', so I tried something, let me know what you think.

[mackowski]

You cannot add this content without changing exisiting content because the protection that you are describing is already described here https://github.com/OWASP/CheatSheetSeries/pull/1623/files#diff-02bc1fbe932c98d807eedbfc2a54ef8c5dbb33feb7b5400cf484a740228530f4L129

Employing Custom Request Headers for AJAX/API

Both the synchronizer token and the double-submit cookie are used to prevent forgery of form data, but they can be tricky to implement and degrade usability. Many modern web applications do not use <form> tags to submit data. A user-friendly defense that is particularly well suited for AJAX or API endpoints is the use of a custom request header. No token is needed for this approach.
In this pattern, the client appends a custom header to requests that require CSRF protection. The header can be any arbitrary key-value pair, as long as it does not conflict with existing headers.

X-YOURSITE-CSRF-PROTECTION=1

When handling the request, the API checks for the existence of this header. If the header does not exist, the backend rejects the request as potential forgery. This approach has several advantages:

• UI changes are not required
• no server state is introduced to track tokens
  This defense relies on the CORS preflight mechanism which sends an OPTIONS request to verify CORS compliance with the destination server. All modern browsers designate requests with custom headers as "to be preflighted". When the API verifies that the custom header is there, you know that the request must have been preflighted if it came from a browser.

[jmanico]

I second what @mackowski is saying and will hold off on approving this until he is satisfied.

[mackowski]

Hey @Pastekitoo any updates on this?

[mackowski]

No action for over 3 months - I am closing this PR