Videos
PUT and DELETE are not intrinsically insecure, they are used without problems at many REST services for example.
In my practice the main problem related to these HTTP verbs (apart from the common authentication and authorization problems) was that the server operators weren't aware of their existence introducing the possibility of HTTP Verb Tampering. In summary this means that access control was implemented based on a HTTP verb blacklist but some lesser known verbs were missing from this list allowing access control bypass.
I'd like to note that many web servers implement their own custom (sometimes undocumented) HTTP verbs, so this kind of "Verb-Based Access Control" doesn't seem like a very good idea anyway.
A Note on XSS (Edit 2023.11.17.)
In many cases applications use a particular interface by sending POST requests to it. If the interface is vulnerable to reflected XSS and it also accepts parameters in GET requests exploitation may become easier: if the interface only accepted POST, an attacker would need to direct the victim to a site controlled by him, so a crafted POST request to the real target can be triggered. On the other hand when GET is processed the same way as POST, the attacker only has to convince the victim to follow a link pointing to the (trusted) domain of the vulnerable target application.
Many current frameworks require you to explicitly specify what verb(s) a particular server-side method accepts (with annotations like @GET or @POST). It seems like a good idea to keep the set of accepted verbs minimal.
HTTP methods have little to do with security in and of themselves. A method like DELETE /users/1 could easily also be implemented as POST /users/1/delete or even GET /users/1/delete (GETs should never have side effects, but that doesn't stop some developers from doing so anyway).
You should therefore treat them similarly to any other HTTP method. GETs should not change server state, so typically you would only need to verify that the client has read access to the requested resource. PUTs should be used to update a resource wholly in-place (although they are often also used similarly to the PATCH verb), and so you should ensure that the client has the privileges to do this. Likewise, DELETE should be sent in order to request that a resource be deleted. So you would want to ensure a user has permission to do so.
In short: treat the verbs as descriptors of the type of action the user wishes to perform. Authenticate and authorize them to perform these actions as is required by the security parameters of your particular application.