It is not REST that is unsecure by itself. It is people following ideas without critical thinking.
Maybe I only had _under brained_ CTO, but I always had problems in details. And even though I have been an architect/sysadmin, recently I went back to coding for others, because I prefer coding.
I saw a lot of mess in signaling the error code, or changing how to return them (is it an 5XX error or a { "status" : "bla", "error" : ... }) or even using the "PUT/GET/POST/DELETE" correctly.
Wrong handling of cache too... of HTTP headers, media type... authentication ...
Also trying to make distributed transactional systems without synchronized clocks on server (and with unsecure NTP source because editing the default ntpd.conf is sooooo hard). And denying the need of FSM for distributed REST servers because REST is supposed to be stateless. (lol)
Or the specs of rest limited to a nice HTML page with one example of the "right case" and no descriptions of the types and no informations on how errors are handled.
On the paper REST is great. In practice ... Oh boy. It is the PHP of messaging.
I think you probably need to read up on RFC 2616 again then, and in particular section 9, method definitions.
In terms of status codes, the RFC is very clear: "Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request" [2] so if you are returning a 200 OK when using REST and there server is indicating an error, then you are doing it wrong.
In terms of caching, OPTIONS is not cacheable; GET is cacheable if it conforms to section 13 [3], HEAD can be cacheable, POST is not cacheable at all, responses to [UT are not cacheable, likewise with DELETE.
As for REST being stateless - well, yes! HTTP is "a generic, stateless, protocol" - and indeed every request you send is an independent transaction unrelated to any previous request.
As for producing a distributed transaction system, sure if you have a distributed set of servers processing REST requests, without some sort of FSM it's going to be hard to implement... I just don't see this as a fundamental issue with REST.
As for "Or the specs of rest limited to a nice HTML page with one example of the "right case" and no descriptions of the types and no informations on how errors are handled" - aside from the HTTP RFC, REST is detailed in Roy Thomas Fielding's doctoral dissertation [4] and is a really great read, I recommend reading it if you haven't already as it details many of the things you raise as issues.
I can't see how REST is fundamentally insecure! Could you elaborate?