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?
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:
- RFC 7230: Message Syntax and Routing
- RFC 7231: Semantics and Content
- RFC 7232: Conditional Requests
- RFC 7233: Range Requests
- RFC 7234: Caching
- RFC 7235: Authentication
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.
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.
