Security Architecture

Security Architecture of Dossira

This document is for teams who want the details behind Dossira’s security model. We keep security concrete: clear boundaries, clear access, and a clear verification path.

If we just need the short version:

Passkeys replace passwords (Face ID / Touch ID / Windows Hello).
Workspaces isolate access by membership (and can be sealed).
Encryption is applied at rest and in transit.
Confidential Workspaces add end-to-end encryption (provider cannot read content).
Audit logs are available for access and key actions.
Hosting and operations are designed for a European operating boundary (where applicable to our deployment choices).

This document describes how we protect confidentiality, integrity, and availability across the application, network, and infrastructure.

Security governance & engineering practice

We build and operate Dossira with disciplined security practice:

Review and hardening: code review, configuration review, and security checks as part of normal delivery.
Testing: periodic internal and third-party testing of core workflows.
Vulnerability management: triage, patch cycles, and change control for security-relevant changes.
Operational oversight: incidents and security signals are reviewed as part of normal operations.

We use established reference points (for example OWASP guidance and common security control families) where they fit the product.

1. Authentication & access

Typed passwords are still the weakest link in most systems. Dossira is designed to reduce reliance on them.

Passkeys and strong factors

Passkeys (WebAuthn): Passkeys enable Face ID, Touch ID, or Windows Hello. They use a phishing-resistant cryptographic sign-in rather than a reusable secret.
Hardware-backed authentication: For higher-sensitivity work, we support FIDO2 hardware security keys.
Workspace policies: Workspaces can be configured to require stronger factors in environments where it is appropriate.

Where organizations require centralized identity governance, Dossira can support standard federated authentication patterns (for example OpenID Connect). This can be used to align with corporate identity policy and deprovisioning workflows.

Session security

Short-lived tokens: Sessions use short-lived signed tokens.
Cookie hardening: Session storage is configured to reduce exposure to script-level attacks where applicable.
Session controls: Users can revoke sessions via settings. Administrators can enforce session lifetime limits and force sign-out where needed.

Password handling (fallback)

Where passwords exist for fallback scenarios:

One-way hashing: Passwords are stored using modern one-way hashing (Argon2id) and are not recoverable.
Minimum standards: We enforce strong minimum length requirements and encourage passphrases.

Roles and permissions

RBAC baseline: Workspace access is governed by roles.
Fine-grained controls: Roles can be constrained with resource-level permissions (for example section-level controls, view-only modes, upload controls, and admin policies).
Least privilege: Defaults are narrow and explicit.

Shared responsibility (device hygiene)

The platform boundary depends on device security. We recommend:

keep operating systems and browsers up to date,
use modern browsers,
be cautious with browser extensions and untrusted software on work devices.

2. Hosting and operations boundary

Dossira is designed to support a European operating boundary.

Core workspace data: We avoid placing core workspace storage on US hyperscaler infrastructure for our primary deployments. This reduces cross-border exposure and improves jurisdictional predictability for many teams.
Controlled operations: Administrative access is limited, logged, and protected with strong authentication.
Geographic footprint: Our infrastructure is deployed in Europe, with regional presence depending on the service.

(For scope, providers, and verification, see our privacy and data processing documentation.)

3. Encryption strategy

We use defense-in-depth encryption across storage, backups, and network transport.

At rest (storage)

We encrypt data at the application layer:

Object/file encryption: Individual files and data blobs are encrypted using AES-GCM with 256-bit keys.
Key custody: Key management is separated from the storage layer to reduce the blast radius of any single subsystem.

Full disk encryption (infrastructure)

Full disk encryption: Servers use full disk encryption (for example LUKS/AES-XTS) so removed drives remain unreadable without keys.
Operational separation: Disk encryption control is separated from typical hosting-provider operations where possible.

Backups (encrypted, rotated, controlled)

Encrypted backups: Backups and snapshots are encrypted.
Rotation and retention: Backups rotate on a defined schedule. Deleted content may persist in backups until the rotation window expires.
Recovery testing: Restoration procedures are documented and exercised.

In transit (network)

TLS enforcement: We use modern TLS configurations between client devices and our perimeter.
Internal transport: Service-to-service traffic is encrypted on private network links. We avoid plaintext transport between application and data layers.

Confidential Workspaces (end-to-end encryption)

For workspaces where the service provider must remain blind to content, we offer end-to-end encryption:

encryption happens on member devices,
only authorized workspace members hold the keys,
Dossira cannot decrypt protected content by design.

See: End-to-End Encryption

4. Application integrity

We design the application to minimize attack surface and reduce supply-chain exposure.

Small runtime footprint: Core backend services are compiled services with a controlled runtime profile.
Dependency discipline: We keep external dependencies deliberate and limited where possible.
Release integrity: Releases are verified through integrity checks and controlled deployment.
Parameterized data access: Queries are parameterized and routed through a consistent authorization layer to reduce injection risk and ensure consistent policy enforcement.

5. Network & database isolation

Private networks: Databases and internal services run on private networks and are not exposed to the public internet.
API as gatekeeper: Data is accessed through the authenticated Dossira API, enforcing validation, authorization, and consistent logging.
Segmentation: Internal services are segmented to reduce lateral movement risk.

6. Logging, monitoring & abuse prevention

We monitor systems to detect failures and abuse while minimizing unnecessary personal data exposure.

Operational logging: Logs track errors, performance issues, and suspicious activity.
Privacy-aware logging: Logs avoid storing sensitive content. Exceptions are limited to security-relevant events.
Rate limits: Rate limiting mitigates brute-force and abuse attempts.
IP controls: Where required, access can be restricted to approved IP ranges.

7. Physical security & operational controls

Data is hosted in professional European data centers with physical controls:

controlled access,
monitoring,
redundant power and environmental controls.

Administrative access: Administrative access is restricted to a small set of senior staff, protected with strong authentication, and logged. Support staff do not have routine access to customer content. In end-to-end encrypted workspaces, content is not readable by Dossira by design.

8. Vulnerability disclosure

If you believe you have found a vulnerability in Dossira, please report it via our Contact Page. If we believe an incident affects customers, we follow internal incident procedures and communicate in line with our obligations.

Security Architecture