Security

Security principles

SyncString is being designed for data that deserves careful handling. Its current security model emphasizes least-privilege provider authorization, source-aware managed copies, explicit previews, and confirmation before high-impact changes.

Current hosted-portal safeguards

• Authenticated routes enforce membership and role checks again on the server; interface visibility is not treated as an authorization boundary.
• User records are scoped by normalized account identity, while tenant, policy, people, and audit records are scoped by organization.
• Google and Microsoft authorization requires an existing user-owned connection, verifies the returned provider identity, requests only selected contact or calendar scopes, and binds saved tokens to the exact provider account.
• iCloud setup accepts only an Apple app-specific password for an already-added iCloud account. SyncString never asks for an Apple Account password; the dedicated credential is encrypted before storage and may be replaced or removed with its connection.
• OAuth token payloads are encrypted before database storage using a server-held encryption secret. OAuth state cookies are HTTP-only, secure, short-lived, and cleared after the callback flow.
• Provider connection tests retain counts and redacted outcomes rather than provider response bodies, contact names, or event titles. The iCloud test performs a metadata-only CalDAV/CardDAV reachability check.
• Administrative capabilities are separated between billing and IT roles, with additional checks around role escalation and tenant-scoped records.
• Security headers limit framing, content-type confusion, referrer detail, and access to camera, microphone, and location.

Provider mutation boundary

SyncString creates or updates contacts and calendar events at Google and Microsoft only after you review an itemized preview, select the exact items, explicitly confirm them, and queue that operation. Scheduled and background reads do not mutate provider records without that confirmation. SyncString does not delete contacts. A missing record is never a delete signal, and incomplete, capped, or server-limited reads block mutation. iCloud remains read-only.

Deliberate calendar-event deletion is disabled in this environment by the provider-delete kill switch.

Microsoft contact and event updates and Microsoft event deletion remain blocked in this environment until the live stale-If-Match validation returns HTTP 412.

What is not live yet

Paid checkout is inactive during the free Beta 1. SCIM endpoints remain disabled unless an organization-specific bearer token and organization boundary are configured as protected hosting values; creating assignment rules alone does not activate Entra provisioning. Portal actions for unconfigured external services save configuration or queue a request; they do not claim that external work completed. Supported Apple app builds may use platform Keychain storage when that client capability is introduced.

Beta status

SyncString remains in beta hardening. This page describes current controls and design principles, not a certification, audit result, or guarantee that every planned production control is complete. Privacy, retention, incident response, subprocessors, and enterprise security terms will continue to mature before general availability.

Report a vulnerability

Please report suspected vulnerabilities privately to security@qualystudios.com. Include the affected component, reproduction steps, impact, and any supporting material. Do not access other users’ data, disrupt services, or publicly disclose an unresolved issue. We will acknowledge good-faith reports and coordinate next steps.