@@ -10,22 +10,32 @@ result in exposure of data or unintended code execution.</p>
10
10
</overview >
11
11
12
12
<recommendation >
13
- <p >When handling requests, make sure any requests that change application state are protected from
14
- Cross Site Request Forgery (CSRF). Some application frameworks, such as Spring, provide default CSRF
15
- protection for HTTP request types that may change application state, such as POST. Other HTTP request
16
- types, such as GET, should not be used for actions that change the state of the application, since these
17
- request types are not default-protected from CSRF by the framework.</p >
13
+ <p >Make sure any requests that change application state are protected from Cross Site Request Forgery (CSRF).
14
+ Some application frameworks provide default CSRF protection for unsafe HTTP request methods (<code >POST</code >,
15
+ <code >PUT</code >, <code >DELETE</code >, <code >PATCH</code >, <code >CONNECT</code >) which may change the state of
16
+ the application. Safe HTTP request methods (<code >GET</code >, <code >HEAD</code >, <code >OPTIONS</code >,
17
+ <code >TRACE</code >) should be read-only and should not be used for actions that change application state.</p >
18
+
19
+ <p >This query currently supports the Spring and Stapler web frameworks. Spring provides default CSRF protection
20
+ for all unsafe HTTP methods. Stapler provides default CSRF protection for the <code >POST</code > method.</p >
18
21
</recommendation >
19
22
20
23
<example >
21
- <p >The following example shows a Spring request handler using a GET request for a state-changing action.
22
- Since a GET request does not have default CSRF protection in Spring, this type of request should
23
- not be used when modifying application state. Instead use one of Spring's default-protected request
24
- types, such as POST.</p >
24
+ <p > The following examples show Spring request handlers allowing safe HTTP request methods for state-changing actions.
25
+ Since safe HTTP request methods do not have default CSRF protection in Spring, they should not be used when modifying
26
+ application state. Instead use one of the unsafe HTTP methods which Spring default-protects from CSRF.</p >
27
+
28
+ <sample src =" CsrfUnprotectedRequestTypeBadSpring.java" />
29
+
30
+ <sample src =" CsrfUnprotectedRequestTypeGoodSpring.java" />
31
+
32
+ <p > The following examples show Stapler web methods allowing safe HTTP request methods for state-changing actions.
33
+ Since safe HTTP request methods do not have default CSRF protection in Stapler, they should not be used when modifying
34
+ application state. Instead use the <code >POST</code > method which Stapler default-protects from CSRF.</p >
25
35
26
- <sample src =" CsrfUnprotectedRequestTypeBad .java" />
36
+ <sample src =" CsrfUnprotectedRequestTypeBadStapler .java" />
27
37
28
- <sample src =" CsrfUnprotectedRequestTypeGood .java" />
38
+ <sample src =" CsrfUnprotectedRequestTypeGoodStapler .java" />
29
39
</example >
30
40
31
41
<references >
@@ -36,8 +46,17 @@ OWASP:
36
46
<li >
37
47
Spring Security Reference:
38
48
<a href =" https://docs.spring.io/spring-security/reference/servlet/exploits/csrf.html" >
39
- Cross Site Request Forgery (CSRF)
40
- </a >.
49
+ Cross Site Request Forgery (CSRF)</a >.
50
+ </li >
51
+ <li >
52
+ Jenkins Developer Documentation:
53
+ <a href =" https://www.jenkins.io/doc/developer/security/form-validation/#protecting-from-csrf" >
54
+ Protecting from CSRF</a >.
55
+ </li >
56
+ <li >
57
+ MDN web docs:
58
+ <a href =" https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods" >
59
+ HTTP request methods</a >.
41
60
</li >
42
61
</references >
43
62
</qhelp >
0 commit comments