5. Security Considerations

5. Security Considerations

The security considerations for PATCH are nearly identical to the security considerations for PUT ([RFC2616], Section 9.6). These include authorizing requests (possibly through access control and/or authentication) and ensuring that data is not corrupted through transport errors or through accidental overwrites. Whatever mechanisms are used for PUT can be used for PATCH as well. The following considerations apply especially to PATCH.

A document that is patched might be more likely to be corrupted than a document that is overridden in entirety, but that concern can be addressed through the use of mechanisms such as conditional requests using ETags and the If-Match request header as described in Section 2. If a PATCH request fails, the client can issue a GET request to the resource to see what state it is in. In most cases, the client can check the contents of the resource to see if the PATCH resulted in the expected state.

Sometimes an HTTP intermediary might try to detect viruses being sent via HTTP by checking the body of the PUT/POST request or GET response. The PATCH method complicates such watch-keeping because neither the source document nor the patch document might be a virus, yet the result could be. This security consideration is not materially different from those already introduced by byte-range downloads, downloading patch documents, uploading zipped (compressed) files, and so on.

Individual patch document formats will have their own specific security considerations that will be documented with those formats. Applications using PATCH should take into account all of the security considerations associated with the specific formats they support. Some general considerations apply to all patch document formats though, including:

• Patch documents might contain instructions to modify parts of a resource that the client is not authorized to modify. Such a PATCH should be rejected by the server.
• Some patch document formats may have provisions for conditional requests. The server MUST ensure that such conditions are evaluated based on the state of the resource at the time of the operation, not on the state at the time of the request.
• Servers MUST be careful about doing validation of resources that contain untrusted content (e.g., user-supplied data). Many validation operations require parsing the resource, and parsing untrusted content presents opportunities for denial-of-service attacks and other malicious behavior.
• Patch documents may have no maximum size defined in the patch document format. Servers may want to establish their own maximum size for patch documents to protect themselves from attacks that use very large patch documents, and reject too-large patch documents with the status code 413 (Request Entity Too Large).
• Application designers should consider the impact of patch operations on resources that might be distributed across multiple locations. For instance, a patch may succeed on one copy of a resource but fail on another, resulting in resource state divergence.