diff --git a/submissions/description/cross_site_scripting_xss/cross_site_request_forgery_csrf/flash_based/recommendations.md b/submissions/description/cross_site_scripting_xss/cross_site_request_forgery_csrf/flash_based/recommendations.md index b510a4e2..a40f8d57 100644 --- a/submissions/description/cross_site_scripting_xss/cross_site_request_forgery_csrf/flash_based/recommendations.md +++ b/submissions/description/cross_site_scripting_xss/cross_site_request_forgery_csrf/flash_based/recommendations.md @@ -1,8 +1,9 @@ # Recommendation(s) -There is no single technique to stop CSRF from occurring. However, implementing the right combination of defensive measures within the application will prevent and limit the impact of CSRF. Some best practices include the following: +Flash is now a depreciated technology that is no longer supported by many browsers. There are multiple security risks and performance issues related to Flash. Consider updating to alternative technologies, such as HTML5, JavaScript, and CSS3. + +Some other best practices include the following: -- All state changing requests should include CSRF tokens which are validated on the backend of the application. This token should be tied to the user’s session, strictly validated before an action is executed, and be unpredictable with high entropy. - Ensure that the framework is using built-in or existing CSRF prevention protections that exist within most major frameworks - Use the `SameSite` cookie attribute, which can have the values of `Lax`, `Strict`, or `None`. For example: @@ -13,6 +14,4 @@ There is no single technique to stop CSRF from occurring. However, implementing For more information, please see the Open Web Application Security Project (OWASP) guides located at: - -- -- -