REST Security Cheat Sheet - Revision history

Dominique RIGHETTO: Point to the official site

2019-07-15T14:39:15Z

Point to the official site

Thunder-Son: Migration to GitHub

2019-02-14T14:04:19Z

Migration to GitHub

Show changes

Hblankenship at 15:02, 28 December 2018

2018-12-28T15:02:07Z

Gutem: old link (http://www.aspectsecurity.com/research-presentations/bypassing-vbaac-with-http-verb-tampering) dead. Archived in (https://archive.li/XUvSz). Paper @ https://packetstormsecurity.com/files/66779/Bypassing_VBAAC_with_HTTP_Verb_Tampering.pdf.html

2018-09-04T19:17:56Z

old link (http://www.aspectsecurity.com/research-presentations/bypassing-vbaac-with-http-verb-tampering) dead. Archived in (https://archive.li/XUvSz). Paper @ https://packetstormsecurity.com/files/66779/Bypassing_VBAAC_with_HTTP_Verb_Tampering.pdf.html

Peter Mosmans: Correct misspellings

2018-05-16T08:15:43Z

Correct misspellings

Yo: /* HTTP Return Code */

2018-05-02T09:40:26Z

‎HTTP Return Code

Jmanico: /* Additional Cheatsheets */

2017-11-14T03:08:25Z

‎Additional Cheatsheets

Jmanico at 03:07, 14 November 2017

2017-11-14T03:07:47Z

Show changes

Jmanico: unlinking

2017-11-14T03:04:58Z

unlinking

Jmanico: added other more critical features of REST

2017-11-14T02:45:30Z

added other more critical features of REST

← Older revision		Revision as of 14:39, 15 July 2019
Line 4:		Line 4:
	The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!		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/REST_Security_Cheat_Sheet.md REST Security Cheat Sheet] to see the latest version of the cheat sheet.	+	Please visit [https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html REST Security Cheat Sheet] to see the latest version of the cheat sheet.

@@ Line 109: / Line 109: @@
 To make sure the content of a given resources is interpreted correctly by the browser, the server should always send the Content-Type header with the correct Content-Type, and preferably the Content-Type header should include a charset. The server should also send an <tt>X-Content-Type-Options: nosniff</tt> to make sure the browser does not try to detect a different Content-Type than what is actually sent (can lead to XSS).
-Additionally the client should send an <tt>X-Frame-Options: deny</tt> to protect against drag'n drop clickjacking attacks in older browsers.
+Additionally the server should send an <tt>X-Frame-Options: deny</tt> to protect against drag'n drop clickjacking attacks in older browsers.
 == CORS ==

@@ Line 3: / Line 3: @@
 {| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
-| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
+| style="border-right: 1px dotted gray;padding-right:25px;" valign="top" |
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
@@ Line 57: / Line 57: @@
 * Reject all requests not matching the whitelist with HTTP response code 405 Method not allowed
 * Make sure the caller is authorised to use the incoming HTTP method on the resource collection, action, and record
-In Java EE in particular, this can be difficult to implement properly. See [http://www.aspectsecurity.com/research-presentations/bypassing-vbaac-with-http-verb-tampering Bypassing Web Authentication and Authorization with HTTP Verb Tampering] for an explanation of this common misconfiguration.
+In Java EE in particular, this can be difficult to implement properly. See [https://packetstormsecurity.com/files/66779/Bypassing_VBAAC_with_HTTP_Verb_Tampering.pdf.html Bypassing Web Authentication and Authorization with HTTP Verb Tampering] for an explanation of this common misconfiguration.
 = Input validation =

@@ Line 15: / Line 15: @@
 Another key feature of REST applications is the use of standard HTTP verbs and error codes in the pursuit or removing unnecessary variation among different services.
-Another key feature of REST applications is the use of HATEOS or Hypermedia as the Engine of Application State. This provides REST applications a self-documenting nature making it easier for developer to interact with a REST service without a-priori knowledge.
+Another key feature of REST applications is the use of HATEOS or Hypermedia as the Engine of Application State. This provides REST applications a self-documenting nature making it easier for developers to interact with a REST service without a priori knowledge.
 = HTTPS =

@@ Line 131: / Line 131: @@
 = HTTP Return Code =
-HTTP defines status code [https://en.wikipedia.org/wiki/List_of_HTTP_status_codes].
+HTTP defines status codes [https://en.wikipedia.org/wiki/List_of_HTTP_status_codes].
-When designing REST API, don't just use 200 for success or 404 for error.
+When designing REST API, don't just use 200 for success or 404 for error. Always use the semantically appropriate status code for the response.
-Here is a selection of security related REST API status codes. Use it to ensure you return the correct code.
+Here is a non-exhaustive selection of security related REST API status codes. Use it to ensure you return the correct code.
 {| class="wikitable"
 !Status code
@@ Line 187: / Line 187: @@
 |Too Many Requests
 |The error is used when there may be DOS attack detected or the request is rejected due to rate limiting
 |}

@@ Line 198: / Line 198: @@
 Rocco Gränitz - rocco.graenitz@owasp.org
-= Additional Cheatsheets =
+= Other Cheatsheets =
-{{Cheatsheet_Navigation}}
+{{Cheatsheet_Navigation_Body}}
 |}
 [[Category:Cheatsheets]]

@@ Line 124: / Line 124: @@
 * <nowiki>https://example.com/resourceCollection/</nowiki><id>/action
-* https://twitter.com/vanderaj/lists
+* <nowiki>https://twitter.com/vanderaj/lists</nowiki>
 NOT OK:

@@ Line 11: / Line 11: @@
 [http://en.wikipedia.org/wiki/Representational_state_transfer REST] (or REpresentational State Transfer) is an architectural style first described in [https://en.wikipedia.org/wiki/Roy_Fielding Roy Fielding]'s Ph.D. dissertation on [https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm Architectural Styles and the Design of Network-based Software Architectures]. It evolved as Fielding wrote the HTTP/1.1 and URI specs and has been proven to be well-suited for developing distributed hypermedia applications. While REST is more widely applicable, it is most commonly used within the context of communicating with services via HTTP.
-The key abstraction of information in REST is a resource. A REST API resource is identified by a URI, usually a HTTP URL. REST components use connectors to perform actions on a resource by using a representation to capture the current or intended state of the resource and transferring that representation. The primary connector types are client and server, secondary connectors include cache, resolver and tunnel.
+The key abstraction of information in REST is a resource. A REST API resource is identified by a URI, usually a HTTP URL. REST components use connectors to perform actions on a resource by using a representation to capture the current or intended state of the resource and transferring that representation. The primary connector types are client and server, secondary connectors include cache, resolver and tunnel. In order to implement flows with REST APIs, resources are typically created, read, updated and deleted. For example, an ecommerce site may offer methods to create an empty shopping cart, to add items to the cart and to check out the cart.
-In order to implement flows with REST APIs, resources are typically created, read, updated and deleted. For example, an ecommerce site may offer methods to create an empty shopping cart, to add items to the cart and to check out the cart.
+Another key feature of REST applications is the use of standard HTTP verbs and error codes in the pursuit or removing unnecessary variation among different services.
 == HTTPS ==