Is it correct to assert that pure RESTful applications require HTTPS to be secure?

Given the fact that for pure REST each resource request from the client carries authentication information, it appears to me that the only way to secure against replay or copy-and-paste attacks requires that the REST request 开发者_开发技巧runs inside an HTTPS protected channel.

Is that assertion correct?

---

False. The fact that each request carries authentication does not mean that a request can be replayed. HTTP DIGEST can be used for authentication and a digest authentication cannot be replayed, because the challenge from the server will carry a different nonce on each connection and clients cannot reuse a nonce:

• Server nonce is allowed to contain timestamps. Therefore the server may inspect nonce attributes submitted by clients, to prevent replay attacks.
• Server is also allowed to maintain a list of recently issued or used server nonce values to prevent reuse

Requiring HTTPS is not bad on itself, it certainly adds increased privacy and tampering protection for the traffic, but it is not required to prevent replay and copy-paste attacks.

---

The assertion itself is incorrect since it lacks context. REST is an architectural style. Although HTTP is the typical example of supporting protocol for a RESTful system, the security of such a system would depend on a number of factors.

First of all, there are HTTP authentication mechanisms that are orthogonal to the application running on top of HTTP, e.g. HTTP Basic and HTTP Digest. While HTTP Basic isn't secure, there are mechanisms that can help protect against replay attacks in HTTP Digest, which doesn't send the authentication information in clear either. (There can be and there are other authentication mechanisms that are orthogonal to the application and that can be more secure than HTTP Digest too.)

There are also specifications for securing HTTP requests at the message level (e.g. HTTPsec).

However, the wide availability of SSL/TLS stacks on various languages/platforms/OS makes it rather convenient for many applications to protect the communication between the client and the server via HTTPS. Not using HTTPS doesn't mean that your system is going to be insecure (although it might require a bit of work to protect the data); and using HTTPS isn't a guarantee that your application will be secure either. Security is a broad topic and you need to consider the range of threats you want to be protected against before making an evaluation.