CardDAV is a protocol for accessing and synchronising contact data over HTTP. It is commonly paired with CalDAV in groupware platforms, and it uses WebDAV-style methods and properties. Security depends on correctly enforcing who can view, modify, or delegate access to address books and contact collections.
Expanded Definition
CardDAV is an application protocol for managing address books and contact collections over HTTP, typically using WebDAV methods to create, read, update, and delete contact records. In practice, it sits inside a broader identity and collaboration stack, where permissions determine whether a user, app, or delegated service account can view or modify contact data. The protocol is standardised through Internet specifications, and its implementation usually relies on adjacent controls for authentication, authorisation, and session handling. For a standards-oriented baseline, see RFC 6352 alongside the control expectations in NIST Cybersecurity Framework 2.0.
Definitions vary across vendors when CardDAV is embedded inside mail, calendar, or MDM platforms, so the security boundary is often misread as “contacts only” rather than “an externally reachable identity-backed data service.” In NHI environments, that matters because the protocol may be accessed by sync clients, mobile apps, and automation tokens that inherit broader permissions than operators expect.
The most common misapplication is treating CardDAV endpoints as low-risk collaboration plumbing, which occurs when organisations fail to scope write access and delegated authentication separately.
Examples and Use Cases
Implementing CardDAV rigorously often introduces client-compatibility and permission-granularity constraints, requiring organisations to weigh seamless synchronisation against tighter control over who can enumerate or edit shared contacts.
- A managed mobile fleet syncs corporate address books to employee phones through a delegated service account, with access limited to read-only contact sets.
- A helpdesk platform publishes team contact collections for internal use, while administrative write access is restricted to a small RBAC group.
- A calendaring suite pairs CardDAV with CalDAV so that a user’s contacts and events sync consistently across devices, but separate scopes govern each data class.
- An automation workflow updates distribution lists from a HR system, using a short-lived token rather than a long-lived secret embedded in configuration.
- An organisation reviews sync logs after a third-party client begins repeatedly enumerating address books, revealing an overly permissive integration token.
For broader context on how identity-backed integrations expand exposure, the Ultimate Guide to NHIs shows that 97% of NHIs carry excessive privileges, which is directly relevant when CardDAV clients inherit broad access. The same control pattern appears in the NIST Cybersecurity Framework 2.0, where access permissions must be continuously managed rather than assumed safe after initial setup.
Why It Matters in NHI Security
CardDAV becomes an NHI security issue whenever contact sync is driven by service accounts, API tokens, or delegated clients that outlive their intended scope. A contact repository may seem operationally harmless, but it can expose employee directories, customer metadata, internal aliases, and relationship graphs that support phishing, impersonation, and lateral targeting. Once CardDAV is connected to a shared platform, the key question is no longer whether data can sync, but whether every client, token, and delegate can be traced, reviewed, and revoked in a predictable way.
This is especially important because NHIMG research shows only 5.7% of organisations have full visibility into their service accounts, and 79% have experienced secrets leaks with tangible damage in most cases. That combination means contact sync often runs under identities that are hard to inventory and harder to offboard, which creates persistent access paths long after an integration should have been removed. The control lesson aligns with identity governance guidance in the Ultimate Guide to NHIs and with least-privilege expectations in RFC 8630 where protocol design is paired with access discipline.
Organisations typically encounter CardDAV risk only after a sync token is abused, at which point address-book access becomes operationally unavoidable to contain and revoke.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers improper secret and token handling that often secures CardDAV sync clients. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions management applies directly to contact collections and delegated sync clients. |
| NIST Zero Trust (SP 800-207) | AC-3 | Zero trust requires each CardDAV request to be authenticated and authorised independently. |
| NIST SP 800-63 | AAL2 | Identity assurance levels inform how strongly users and service accounts authenticate to sync services. |
| OWASP Agentic AI Top 10 | Agentic clients that sync contacts via CardDAV need scoped tool access and safe delegation. |
Inventory CardDAV credentials, restrict scopes, and rotate or revoke tokens on a fixed schedule.
