HTTP protocol transactions are sent in the clear over the network unless protection from snooping is negotiated. This can be accomplished by use of TLS, as defined in [RFC2818]. In particular, HTTP Basic authentication MUST NOT be used unless TLS is in effect.
Servers MUST take adequate precautions to ensure that malicious clients cannot consume excessive server resources (CPU, memory, disk, etc.) through carefully crafted reports. For example, a client could upload an event with a recurrence rule that specifies a recurring event occurring every second for the next 100 years, which would result in approximately 3 x 10^9 instances! A report that asks for recurrences to be expanded over that range would likely constitute a denial-of-service attack on the server.
When creating new resources (including calendar collections), clients MUST ensure that the resource name (the last path segment of the resource URI) assigned to the new resource does not expose any data from within the iCalendar resource itself or information about the nature of a calendar collection. This is required to ensure that the presence of a specific iCalendar component or nature of components in a collection cannot be inferred based on the name of a resource. When rolling up free-busy information, more information about a user's events is exposed if busy periods overlap or are adjacent (this tells the client requesting the free-busy information that the calendar owner has at least two events, rather than knowing only that the calendar owner has one or more events during the busy period). Thus, a conservative approach to calendar data privacy would have servers always coalesce such busy periods when they are the same type.
Procedure alarms are a known security risk for either clients or servers to handle, particularly when the alarm was created by another agent. Clients and servers are not required to execute such procedure alarms.
Security considerations described in iCalendar [RFC2445] and iTIP [RFC2446] are also applicable to CalDAV.
Beyond these, CalDAV does not raise any security considerations that are not present in HTTP [RFC2616] and WebDAV [RFC2518], [RFC3253], [RFC3744].