1

I have been reading the widely recommended introduction to REST and came across the following statement:

POST, which usually means “create a new resource”, can also be used to invoke arbitrary processing and thus is neither safe nor idempotent.

Words like arbitrary processing and neither [i.e. not] safe make POST sounds less secure than PUT when there is a choice. Is this so? If so, is it best practice to prefer PUT over POST when possible?

I would have expected to find any security concerns highlighted in this highly-rated question. However, there is only a single mention of security in a quite lowly-ranked answer. I vaguely get the theoretical value of idempotence, but I definitely get the practical value of security. I imagine a lot of people are like that. So I'm guessing that there are no particular security concerns around POST, despite the arbitrary processing.

Where can I find more solid reassurance than guesswork?

Community
  • 1
  • 1
omatai
  • 3,448
  • 5
  • 47
  • 74
  • `security` is umbrella word that should be refine if you want to make any sens. My guess is that the author use `safe` in the sense of concurrent access of the resource. – mathk Mar 07 '16 at 22:54
  • @mathk No, 'safe' has [this meaning](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Safe_methods). –  Mar 08 '16 at 07:04
  • @lutz utterly the final point of having no side effect is to be consistent across repetitive and concurrent access. – mathk Mar 08 '16 at 07:08
  • The final point of not having side effects is to be RESTful. Even a single `GET` must not change server state. –  Mar 08 '16 at 07:11

3 Answers3

1

Note that the text you code talks about safe, not secure. The word 'safe' has a special meaning:

Some of the methods (for example, HEAD, GET, OPTIONS and TRACE) are, by convention, defined as safe, which means they are intended only for information retrieval and should not change the state of the server. In other words, they should not have side effects, beyond relatively harmless effects such as logging, caching, the serving of banner advertisements or incrementing a web counter.

Safe is not about security.

The word idempotent has a special meaning, too.

1

In this context, safe is not related to security

In the context of HTTP methods, safe is not related to security. Basically, safe means read-only.

RFC 7231

If you have any questions regarding the HTTP/1.1 protocol, the RFC 7231 is the best reference for you. The document defines the semantics and the content of the HTTP protocol.

Have a look at what it says about safe methods:

4.2.1. Safe Methods

Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. [...]

Of the request methods defined by this specification, the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe. [...]

Now, have a look at what it says about idempotent methods:

4.2.2. Idempotent Methods

A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent. [...]

Summarizing, the HTTP methods are classified as following:

+---------+------+------------+
| Method  | Safe | Idempotent |
+---------+------+------------+
| CONNECT | no   | no         |
| DELETE  | no   | yes        |
| GET     | yes  | yes        |
| HEAD    | yes  | yes        |
| OPTIONS | yes  | yes        |
| POST    | no   | no         |
| PUT     | no   | yes        |
| TRACE   | yes  | yes        |
+---------+------+------------+

Using the POST verb

POST is commonly used to create a new resource. But it's also a catch-all verb for operations that should not be executed using the other methods.

Use POST for non safe operations (not read-only) and for non idempotent operations (multiple identical requests may have different effects).

Additional resources

In the following page, you'll find great answers regarding choosing PUT or POST in REST applications:

Below you'll find the current references for the HTTP/1.1 protocol:

Community
  • 1
  • 1
cassiomolin
  • 124,154
  • 35
  • 280
  • 359
0

Other answers have highlighted the fact that the word safe is used in a particular context that implies nothing about security. But the notion of arbitrary processing has not been addressed.

Although a POST request can invoke arbitrary processing, that is not the same as saying that it will invoke arbitrary processing. The processing that will be invoked will be precisely that which the developer implemented. It's up to the developer to consider the security implications of that processing.

One needs arbitrary processing, for example, to assign a unique identifier to a database entry (order number, time stamp, etc) when there are multiple clients being served assynchronously. A PUT cannot be used for such a purpose. The processing is arbitrary in the sense that one can use sequential numbers, or odd numbers, or prime numbers or anything you like for such purposes. It needs to be "arbitrary" and unconstrained to support reasonable variations on this and similar themes. But yes - it can also potentially be used to do malicious things to a server. It's just that people typically don't (knowingly) write code to sabotage their own servers.

omatai
  • 3,448
  • 5
  • 47
  • 74